Hi, I’ve been using Syncthing for a few years now and I really like it. However, recently I did a fresh setup of my mini server running Armbian. From this date I don’t get two of my folders synchronized. The error message on each of the files is:
syncing: handling dir (setting permissions): chmod “path and filename”: operation not permitted
Thanks for any help in advance!
That error message means Syncthing doesn’t have sufficient permission to modify the destination file/directory.
With a recent fresh setup, chances are that some of the file/directory permissions got a little mixed up.
If there are other Syncthing folders that are syncing without error, compare the file/directory ownership between the one that’s working and the one that’s not.
Also, if syncing permissions is enabled in Syncthing, elevated privileges might be required. For example, if device A sends a file owned by 1001:1002 (user:group) to device B, and Syncthing on device B isn’t running under the same user and group IDs, then Syncthing cannot set the user:group to 1001:1002 without root privileges (or something else suitable).
Thanks for your comprehensive explanation. However, I need some further help as I’m not very familiar how Linux is handling access rights: I did a chmod -R 777 for my folder, so Syncthing did a rescan but after all it didn’t help. My more general question would be, what is the best practice for setting folder rights and owners? Also should Syncthing run from an elevated user account?
chmod -R 777 /path/to/some/directory basically says “Recursively set the read/write/execute permissions on all subdirectories and files so that the owner, group and other system users can modify/delete anything under the target directory”.
So although a chmod -R 777 would allow Syncthing to create/delete/change files, it wouldn’t allow Syncthing to change the ownership of a file/directory – e.g., if Syncthing is running as user:group syncthing:apps it cannot set the user:group of a file/directory to joe:users, jane:student, or anything else other than syncthing:apps.
On Un*x/Linux, only a user with elevated privileges can assign arbitrary user:group ownership to a file/directory.
I don’t know that there’s a general best practice with regards to setting folder rights and owners because each usage scenario is different. But the #1 rule is to assign the least amount of privileges required. For Syncthing, best practice is to have both Syncthing running under the same user who owns the files/directories being managed by Syncthing.
Without more info about your Armbian system, it’s difficult to provide a specific fix. At the very least, we need to figure out what user is Syncthing running under and what the file/directory ownership is for the Syncthing folders.
Display some basic details about the Syncthing process:
ps -ef | grep syncthing
Display the ownership of the directory that’s failing to sync:
ls -l /path/to/some/directory
Generally speaking, it’s not a good idea on any platform. There are some niche scenarios (e.g., a private network) where it might be okay, but best to avoid it whenever possible.
Although it would work around the permissions issue, it’s the nuclear solution and would create potential security and other issues.
ps -ef | grep syncthing
hc1 1400 1 0 Sep10 ? 00:02:36 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0
hc1 1604 1400 12 Sep10 ? 04:00:39 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0
root 20775 17742 0 18:43 pts/0 00:00:00 grep syncthing
ls -l
drwxrwsrwx+ 15 root users 4096 May 18 2021 backup
So Syncthing is running as user hc1 (and most likely in the users group).
By the way, the stat command provides even more details:
stat backup
Your backup directory is currently owned by root (a little unusual that the group isn’t root).
So at a bare minimum, change the ownership to user hc1 and group users:
chown -R hc1:users backup
Next, should also fix the permissions even if it’s a private system. The following blanket change will work…
chmod -R 755 backup
… but I think this would be better:
find backup -type d -exec chmod 700 {} \;
find backup -type f -exec chmod 600 {} \;
First command finds every directory (under and including backup) and sets the permissions mode to 755 (RWX for the owner, nothing for the group and others.)
Second command finds every file under backup and sets the permissions mode to 644 (RW for the owner, nothing for the group and others).
(R = Read, W = Write, X = Execute)
This worked for me! I even learned something from it. Thank you, very much for your help - you are awesome!
You’re welcome. Glad I could help. 
(I noticed that I wrote 755 and 644 for the octets in the description even though my example command said 700 and 600. Both versions are valid, but 700 and 600 limit access to just the owner for better security.)