Just getting started with Syncthing. I have it installed as a docker app using Linuxserver’s image. The server that it is on also runs a few other docker apps, and my goal is to back up these settings and files. Most of my docker configs and special volumes are stored in /appdata/, and I am trying to leverage Syncthing to backup this folder to my Linux NAS (another machine).
I am getting some “Permission denied” errors on some of the files/folders after the first sync, because some files and folders are owned by root or some special users (say, 70). The files are owned by these users based on how the docker apps are set up.
What is the recommended approach for me to get Syncthing to successfully back up these files, without breaking the various docker apps?
You’ll have to grant Syncthing better access, somehow. Options include giving read access to the files to the user Syncthing is running as (through ACLs or regular permission bits) or giving the Syncthing extra capabilities (CAP_DAC_OVERRIDE should let it slide past file permissions in general). Exactly how to do the latter depends on what the Docker image does and I don’t know their image well. With our image, it can be set using an environment variable. Running the Syncthing process as root is also an option, though it’s more of a sledgehammer approach and not generally recommended.
Thanks. I ended up doing chmod -R o+r to all the problematic directories/files so they are readable, and find ./ -type d -exec chmod o+x '{}' \; to set directories to be executable. Not perfect, but good enough for now.
If the server is running Ubuntu, Fedora, RHEL/CentOS or other relatively recent Linux distribution, the bindfs module for FUSE (https://bindfs.org/) should be in its default repository.
To use bindfs, if for example Syncthing is running as a dedicated user “syncthing” in the group “syncthing” and you want it to be able to access everything under your /appdata/ directory, issue the following command:
(The user, group, and mount point /mnt/Syncthing can be adjusted for whatever is most suitable for your environment.)
Everything in, and including the mount point, will be virtually owned by syncthing:syncthing with read/write/execute permissions on all directories and files.
And for an optional extra measure of safety, the “-o ro” makes it all read-only – no chance for accidentally deleting any files with a configuration mistake in Syncthing.
Did you mean the .stfolder marker? If so, a mkdir /appdata/.stfolder once will take care of it, then bind mount. Syncthing only needs write access if it doesn’t exist yet and then doesn’t (currently) do anything else with it.
Alternatively from the Syncthing FAQ:
How do I serve a folder from a read only filesystem?
Syncthing requires a “folder marker” to indicate that the folder is present and healthy. By default this is a directory called .stfolder that is created by Syncthing when the folder is added. If this folder can’t be created (you are serving files from a CD or something) you can instead set the advanced config Marker Name to the name of some file or folder that you know will always exist in the folder.
Thanks for explaining .stfolder. I will revert back to a read-only mount.
Just to confirm, on my other server that is receiving the files, I’ve turned on versioning of files, which I believe store files in .stfolder. However that shouldn’t be a concern since the files are on a different server, not on this read-only mount and server.
Yup, versioning only requires write-access on the receiving side, and it’s actually a different hidden directory named .stversions under each subdirectory while there is only a single .stfolder at the root of the shared directory.