A Syncthing permission error usually means the running Syncthing process cannot reach or write one part of the folder path. First check the mounted disk or share, the account and groups used by the running process, and—when using Docker—the path visible inside the container. Start with the read-only checks below; do not use chmod 777 as the fix.
Start here when Syncthing access is denied on Linux or Docker
Use this quick path before changing any permissions. The goal is to find the first place where the running process loses access: the mount, a parent directory, its numeric user or groups, or the path Syncthing sees.
Using Windows? This Linux diagnostic does not apply. Use Syncthing's Windows startup and service guidance to identify the account running Syncthing, then determine whether the error comes from the synced folder, the file watcher, or the updater.
Check
Command
What to fix
System service: which groups does the running process have?
pid=$(systemctl show UNIT -p MainPID --value); [ "$pid" -gt 0 ] && grep -E "^(Uid|Gid|Groups):" /proc/$pid/status
Replace UNIT with the exact system service name.
User service: which groups does the running process have?
pid=$(systemctl --user show UNIT -p MainPID --value); [ "$pid" -gt 0 ] && grep -E "^(Uid|Gid|Groups):" /proc/$pid/status
Run this while logged in as the account that owns the user service. Docker uses the separate process steps below.
Can the group write the folder?
stat -c "%U %G %a %n" /srv/sync/notes
Use shared group ownership plus directory mode 2775 when multiple services write.
Do new files inherit write access?
getfacl /srv/sync/notes
Configure the app to keep group write—for example with umask 0002—or add an inherited access rule when new files keep landing as 0644.
Runs in your browser
Syncthing permission diagnostic
Replace the example values with observations from your machine. The diagnostic separates a missing mount or .stfolder safety warning from a process-group, path-mapping, watcher, or new-file permission problem. It gives read-only checks before suggesting a change.
Example values are shown
Replace the examples with values from your machine, then select Diagnose this folder. No values leave this page. Review folder paths and group names before sharing a copied report.
For a systemd service, check the groups held by the running Syncthing process
Adding an account to a Linux group changes the account database, but an already-running service can keep its old group list. That is why id syncthing may look correct while Syncthing still gets permission denied.
For a system service, find the exact unit with systemctl list-units '*syncthing*'. For a user service, run systemctl --user list-units '*syncthing*' while logged in as the account that owns it.
Read that unit's MainPID, then inspect Uid, Gid, and Groups in /proc/$pid/status.
If the required group is missing, add it and refresh the correct runtime. A system service can restart its confirmed unit. A user service may keep the old user-manager groups after a unit-only restart; save work and follow distribution-specific steps to fully recreate that user's login session and user manager, then inspect the new process.
UID and GID are the numeric user and group IDs Linux uses for permission checks. Supplementary groups are the additional groups the running process can use.
Docker has two different path views. The host might mount /volume1/photos into the container at /var/syncthing/photos. Syncthing's GUI must use the container path—or a folder below it—not the host path.
If Syncthing reports “Up to Date” but the NAS host folder stays empty, confirm the container mount first. A valid-looking path inside the container can point at its private filesystem instead of the intended NAS share.
Use the diagnostic above to compare all three values. Then resolve both container paths with readlink -f, because a symlink or a more specific nested mount can change where a path really leads.
When a full scan works but the file watcher gets permission denied
A full scan and the Linux file watcher use different operations. A successful scan proves Syncthing can read the files it reached; it does not prove the watcher can register the failing directory and the directories within that watched tree. Linux calls this watcher interface inotify; path ancestors must still allow traversal.
Result
What it means
Next check
Watches established, then timeout
Watcher registration succeeded; no matching event happened during the short test.
Reproduce the file change and inspect Syncthing's watcher log.
Permission denied
The process could not watch the target or one of its parent directories.
Check the running process groups, each parent directory, ACLs, and security labels.
No space left on device
The inotify watch limit may be exhausted; this message does not necessarily mean the disk is full.
Inspect current inotify usage and limits before raising them.
The diagnostic prepares an optional, short, non-recursive inotifywait check for the exact directory you enter. Success proves only that directory registered; it does not prove the entire synced tree can be watched. The command does not disable the watcher, change ACLs recursively, or raise system limits.
What .stfolder protects
Syncthing uses .stfolder as a health marker for the configured folder. When the marker disappears, Syncthing stops the folder rather than assuming that every missing local file was intentionally deleted.
Failed to create folder marker: mkdir /data1/.stfolder: permission denied
Failed initial scan of sendreceive folder
folder marker missing (this indicates potential data loss)
A marker error can mean the process lacks write access, but it can also mean a disk is unmounted, a bind mount points at the wrong location, the configured path moved, or the storage is read-only. Reinstalling Syncthing does not repair those host conditions.
Safe folder-marker recovery order
Run findmnt -T /path and confirm the expected filesystem is mounted.
List the folder and confirm the original files are present before changing the marker.
Check every parent directory with namei -l /path.
Test read and write access as the actual service user or inside the actual container.
After the path is confirmed healthy, restart or rescan first. Removing and re-adding the folder resets its local database state and merges it as a newly added folder; use that only as a documented last resort after a backup.
Do not create .stfolder just to silence the warning before checking the mount. The marker is a data-loss guard, not an ordinary cache directory. Resuming against an empty or wrong path can turn locally missing files into propagated deletions.
Ignore Permissions is different. It controls whether Syncthing applies synchronized permission bits. It does not grant read, write, or traversal access to a host directory.
The problem: multiple services write to one Syncthing share
A common home-server or small-team setup has one host folder mounted into several containers. Syncthing syncs files, Samba exposes the folder to a network share, FileBrowser edits the same files through a web UI, and another service reads or writes generated content. Each service may run as a different user inside the container, and each bind mount maps that user back to a host UID and GID.
The first "permission denied" failure often appears after the folder seems to work. One service creates a file, another service can read it, but cannot edit it. A directory exists and looks correct, but a container cannot create a new file inside it. A user runs chmod -R 777 and the error disappears for a while, then returns when a new file is synced or created.
Give every trusted app the same shared group and make new files keep group-write access. That fixes the cause without opening the folder to every local process.
Two common problems when several apps share one folder
Docker PUID/PGID mismatch
Many container images let you set PUID and PGID. If Syncthing runs as one host identity, FileBrowser runs as another, and Samba uses a third, they may all see the same path but not share write permission. The folder may be owned by UID 1000 while a gateway or helper service writes as UID 10000. That mismatch is enough to make one service fail even when the bind mount itself is correct.
Why new files are often 0644
A common umask 0022 makes new files appear as 0644. That means owner read/write, group read-only, and others read-only. If another container is only in the group, it can read but cannot write. A stricter umask 0077 creates private files such as 0600, which can block group and other services entirely. Use the Umask Calculator to see how 0022, 0002, 0027, and 0077 affect new files and directories.
Syncthing error messages and symptoms
Symptom
What it usually means
First thing to check
Failed to create folder marker ... .stfolder: permission denied
The running process cannot create an entry, or the mounted storage is read-only.
Check the mount, actual process UID/GID, parent traversal, and directory write access.
folder marker missing
The marker disappeared, the folder moved, or the expected filesystem is not mounted.
Confirm the filesystem and original files before allowing marker recovery.
Failed initial scan or stat ... permission denied
Syncthing cannot read or traverse the folder, a parent directory, or a child entry.
Run namei -l and test access as the real service or container user.
Operation not permitted
An inherited ACL, SELinux rule, read-only filesystem, Syncthing Sync Ownership request, or network-share rule may block the exact operation.
Read the full log line first: a failed write, rename, chmod, or chown operation needs a different next check.
Permission denied when a container writes to the share
The container user does not own the folder and lacks group-write permission.
Compare the container's UID/GID with host folder owner and group.
New files are created as 0644
umask 0022 removed group-write and other-write from the regular-file default.
Check whether the app should use umask 0002 so new files keep group write.
New directories are 0755
Group members can enter the directory but cannot create or modify files inside it.
Use a shared group plus group-write and setgid on the directory.
One service can create files, another cannot modify them
Ownership and mode bits favor the creator, not the shared service group.
Inspect the new file with stat and getfacl.
chmod 777 works temporarily
The underlying identity and creation-default problem was not fixed.
Replace it with shared group, setgid, umask, and default ACL rules.
Why it happens
Linux permission checks combine user identity, group identity, mode bits, directory traversal, and optional ACL entries. In a simple shell session, you can often reason about one user and one group. In a containerized Syncthing share, each service may be a different process identity even when it points at the same host path.
The uid decides whether a process is treated as the owner of a file. The gid decides whether it belongs to the file's group. The mode decides whether owner, group, and others have read, write, and execute rights. Directory execute permission means the ability to enter or traverse the directory. Directory write permission means the ability to create, remove, or rename entries inside it.
The setgid bit on a directory changes one important part of this model: files and subdirectories created inside inherit the directory's group. That is useful for shared folders, but setgid does not make new files group-writable by itself. If the creator's umask still removes group write, files can still land as 0644.
What chmod and umask actually do
chmod changes permissions on existing files and directories. Use the Chmod Calculator or Linux permissions calculator hub when you need to check 2775, 0664, 0644, or another explicit mode before copying a command.
umask controls default permissions for future files and directories created by a process. For example, umask 022 usually creates files 644 and directories 755. If you need shared group writes, umask 0002 is often the value to test because it commonly creates files as 0664 and directories as 0775.
Use this order only after the read-only checks identify a group-sharing problem. Do not start by making the folder writable by everyone.
Step
Command or setting
Why it matters
1. Create or choose a shared group
file-share or another service group
Every writer needs a common group identity on the host.
2. Put service users in that group
usermod -aG file-share user
Membership lets services use the group permission bits.
3. Set group ownership on the folder
chgrp file-share /srv/sync/notes
Start with the shared-folder root. Inspect existing children before changing ownership recursively.
4. Keep the shared group on new items
chmod 2775 /srv/sync/notes
New children inherit the shared group instead of the creator's primary group.
5. Let the shared group write new items
UMASK=002 or umask 0002
Files can be created as 0664 and directories as 0775 instead of 0644/0755.
6. Add an inherited access rule when needed
setfacl -d -m g:file-share:rwx /srv/sync/notes
Default ACLs can keep inherited group permissions when a container has no useful UMASK setting.
Example command sequence
Adjust the group name, service users, and path to match your host. Run the read-only checks first and take a backup before changing a large existing tree. These commands change only the shared-folder root; inspect child files separately so you do not remove executable bits or overwrite intentional private permissions.
If a service supports PUID, PGID, or a UMASK setting, set those values so the container uses the same host user, group, and file-creation defaults. If it does not, use a default ACL to keep new files editable by the shared group.
After changing group membership: restart a confirmed system service or container, then read the new process's Gid and Groups. For a systemd user service, a unit-only restart may inherit the user manager's old groups. Save your work and use distribution-specific steps to fully recreate that user's login session and user manager, including any lingering setup; do not terminate a user's session blindly.
Container notes for Syncthing, Samba, and FileBrowser
Syncthing: check which user owns the synchronized files on the host. Syncthing can create files that other services can read but not modify if the group write bit is missing.
Samba: SMB clients may write through a mapped Unix user. Confirm the host-side user and group, not only the username shown to the client.
FileBrowser: web edits happen as the process identity inside the container. Match its host UID/GID or make sure it is in the shared group.
Docker Compose: keep the bind-mounted path, PUID, PGID, and service-level umask together so every service uses the same IDs and file-creation defaults.
Verification checklist
After changing permissions, verify the user, group, mode, and inherited ACL with commands that show the actual host values.
Check
Command
What you want to see
Running service identity
grep -E "^(Uid|Gid|Groups):" /proc/PID/status
The running process—not only the account database—has the expected filesystem UID/GID or shared group.
Folder owner, group, and mode
stat -c "%U %G %a %n" /srv/sync/notes
The group is shared and directory mode includes setgid, such as 2775.
Default ACL
getfacl /srv/sync/notes
Entries such as group:file-share:rwx and default:group:file-share:rwx, plus a mask::rwx that does not reduce them. Check any #effective: annotation.
Cross-service write
Create from one service, edit from another.
The second service can modify or replace the file without chmod 777.
Why chmod 777 is the wrong long-term fix
chmod 777 often appears to solve a shared folder because it gives owner, group, and others read, write, and execute permission. It also gives unrelated local users and processes write access. On a real host, that is a broad security tradeoff for a problem that usually has a narrower cause.
If someone already changed the folder to 777 and the error disappeared, restore a narrow mode promptly and use that history only as a clue. Do not set 777 just to test: the read-only identity, path, and access checks above can locate the failure without opening the folder to every local process.
When to use chmod, umask, setgid, or ACL
Use chmod
When an existing file or directory has the wrong mode, such as changing a shared folder to 2775 or existing files to 0664.
Use umask
When a service can be configured to create future files with group-write enabled, such as UMASK=002.
Use setgid
When new files and directories should inherit the shared folder's group.
Use default ACL
When you need inherited group permissions but one or more writers cannot be trusted to set the right umask.
Choose the next page for your result
Continue only with the page that matches what the checks found.
Last verified July 16, 2026. This troubleshooting flow targets Syncthing on Linux or in a Linux container. Syncthing's Ignore Permissions option controls synchronization of permission bits; it does not give the Syncthing process write access to a host directory it cannot already access.
Why does Syncthing say access denied on Linux or Docker?
First identify the account and groups used by the running Syncthing process. Then confirm it can pass through every path ancestor and access the exact Folder Path. In Docker, also verify that the Folder Path resolves inside the mounted container destination.
What is the difference between 0644 and umask 0022?
0644 is the mode on a file after it has been created. umask 0022 is a creation mask. In common Linux file creation, files start from 0666; 0022 removes group-write and other-write, so the result is 0644.
Does setgid affect file permissions?
Setgid on a directory affects group inheritance. It does not automatically make a new file group-writable. A file can inherit the right group but still be 0644 if the creating process uses umask 0022.
Why doesn't changing umask fix every container?
Some containers do not expose a UMASK variable, some ignore the shell mask, and some applications create files with explicit private modes. A PUID/PGID mismatch can also block writes even when the umask looks correct.
When should I use ACLs instead of chmod?
Use default ACLs when future files need inherited group write permission and at least one writer cannot be configured to create group-writable files. ACLs are especially useful for mixed Syncthing, Samba, FileBrowser, and Docker Compose setups.
Is chmod 777 safe for Syncthing shared folders?
No as a normal setup, and you do not need to set it just to diagnose the error. It grants every local identity write access. Use the read-only identity, path, group, and mode checks above to locate the failing layer.
How do I verify the group and ACL on a shared folder?
Read Uid, Gid, and Groups from the running process's /proc/PID/status, then use stat and getfacl on the exact folder. For ACLs, check both the group entry and mask:: or any #effective: value. id USER is only a secondary account-level check.
Why can one container create files but another cannot edit them?
The creator may own the file, while the second container only has group or other permissions. If the file is 0644, group members can read but cannot write. Make the folder group-owned, setgid, and group-writable for future files.
Why does Syncthing fail to create .stfolder with permission denied?
The actual Syncthing process cannot create an entry in the configured folder. Confirm the service or container UID and GID, parent-directory traversal, directory write access, and whether the underlying mount is writable.
Is it safe to create a missing .stfolder manually?
First verify that the original filesystem is mounted, the configured path is correct, and the expected files are present. Follow Syncthing's documented recovery procedure. Removing and re-adding a folder resets its local database state and merges it as a new folder, so use that only as a backed-up last resort.
Does Ignore Permissions fix Syncthing access denied?
No. Ignore Permissions changes whether Syncthing applies synchronized permission bits. It does not grant the running process read, write, or traversal access to a host folder.
Why is Syncthing up to date while the NAS host folder is empty?
In Docker, Syncthing may be writing to a valid path in the container's private filesystem instead of the intended bind mount. Compare the host source, container destination, and Syncthing Folder Path; the Folder Path must be the destination or a folder below it.
Why does a full scan work while the file watcher gets permission denied?
A full scan and the Linux watcher perform different operations. Test the exact failing directory, then check the real process groups, traversal on path ancestors, directories inside the watched tree, ACLs, and SELinux rules. One successful root-directory test does not prove the full tree.
Does this apply to macOS?
The chmod and umask concepts also apply on macOS, but the Linux setfacl and getfacl commands are not the same on every macOS setup. Treat the ACL section as Linux-focused unless your filesystem and tools support compatible POSIX ACL commands.