Errors when runing syncthing as service, while not as root; enabling CAP_DAC_READ_SEARCH neccessary?

Support
1

When running syncthing with a system also running samba, I get (a lot of) these errors:

2026-06-22 21:54:16 WRN Failed to scan (path="[PATH]" error="scan: reading platform data: get xattr [FULLPATH]: Lgetxattr [FULLPATH] "user.DOSATTRIB": permission denied" folder.label=Foto's folder.id=[FOLDERID] folder.type=sendreceive log.pkg=model)

I can’t get passed it, even using this override:

### Editing /etc/systemd/system/syncthing@root.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file

CapabilityBoundingSet=CAP_CHOWN CAP_FOWNER CAP_DAC_READ_SEARCH

### Edits below this comment will be discarded

In the end I changed it in the original /etc/systemd/system/syncthing@root.service-file. It now works, for the time being.

Some of these folders seem to have the sticky bit set. How to get this resolved, without need to change the original service-file and/or need to add the CAP_DAC_READ_SEARCH-capability?

(Follow-up on Errors when running as service@root, but no errors when run in terminal or without sandboxing - #5)

2

Syncthing accessing files on local disk, or Syncthing accessing files stored via Samba? In the latter case, I suspect this would be a Samba config issue. (In the first case, no idea.)

Your override file is suspect for not running Syncthing as root, though, given the @root part.

3

Syncthing is accessing files on local disk, that’s also being shared using Samba. It’s such far a Samba issue, that Samba is setting the "user.DOSATTRIB"-attribute (xattr). But it’s also a Syncthing-issue that it apparently hasn’t enough rights to write/read extend attributes on directories. I checked, but most directories the errors came from have this right pattern drwxrws---+.

root@[COMPUTER NAME]:/# ps -aux | grep syncthing
root       11193  0.0  0.1 1360268 21908 ?       Sl   Jun22   0:10 /usr/bin/syncthing serve --no-browser --no-restart
root       11203 15.0  6.0 2659160 727652 ?      SNl  Jun22  70:42 /usr/bin/syncthing serve --no-browser --no-restart
root       80813  0.0  0.0   7068  2144 pts/0    S+   05:53   0:00 grep syncthing

So, that’s not the issue.

But extended attributes in the user-namespace aren’t that uncommon, I would assume. Besides, CAP_FOWNER is managing that right as far as I know. So, I don’t understand why this issue arises.

4

Right, topic subject says ”not as root” while you clearly are running as root, which confused me. That also makes it even less clear why it would have problems reading that specific attribute. I have no real idea what’s going on, as far as I know attributes don’t have permissions of their own.

I guess you can try adding an xattr filter to exclude it, assuming it’s not the attribute you want to sync.

Or, remove more hardening options from the systemd file on the guess that this might be something there that is acting up.

5

I actually want to sync it. BTW, if I filter this out, I get other errors… So there seems something odd goign on.

Doesn’t work at all. I tried. But the capabilities are the thing involved here…

6

Yeah… syncthing just reads files and their attributes. The permissions and capabilities are up to OS settings and setup :person_shrugging:

7

Nah, is also in the service unit. Since in that unit you can ask for the permissions. And I’m inclined to think there’s a bug in Debian or Syncthing. Since it’s not so sophisticated what I’m doing. Most of it is just vanilla Debian.