# Not synchronized folders
**URL:** https://forum.syncthing.net/t/not-synchronized-folders/20777
**Category:** Support
**Created:** [September 10, 2023, 10:38am UTC](https://forum.syncthing.net/t/not-synchronized-folders/20777 "2023-09-10T10:38:23Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@socke7](https://forum.syncthing.net/u/socke7)
#### Post date: [September 10, 2023, 10:38am UTC](https://forum.syncthing.net/t/not-synchronized-folders/20777/1 "2023-09-10T10:38:23Z")
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!
---
### Author:  [@gadget](https://forum.syncthing.net/u/gadget)
#### Post date: [September 10, 2023, 11:26pm UTC](https://forum.syncthing.net/t/not-synchronized-folders/20777/2 "2023-09-10T23:26:11Z")
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).
---
### Author:  [@socke7](https://forum.syncthing.net/u/socke7)
#### Post date: [September 11, 2023, 3:52pm UTC](https://forum.syncthing.net/t/not-synchronized-folders/20777/3 "2023-09-11T15:52:23Z")
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?
---
### Author:  [@gadget](https://forum.syncthing.net/u/gadget)
#### Post date: [September 11, 2023, 4:33pm UTC](https://forum.syncthing.net/t/not-synchronized-folders/20777/4 "2023-09-11T16:33:09Z")
> [@socke7](#):
>
> 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?
`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:
```plaintext
ps -ef | grep syncthing
```
Display the ownership of the directory that’s failing to sync:
```plaintext
ls -l /path/to/some/directory
```
> [@](#):
>
> Also should Syncthing run from an elevated user account?
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.
---
### Author:  [@socke7](https://forum.syncthing.net/u/socke7)
#### Post date: [September 11, 2023, 5:00pm UTC](https://forum.syncthing.net/t/not-synchronized-folders/20777/5 "2023-09-11T17:00:16Z")
`
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
`
---
### Author:  [@gadget](https://forum.syncthing.net/u/gadget)
#### Post date: [September 11, 2023, 9:00pm UTC](https://forum.syncthing.net/t/not-synchronized-folders/20777/6 "2023-09-11T21:00:22Z")
> [@socke7](#):
>
> `
> 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
> `
So Syncthing is running as user `hc1` (and most likely in the `users` group).
By the way, the `stat` command provides even more details:
```plaintext
stat backup
```
> [@](#):
>
> `
> ls -l
> drwxrwsrwx+ 15 root users 4096 May 18 2021 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`:
```plaintext
chown -R hc1:users backup
```
Next, should also fix the permissions even if it’s a private system. The following blanket change will work…
```plaintext
chmod -R 755 backup
```
… but I think this would be better:
```plaintext
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)
---
### Author:  [@socke7](https://forum.syncthing.net/u/socke7)
#### Post date: [September 12, 2023, 3:21pm UTC](https://forum.syncthing.net/t/not-synchronized-folders/20777/7 "2023-09-12T15:21:50Z")
This worked for me! I even learned something from it. Thank you, very much for your help - you are awesome!
---
### Author:  [@gadget](https://forum.syncthing.net/u/gadget)
#### Post date: [September 13, 2023, 2:01am UTC](https://forum.syncthing.net/t/not-synchronized-folders/20777/8 "2023-09-13T02:01:29Z")
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.)_
---
### Author:  [@system](https://forum.syncthing.net/u/system)
#### Post date: [October 13, 2023, 2:01am UTC](https://forum.syncthing.net/t/not-synchronized-folders/20777/9 "2023-10-13T02:01:59Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.