I had a functioning Nextcloud 9.0.51 server, however, I was getting the odd repeating error in the logs as outlined here. So I tried running the strong permissions script recommended in the docs to set the correct permissions.
Immediately after running it, when I attempt to access any page on my Nextcloud server I just get a blank white page with a “file not found” message similar to this bug report. Running the script to loosen permissions for upgrade, immediately makes my server work again, but be insecure.
The only 2 modifications I have made to either script are to match that my data folder is not inside the Nextcloud folder, and to match that my root user is not in the same group as the http data webserver user.
The only other possible factor I can think of is that because I installed with Yunohost, Nextcloud uses it’s own user/group rather than the shared webserver group. This was no issue before running the script, however.
Have other people (especially running Nginx or with data folders outside the Nextcloud folder) tried running the strong permissions script? Does it work for you? Any ideas why it may not be working here?
I’m neither a Yunohost user, nor an nginx user, so don’t take this as gospel.
Did you confirm the user/group that nginx runs as (e.g., phpinfo)? Check again, in case Yunohost has weird settings – don’t presume that it’s www-data/www-data.
To set sane permissions and ownership from cli, as root, cd to the root directory of your nextcloud and use:
find . -type f -exec chmod 644 {} \;
find . -type d -exec chown www-data:www-data {} \;
find . -type f -exec chown www-data:www-data {} \;```
Substitute your actual nginx user:group for www-data:www-data.
You may need to change /data too, but this should get it working again.
Yeah you’re right about the user thing. Yunohost creates a new user/group for any ownCloud installation (which I then upgraded to Nextcloud), so in this case the correct user/groupis actually different from the NGINX HTTP user. I’d already accounted found this though and used the correct user /group in the script. (I know it’s the correct user/group as that’s what it was using before sand that’s what it runs fine with ID I use the upgrade permissions).
I’ll try out the directory/folder permissions commands you suggested though and report back.
Ok, so @NickW’s suggested permissions work fine, which got me wondering exactly which part of the strong permissions script was breaking things.
After going through and manually applying each command from the strong permissions script and then testing my Nextcloud instance, it appears the culprit is the part that makes everything, except a few folders be owned by root. The stronger 640/750 permissions don’t appear to create any issues.
I actually found I’d introduced a bug by being it be made owned by root:root instead of user:root. When I fixed that though, I now get the text from the pages nextcloud generates, but no external resources (eg images except user avatars, css, fonts etc).
I’m guessing that a couple more folders need changing from root:root to root:user. Any ideas?
EDIT: It looks like the 750/640 permissions WERE causing issues with accessing css/images/fonts etc, but when I first wrote this, the browser was caching them, hiding the problem. Even when I chown’d the whole Nextcloud directory recuursively with user:user, the problem persisted, until I changed the permissions back to 755/644.
Under normal (i.e., not YunoHost) circumstances, the only files that should have root as owner are .htaccess in NC root and data directories (root:[HTTP group]) and these should have permissions of 644.
If permissions of xx0 are causing problems, you have user:group setting errors. Normally (see above) these should all be [HTTP user]:[HTTP group].
What is the nginx user and group? If you really have ownership root:root, with permissions of xx0, you will surely have a broken installation, unless nginx runs as root (very bad).
Edit to add: I would be wary of running NC scripts in a ‘special case’ installation. Clearly, it isn’t possible for NC devs to take all cases into consideration. You either have a convenient installation and make adjustments manually, or you do a ‘standard’ installation and have access to convenient scripts. The same problem arises with, for example, installation on shared hosting, where there is not full control over the environment.
…so basically it’s making everything be owned by root, except those few folders which it changes back.
Hmmm… ok. I’ll have to figure out how to hunt these down.
Presumably for extra security, possibly to assist with having more than one ownCloud/Nextcloud installation, Yunohost runs most apps under www-data, but ownCloud / Nextcloud it gives it’s own installation specific user/group.
www-data ,but as mentioned before, all files were previously assigned to a unique user/group. Under that user/group everything was running ok, barring a single repeating error in the logs which didn’t cause visible issues, until I ran the strong permissions script.
I wasn’t aware I had a “special case” installation, until all of this!
In a standard (Apache) installation, the web server user is www-data and it belongs to group www-data. Permissions of 750/640 (directories/files) will allow Apache to read and write all the files. This can be improved by granting ownership of the two .htaccss files to root, so only root can make changes, but all users and groups can read.
The script also makes all the other files in the NC root directory writeable only by root, which makes it more secure, but is inconvenient for updates – ownership must be changed back before the update script can be run.
If permissions were more permissive, probably 755/644, then that unique user/group would have had read access to everything, so most things would work fine. Problems would arise if a new file had to written, or changes made to an existing file.
It boils down to the complication of having an intermediate layer (YunoHost) between the server operating system and the application. I think you are making things harder for yourself by, essentially, crowbarring an unsupported application into an ease-of-use framework. Probably not what you wanted to hear.
Probably, although to be fair, I originally installed ownCloud 9 with it, which is a supported application, and Nextcloud 9 is supposed to be compatible with ownCloud 9, so I’d say the real issue is that Yunohost is running things in a non-standard way. I do appreciate the help you’ve given though.
I might try just changing all of the files over from Yunohost’s unique user to the webserver user (as per the script), and see if that breaks anything. I mean hey, if an attacker has access to my webserver user, I’m pretty much DOA already anyway, right?
No! I hadn’t! That’s good news to see that existing, as I’d been campaigning for it in the Yunohost forums and they were all taking the line that Nextcloud was so new that they should all just “wait and see” how the whole Nextcloud / ownCloud thing pans out. Thanks for alerting me to this!
‘Supposed’ is the operative word. I have had to go back to OC9 (and may yet go back to OC 8.2.5, from whence I came to NC), as webdav stopped working, which is important for me. I’m running on shared hosting, so I expect to jump through a few hoops, but I would like to see NC take a more inclusive stance on a wider variety of hosts.
Not an issue if you stay within the YunoHost sphere.
A sensible approach, imo. NC is still in a state of flux (inevitably) and there’s no point in YunoHost expending effort on an unstable (in terms of changing) base.
