UGREEN UGOS / Docker: Syncthing watcher “permission denied” while scan/sync works — root cause was host ACL blocking inotify

[Vadorequest]

Hi,

Following up from my original thread here: (closed, can’t reply)

Syncthing watcher fails on folder with error while traversing: permission denied, but scan/sync works fine in Docker

I know this issue is related to my own setup, but I’ve already tried debugging it myself and couldn’t find a good explanation. After digging a lot by myself (and AI) I wonder if other people might have a clue. Hi, I am running Syncthing in Docker on a UGREEN NAS (UGOS, accessed via SSH as root). The Syncthing image is lscr.io/linuxserver/syncthing:latest. I have setup quite a few syncs on various devices. All work fine except one. I have this one specific folder that syncs correctly, but th…

I found the root cause on my setup:

• NAS: UGREEN DXP4800 Plus
• OS: UGOS
• Syncthing running in Docker
• Symptom: normal scan/sync worked, but filesystem watcher failed with:

error while traversing /some/folder: permission denied

At first someone suspected inotify limits, but that was not the issue. The limits were already high, and the affected folder did not contain many directories.

The useful test was running inotifywait as the same UID used by the Syncthing process inside the container:

docker exec syncthing-container sh -c '
s6-setuidgid abc sh -c "
  id
  inotifywait -r -t 5 /path/inside/container
  echo inotify_exit_code:\$?
"
'

This failed with:

Couldn't watch /path/inside/container: Permission denied

So the problem was not Syncthing itself: Linux inotify could not watch the folder.

On the UGOS host, the shared folder looked accessible in the UGOS UI, but the underlying Linux ACL was missing proper access for the UID running Syncthing in Docker.

The fix was to grant that UID explicit ACL access on the host folder:

setfacl -Rm u:<UID>:rwX "/path/to/host/shared-folder"

After that, inotifywait reported:

Watches established.

and Syncthing’s filesystem watcher started working.

I did my analysis with AI (ChatGPT), to track down the root issue, it also recommended to run:

find "/path/to/host/shared-folder" -type d -exec setfacl -m d:u:<UID>:rwX {} +

But I’m not sure if that’s a good idea, I don’t understand these things very well and I’m concerned whether it could affect UGOS’s way of doing things.

Also, as I have several users with their own Syncthing server/config that will eventually sync this particular shared folder, I expect to have to run this “fix” for several ACL users. And I clearly can’t foresee the consequences, any advise on this would be appreciated!

One remaining question: does anyone know why UGOS can show the user as having Read/Write access in the UI, while the underlying Linux ACL does not expose enough permission for inotify? I have seen mentions that UGREEN/UGOS handles ACLs in a non-standard or opaque way, so maybe this is expected behavior, but I would appreciate clarification.

Hope this helps other UGOS / UGREEN NAS users who see watcher errors while scan/sync still works.

P.S : Also, despite the error message on the Syncthing GUI, I hadn’t actually experienced issues, decided to go down the rabbit hole to fix it out of habit, but not sure what it fixed for real. Maybe change detections that I couldn’t notice.