Key conclusion: if Syncthing can read a folder but cannot propagate deletes or modifications, test write permission from inside the Syncthing container. A readable bind mount is not automatically writable.
Check folder mode first
A bidirectional folder should use Syncthing folder modes appropriate for receiving changes. Send Only will not behave like Send & Receive.
Prove the container can write
docker exec -it syncthing sh
touch /DATA/Gallery/.write-test
rm /DATA/Gallery/.write-testIf either command fails, fix storage permissions before changing Syncthing settings.
Match PUID and PGID
The official CasaOS Syncthing compose passes PUID/PGID and binds /DATA into the container. LinuxServer explains PUID/PGID ownership for host volumes.
docker exec syncthing id
stat -c '%u:%g %a %n' /DATA/GalleryCompare numeric IDs. Renaming ownership to a username is not enough if the container runs under a different UID/GID.
Deletes need parent-directory rights
Removing or renaming a file requires write and execute permission on the parent directory. That explains why read/sync can appear partly functional while remote deletes fail.
Compare a working folder
Compare docker inspect syncthing mounts, stat mode/UID/GID, ACLs with getfacl, filesystem read-only state, and ignore patterns. Do not jump to chmod 777.
The CasaOS Syncthing setup gives a clean baseline. The ZimaOS app platform helps compare alternatives, while ZimaCube 2 fits multi-drive storage workloads.
Check ACLs when Unix mode bits look correct
Traditional chmod output can look fine while an ACL still changes effective permissions. Compare a working and failing directory:
getfacl /DATA/Gallery
getfacl /DATA/DocumentsIf one path contains extra ACL entries, fix those intentionally rather than recursively opening permissions everywhere.
Check whether the filesystem is read-only
findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /DATA/GalleryA disk mounted ro, filesystem errors, or a degraded external drive can produce the same “can read but cannot change” symptom. If the mount itself is read-only, changing Syncthing settings cannot fix it.
Read the Syncthing error behind “out of sync”
Open the Syncthing web UI and inspect the folder error, then compare container logs:
docker logs --tail 200 syncthingLook for permission denied, operation not permitted, path-not-found errors, or failed rename/delete operations. “Out of sync” is a state; the log usually contains the lower-level filesystem cause.
Do not use Ignore Permissions as a universal fix
Ignoring permission metadata can help when two filesystems represent Unix mode bits differently, but it does not grant write permission to the process. If the container cannot delete a test file, changing Syncthing's permission-metadata behavior will not make the host directory writable.
Use a controlled write test
Create a small disposable directory, map it into Syncthing, and verify create → edit → rename → delete from both devices. Once that works, apply the same ownership and mount pattern to the real folder. This isolates sync behavior from a complicated existing directory tree.
FAQ
Why can Syncthing add but not delete?
Parent directory permissions can allow reading but block rename/delete operations.
Should I use chmod 777?
No. Prove the failing path and container identity first.
