Write Files with Correct UID/GID

We’re planning on migrating to nextcloud soon. Our users have remote home directories which I would like to make accessible using nextcloud as their storage root. This is easy enough using ldap. The problem is that there are several ways that the users can access the files in their home directories including good old fashioned Linux login. This means that the files need to be written, and nextcloud needs to be able to read using the correct uid/gis (again stored in ldap) for the logged in user. After extensive googling I couldn’t find anything on how to do this. Is it possible?

It depends on where the files are stored.

If the files are on external storage, and the user mounts the external storage with their own login, then actions in that storage will be done in their user context. Usually that means they will own the files on the the remote system.

If you’re talking about the user owning files within Nextcloud’s data folder, that’s not possible. The data folder and contents must be owned by www-data and should not be accessed directly anyway.

I can use external storage as the users root though, wouldn’t that do what I want just in a much more inconvenient to set up way?

External storage can’t be the user’s home folder root. It’s a folder beneath their home folder.

You may want to read that thread more closely.

I don’t think I misunderstood it, it allows you to configure the external storage mount point as / “so that the user sees only external storage”. Can you clarify how you think I am misinterpreting it?

I managed to hack together a solution to this which I think is “good enough” and I’m going to leave it here in case other people are interested in this kind of setup. I still think it would be nice to have proper uid/gid support.

First of all, the linked PR works exactly how I thought it would, you set the mount point to ‘/’ (you can even do this on the GUI by entering / for the name) and the users root folder becomes the external storage. Not sure why Karl thinks it works different.

Next, I set up ACL permissions on the remote drive (more on why later). Users home directories are configured with default permissions 770 and owner as username:usergroup (e.g. max:max for myself). Then make sure the setgid bit is set on the user home directories:

chmod g+s /home/max

this ensures that when a file or folder is created by nextcloud, the group owner will be the users personal group ID.

Next, use ACL to give permissions to the www-data user, which in my setup was userid 33:

setfacl -m g:33:rwx

This gives nextcloud full control over the home directory without letting any other user have such control (this is why you need ACLs, using a group is not fine grained enough). If a user doesnt want a file or folder accessible to nextcloud, they can revoke this ACL.

Next, make a default ACL to do the same, so that when a user creates subdirectories they still have this ACL:

setfacl -dm g:33:rwx

and make sure there is a default ACL for the users group:

setfacl -dm g:max:rwx

this way the user always has access to their files even if nextcloud does something unexpected like changing the group ownership.

The end result of this is that new files created in nextcloud are owned by the www-data user, but are owned by the users personal group (www-data:max in my example) and there are additional ACLs in place making sure that both nextcloud and the user do not lose access to their files (again the nextcloud ACL is freely revoked in the user wants that).

All of these precise permissions can be automated when new users are onboarded although I haven’t set that up yet. This can also be linked to the ldap home folder attribute to make it all pretty much automatic.

Important caveat: nextcloud does indeed require an up-to-date database to interact with files stored in this way, so there needs to be periodic rescans setup (recommendation was to use cron i believe) in order to show files created outside of nextcloud. I suppose this could be expensive for big file structures. some kind of watch mechanism would be really nice here.