NextCloud and OwnCloud History
Some time ago I tried OwnCloud, it wasn’t a positive experience for me. Since that time I’ve got a server with a much faster CPU, a faster Internet connection, and the NextCloud code is newer and running on a newer version of PHP, I didn’t make good notes so I’m not sure which factors were most responsible for having a better experience this time. According to the NextCloud Wikipedia page [1] the fork of NextCloud from the OpenCloud base happened in 2016 so it’s obviously been a while since I tried it, it was probably long before 2016.
Recently the BBC published an interesting article on “Turnover contagion” which is when one resignation can trigger many more [2] which is interesting to read in the context of OwnCloud losing critical staff failing after one key developer resigned.
I mentioned OwnCloud in a 2012 blog post about Liberty and Mobile Phones [3], since then I haven’t done well at achieving those goals. A few days ago I decided to try NextCloud and found it a much better experience than I recall OwnCloud being in the past.
Installation
I installed OwnCloud on an Oracle Cloud ARM VM (see my previous blog post about the Oracle Cloud Free Tier [4]).
This CloudCone article on installing NextCloud on Debian 10 (Buster) covers the basics well [5].
Here is the NextCloud URL for downloading the PHP files (a large ZIP archive) [6]. You have to extract to where Apache is configured to have it’s webroot and then run “chown -R www-data nextcloud/lib/private/Log nextcloud/config nextcloud/apps” (or if you use php-fpm then chown it to the user for that). NextCloud recommend having all of the NextCloud files owned by www-data, but that’s just a bad idea, allowing it to rewrite some of it’s program files is bad, allowing it to rewrite all of them is worse.
For my installation I used the Apache modiles macro, rewrite, ssl, php7.4, and headers (this is more about how I configure Apache than about NextCloud). Also I edited /etc/php/7.4/apache2/php.ini and changed memory_limit to 512M (the default of 128M is not enough). I’m currently only testing it, for a production use I would use php-fpm and run it under it’s own UID so that it can’t interact with other PHP apps.
After that it was just a matter of visiting the configuration URL and giving it the details of the database etc.
After setting it up the command “php -d memory_limit=512M occ app:install richdocumentscode_arm64” when run from the root of the OwnCloud installation installs the Cloudera components for editing LibreOffice documents in OwnCloud, this is the command for ARM64 architecture, I presume the command for other architectures is similar.
Conclusion
OwnCloud is very usable, it has a decent feature set built in and the option to download modules such as the components for editing LibreOffice files on the web is useful. But I am hesitant to install things that require the sort of access it requires. I think it would be better if there was a documented and supported way of installing things and then locking them down so that at runtime it can only write to data files not any program files or configuration files. It would also be better if it was packaged for Debian and had the Debian update process for security fixes. I can imagine many people installing it, forgetting to update it, and ending up with insecure systems.
Small typo nit. Third paragraph “chmod www-data…” should be “chown www-data…”
Running Nextcloud via container can address some of the concerns about how much access it requires.
P.s.: as I’m writing this your comment box is presenting black text on a black background…
Tomas: thanks, I fixed that.
Jonathan: True, but even in a container you don’t want it being exploited.
Strange about the comment box, it’s black text on white background for me. What browser do you use?