I have a silly problem and I just can’t figure it out.
I have two hosts running syncthing:
One is a linux container on proxmox with a mounted folder called pictures. The other one is a docker container that is running on a QNAP NAS also with a folder called pictures.
Both hosts must do two way sync such that at any point the content is the same on both.
As it is now, it sort of happens in the sense that if I add pictures to the host on the QNAP, they get synced to the other host but the only things I can see on that other host with the syncthing user is the folders. The files receive different permission and I can only see them with root.
My question is: how can I sync the files and folders such that I can see them with a regular user on both hosts?
on the syncthing running in the linux container on proxmox, the umask of the syncthing user is 0022. I read that you can set different permissions by editing the systemd service and adding a different umask. I have done that and added 0022 which is (if I understand it correctly) equivalent to 755 permissions.
But that resulted in a 000 permission set on a newly synced file and weirdly on the syncthing database.
So to clarify, I have the following two hosts:
Host A: syncthing docker container running in QNAP NAS on container station.
Host B: syncthing running in a linux lxc container under proxmox.
The permission problem I have is in Host B so far.
Actually, the effective permissions could be 755, but it could also be something entirely different…
Note that umask is short for “user mask”, which sort of acts like a filter that subtracts from the default permissions defined by the ACL (Access Control List).
So, if the default permission is 777, a 022 umask would indeed result in 755 when a new file is created.
However, for security (e.g. reduce the chances of inadvertently executing a rogue script/program) plus other reasons, the default permission is rarely 777. It’s more often 644 / -rw-r--r-- (i.e. read/write user, read-only group, read-only others) or 640 / -rw-r----- for more default privacy.
Use the getfacl and setfacl commands to view and change the default permissions for a directory or file.
setfacl can also be used to grant extended permissions on a per-user and/or per-group basis independent of the basic permissions shown by ls.
On a Linux system, the location defaults to one of two paths depending on the version of Syncthing and when the config was initialized (once created, Syncthing doesn’t move its files).
i see that all the files created by syncthing appear to be stored in the .config dir in the home of the syncthing user. i’ll copy those and reinstall the container
sorry to bother you again. i copied those files over but the new syncthing install refuses to start now. here is what systemctl status says:
# systemctl status syncthing@syncthing.service
x syncthing@syncthing.service - Syncthing - Open Source Continuous File Synchronization for syncthing
Loaded: loaded (/lib/systemd/system/syncthing@.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Tue 2024-09-17 06:40:45 UTC; 2s ago
Duration: 1ms
Docs: man:syncthing(1)
Process: 1038 ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0 (code=exited, status=226/NAMESPACE)
Main PID: 1038 (code=exited, status=226/NAMESPACE)
CPU: 1ms
Sep 17 06:40:45 luxsync systemd[1]: syncthing@syncthing.service: Scheduled restart job, restart counter is at 4.
Sep 17 06:40:45 luxsync systemd[1]: Stopped syncthing@syncthing.service - Syncthing - Open Source Continuous File Synchronization for syncthing.
Sep 17 06:40:45 luxsync systemd[1]: syncthing@syncthing.service: Start request repeated too quickly.
Sep 17 06:40:45 luxsync systemd[1]: syncthing@syncthing.service: Failed with result 'exit-code'.
Sep 17 06:40:45 luxsync systemd[1]: Failed to start syncthing@syncthing.service - Syncthing - Open Source Continuous File Synchronization for syncthing.
and here is what journalctl -xe says:
# journalctl -xe
--
-- The job identifier is 2057.
Sep 17 06:40:44 luxsync (yncthing)[1038]: syncthing@syncthing.service: Failed to set up mount namespacing: Permission denied
Sep 17 06:40:44 luxsync (yncthing)[1038]: syncthing@syncthing.service: Failed at step NAMESPACE spawning /usr/bin/syncthing: Permission denied
-- Subject: Process /usr/bin/syncthing could not be executed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The process /usr/bin/syncthing could not be executed and failed.
--
-- The error number returned by this process is 13.
Sep 17 06:40:44 luxsync systemd[1]: syncthing@syncthing.service: Main process exited, code=exited, status=226/NAMESPACE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit syncthing@syncthing.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 226.
Sep 17 06:40:44 luxsync systemd[1]: syncthing@syncthing.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit syncthing@syncthing.service has entered the 'failed' state with result 'exit-code'.
Sep 17 06:40:45 luxsync systemd[1]: syncthing@syncthing.service: Scheduled restart job, restart counter is at 4.
-- Subject: Automatic restarting of a unit has been scheduled
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Automatic restarting of the unit syncthing@syncthing.service has been scheduled, as the result for
-- the configured Restart= setting for the unit.
Sep 17 06:40:45 luxsync systemd[1]: Stopped syncthing@syncthing.service - Syncthing - Open Source Continuous File Synchronization for syncthing.
-- Subject: A stop job for unit syncthing@syncthing.service has finished
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A stop job for unit syncthing@syncthing.service has finished.
--
-- The job identifier is 2115 and the job result is done.
Sep 17 06:40:45 luxsync systemd[1]: syncthing@syncthing.service: Start request repeated too quickly.
Sep 17 06:40:45 luxsync systemd[1]: syncthing@syncthing.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit syncthing@syncthing.service has entered the 'failed' state with result 'exit-code'.
Sep 17 06:40:45 luxsync systemd[1]: Failed to start syncthing@syncthing.service - Syncthing - Open Source Continuous File Synchronization for syncthing.
-- Subject: A start job for unit syncthing@syncthing.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit syncthing@syncthing.service has finished with a failure.
--
-- The job identifier is 2115 and the job result is failed.
now that it is all done I think the problem was with the lxc container and the fact that it was unprivileged. I have tried to map the users but I probably didn’t do a very good job.
Now I switched to a priviledged container and is all good.