Hi @Juno
to add to what @tflidd already said, I think the knot here is the mental model, not Nextcloud.
You are thinking in POSIX ownership, “who does ls -l show as the owner”. Nextcloud does not track file ownership there at all. To the OS the whole data directory belongs to one single web server user (in a container that is usually UID 33, www-data/http), and the filesystem is nothing more than a blob store to Nextcloud. Which Nextcloud user owns which file lives in the database (oc_storages, oc_filecache, oc_mounts), not in the file permissions. So “on the host I cannot see who created the file” is true, but it does not matter: Nextcloud knows perfectly well, and shows it to you in the web UI, in the Activity app and via occ. The place to ask “who owns this” is the application, not ls -l. That is not a shortcoming, it is how essentially every multi-user web application works, and it is what lets Nextcloud express things POSIX simply cannot, like “Bob shared this read-only with Alice until Friday”.
The /opt/userfolders/Bob external storage idea will not give you what you are after, and this is the part worth being clear about. The Local external storage backend still reads and writes as that same single web server user. There is no impersonation, Nextcloud never becomes the folder’s POSIX owner, so access is governed entirely by what that one web server user (UID 33) is allowed to do on the path: it needs read and write there for a normal read-write mount, and if it only has read permission the mount is effectively read-only. Per-user local folders only change where the bytes sit, not who owns them at the OS level, so on the host everything is still UID 33. You would be taking on a lot of extra fragility (backups, quota, previews, trash and sharing all get more awkward with external storage) and get none of the per-user OS ownership you wanted. Pointing the root at / on top of that is a security smell I would avoid.
If you genuinely need OS-visible per-user identity, and on TrueNAS that is reasonable to want, turn it around and let the storage layer own the identity. Give each user their own dataset with its own TrueNAS ACLs, and add it in Nextcloud over a protocol that can authenticate each user separately, SFTP or SMB/CIFS for instance, using a per-user authentication mechanism so everyone logs in with their own credentials instead of a shared set. Then the NAS sees each access as that actual user and enforces ownership at the storage layer, while Nextcloud just passes the bytes through. That is the real difference: the Local backend always acts as the single web server user, with no way to enter a per-user login, while a backend that authenticates each user carries a real per-user identity. An NFS export does not change this either, from Nextcloud’s side an NFS mount is just Local again, the same single user.
The backends and their authentication options are described here:
For a plain Nextcloud install though, do none of this. Let Nextcloud own its data directory as the single web server user and let it manage users in its own layer. That is the intended design, not a limitation to work around.
h.t.h.
ernolf