Nextcloud Permission Issue Notes¶

Problem¶

A TrueNAS SCALE NFS share containing an Obsidian vault was mounted on a Linux desktop.

Symptoms¶

File manager could duplicate files successfully.
Terminal cp worked.
Obsidian could create and edit notes.
Obsidian could not duplicate files.

Obsidian error:¶

Uncaught (in promise) Error: EPERM: operation not permitted, copyfile
'/home/james/Projects/Notes/Noteforge/Meeting.md'
->
'/home/james/Projects/Notes/Noteforge/Meeting 1.md'

Additional symptoms:¶

Some Samba operations failed with permission errors.
Some container writes behaved inconsistently.

Recursive chmod operations failed with:

chmod: changing permissions ... Operation not permitted

Technologies involved¶

TrueNAS SCALE¶

Storage backend: - ZFS dataset - Native NFSv4 ACLs Relevant ZFS properties:

acltype=nfsv4
aclmode=restricted
aclinherit=passthrough

NFS¶

Linux client mount:

nfs4
vers=4.2

Mounted using normal UID/GID mapping:

sec=sys

Proxmox LXC containers¶

Containers were unprivileged. Example:

Container:
www-data UID 33
Host/NAS sees:
UID 100033

This caused files created by Nextcloud to appear on TrueNAS as:

rather than:

This is expected behaviour for unprivileged containers.

Nextcloud¶

Nextcloud was intentionally sharing the same dataset. Workflow:

Laptop
 |
Nextcloud sync client
 |
TrueNAS dataset
 |
NFS clients
 |
Obsidian / editors / tools

Therefore separating Nextcloud data into another dataset was not appropriate.

Diagnosis commands¶

Check NFS mount¶

Linux client:

findmnt /home/james/Projects

Showed:

nfs4
vers=4.2

Check filesystem type¶

stat -f .

Confirmed:

Type: nfs

Check ownership¶

TrueNAS:

ls -ln <file>

Example:

1001 3001

and Nextcloud-created files showed:

because of LXC UID remapping.

Check ZFS ACL configuration¶

TrueNAS:

zfs get acltype,aclmode,aclinherit,xattr,exec,setuid Jiggerbights/projects

Important output:

acltype     nfsv4
aclmode     restricted
aclinherit  passthrough

Inspect real NFSv4 ACLs¶

getfacl was misleading because it only showed the POSIX view. Use:

nfs4xdr_getfacl <file>

Example: Before:

trivial_acl: false

After fixing:

trivial_acl: true

Root cause¶

The issue was:

ZFS aclmode=restricted

With NFSv4 ACLs enabled, ZFS was preventing metadata-changing operations that conflicted with the ACL. Operations affected: - Node.js fs.copyFile() used by Obsidian - chmod operations - some Samba metadata operations - some container file operations Normal writes still worked, which made the problem confusing.

Fix¶

Changed the ZFS dataset ACL mode:

zfs set aclmode=passthrough Jiggerbights/projects
zfs set aclinherit=passthrough Jiggerbights/projects

After this: - Obsidian file duplication worked. - Obsidian editing worked. - Nextcloud-created files could be edited from NFS clients. - Nextcloud could modify files created by other users.

Resulting ACL example¶

Working file:

owner: 1001
group: 3001
mode: 777
trivial_acl: true
owner@:rwxp--aARWcCos:allow
group@:rwxp--a-R-c--s:allow
everyone@:rwxp--a-R-c--s:allow

Future troubleshooting checklist¶

If similar issues occur: 1. Check whether it is a metadata problem, not a write problem. Test:

touch testfile
cp file testcopy
chmod 775 file

2. Check ZFS ACL settings:

zfs get acltype,aclmode,aclinherit <dataset>

3. If using mixed Linux/NFS/container environments, prefer:

acltype=nfsv4
aclmode=passthrough
aclinherit=passthrough

4. Inspect actual NFSv4 ACLs:

nfs4xdr_getfacl <file>

5. Remember LXC UID mapping:

container UID 33
=
host/NAS UID 100033

6. Avoid recursive chmod/chown until the ACL model is understood. They can make a working ACL tree worse.