Cannot sync. chmod fails "operation not permitted"

Here is my system:

  • Proxmox host

  • TrueNAS 25.04.2.4 VM (passed-through ZFS array)

  • Syncthing installed as TrueNAS app with host networking enabled

  • Windows 11 PC running syncthing via SyncTrayzor

I’m running Syncthing as a TrueNAS app, attempting to one-way sync Documents folder from Windows PC to SMB share.

Some config info:

  • Created dedicated user in TrueNAS (sync_user)with SMB authentication enabled.

  • Dataset uses NFSv4 ACLs with owner having “Full Control”

  • Syncthing container configured to run as this user (verified UID/GID match)

  • SMB share working - can read/write/delete files from Windows

Here’s my problem:

Syncthing creates directories successfully but fails to sync files with error:

chmod /vault/Documents/[path]: operation not permitted

Even when logged in as the file owner, chmod operations fail:

sync_user@truenas:/mnt/Tank/Vault/Documents$ chmod 755 test_folder
chmod: changing permissions of 'test_folder': Operation not permitted

The user (sync_user) owns the files but cannot modify permissions. The ACL system is preventing chmod operations even for the file owner.

  • Syncthing successfully creates directories

  • Tries to set specific permissions (chmod) on those directories

  • Fails because NFSv4 ACLs block the chmod operation

  • Cannot complete the sync process

I’m at my wits end. I’m a novice with all this stuff and have been leveraging AI tools (claude, chat-GPT) to help me troubleshoot. I’ve been troubleshooting this for a week now and keep getting hung up at the exact same spot.

From my research, it seems like my options are:

  1. Modifing ACL to explicitly grant write_acl permission to owner. (Not real sure what this will do, or what the implications are.)

  2. Switch dataset from NFSv4 ACLs to POSIX permissions. (Also, not real sure what this means)

  3. Configure Syncthing to ignore permissions. – This seems to be a solution that would fix the problem, but I feel like this would cause some problems down the road while my home lab evolves.

I’m very close to throwing in the towel and moving to another solution, but from what I’ve seen, syncthing seems like an awesome solution. I don’t understand what’s unique about my setup that is causing the base functionality of this service to fail. I really want this to work.

Thanks.

It’s not clear to me how Ignore Permissions might break things for you moving forward – if you’re mostly just one person accessing your own files, the permissions are probably not going to be a problem. I would try that first.

I’m not smart on NFSv4 ACLs but I believe “write_ACL” for the user that owns the Syncthing process might solve the issue. If that user account is used for other things, be aware of those implications for file rights.

1 Like

I don’t think it will “break things”. I’m still pretty new to the homelab world, but have plans for some more self-hosted services down the road. I don’t really know what issues it may cause in the future.

Ultimately, I would like my smb share to be accessible from my phone, my wife’s phone, her macbook etc for family cloud storage. Also, I may lean more into using some linux VMs for testing or playing around with. In reality, I may only use it for manually reading and writing to the share from those non-windows devices, not for syncing. I only really want the sync working from my personal PC to my nas as a pseudo-backup, and also cloud access to my files.

The user I created (sync_user) will only be used to access the NAS, either by a sync utility, or via mapped SMB network drive in windows. It would never be used for anything else. That was my thought process and why I created a standalone user for this task.

If you’re going to be mixing OSes and filesystems (like I do) you will likely be happier if you use Ignore Permissions (like I do).

1 Like

Honestly, that is a good enough answer or me. I’ll try that and see if that fixes it.

Thank you.

That worked.

Jesus Christ.

I’ve literally spent hours and days trying to make this work. I knew that was an option, but I didn’t quite grasp its implications. I should have just asked the question here first.

Noted.

Thanks for the advice.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.