Cannot sync to a location outside of home folder on Linux

Support
1

Hello.

I’m trying to set up Win ↔ Linux sync, and stumbled upon a concrete roadblock.

If I set a location outside a home folder on Linux, e.g. /share/sync (where /share is a dedicated btrfs partition), the sync does not happen, even though the Syncthing page says everything is up to date and shows the total file size correctly. The Linux folder just stays empty.

If I leave the default location, or use any folder in home, (~/Sync), the sync works as expected.

No matter how many times I tried to re-share the folder from both sides, the result is the same. I also tried to use symlinks, only to learn the hard way that they are not supported.

Could not find anything of relevance in the logs yet.

Any suggestions?

System info: Syncthing v1.28.1 Linux Manjaro 24.1 with btrfs Kernel version 6.11.10

Thanks in advance.

2

Does the user that owns the Syncthing process have rights to the directories in question?

3

As far as I can tell Syncthing runs under current user, which certainly has read/write access to the directories.

4

Please use ps -ef | grep sync to confirm what user owns the Syncthing process. Then you can use su to become that user and confirm read and write access to that directory.

5

Typically if files are supposedly synced but not visible, it’s because your running in a Docker container and haven’t mapped the volumes properly. Is that the case?

1 Like
6

The ps command shows that the process is running under correct user (me). However, I see two Syncthing processes running. Is this normal? Could it be because I am using Syncthing Tray as a GUI client (both on Windows and Linux)?

7

I have Docker running on Linux, however I did not create any containers involving Syncthing.

8

Yes :slight_smile: (see https://docs.syncthing.net/users/faq.html#why-do-i-see-syncthing-twice-in-task-manager).

1 Like
9

And you’ve confirmed that you can write files to those locations?

10

Yes, I can create and delete files on the /share partition (via Dolphin file manager, at least).

1 Like
11

Super weird. Anything in the log? If not turn on the following debugs (I recommend one at a time) fs, sync, while inducing the behavior, and see if anything lets us know what the problem is.

12

I’ve enabled the debug logging, but it is not clear what kind of messages I should look for, as there seems to be no distinction between info messages, warnings, and errors.

Are there any particular messages to look for?

1 Like
13

Please post the logs here if nothing jumps out at you.

14

Can we see the output from the following commands?

ps -ef | grep syncthing
ls -nd /share/sync

Is Syncthing Tray auto-starting Syncthing or is it some other method?

1 Like
15 
ps -ef | grep syncthing                                                                    
andy        3311     828  0 гру03 ?     00:00:00 bwrap --args 39 -- syncthingtray
andy        3321    3311  0 гру03 ?     00:00:00 bwrap --args 39 -- syncthingtray
andy        3322    3321  0 гру03 ?     00:02:27 syncthingtray
andy        3339    3322  0 гру03 ?     00:00:01 /app/bin/syncthing serve --no-browser --logflags=3
andy        3347    3339  0 гру03 ?     00:00:55 /app/bin/syncthing serve --no-browser --logflags=3
andy       44745   10232  0 22:20 pts/1    00:00:00 grep syncthing

ls -ld /workspace/Work                                                   
drwxrwxrwx 1 root root 0 гру  3 18:37 /workspace/Work

/workspace/Work = /share/Sync

PS It might take a while for me to reply as I’m dealing with constant power outages (UA).

16

Yes, Synchthing Tray is auto-starting Syncthing.

17

The first thing I see is that /workspace/Work is owned by root:root while Syncthing is running under user andy.

Your solution changing the directory permissions to read/write for everyone would work, but is way overkill unless there are other users in addition to andy who will be reading/writing to that same directory – but if that’s the case, you’re going to end up with quite a messy pile of permissions to eventually deal with. Much better to take a more granular approach by changing the ownership instead:

chown -R andy: /workspace/Work

However, I don’t think that’s the core permissions issue…

It’s very unusual that your Syncthing binary is installed in /app/bin. Most often it’s /usr/bin/, possibly /usr/local/bin, or even ~/.local/bin.

Manjaro is based on Arch Linux, which means it’s using Pacman as the package manager, so a pacman -Syu syncthing would have dropped the binary into /usr/bin.

Did you install Syncthing via Flatpak?

18

No, it was installed from the official repository.

19

I downloaded the latest ISO from https://manjaro.org/ to take a closer look. I’m vary familiar with Arch Linux that Manjaro is based on, but other than being aware of Manjaro, hadn’t used it before.

Manjaro’s official Syncthing package installs to /usr/bin just like Arch Linux, Debian, Ubuntu, Fedora and other Linux distros not using containers or an immutable root filesystem, so it appears that you’ve got a custom Manjaro setup because the directory /app didn’t exist in my test installation.

You’ll need to review Syncthing’s logs and perhaps post screenshots of Syncthing’s UI, because with global read/write permissions on /workspace/Work there’s no reason Syncthing can’t use it unless there’s something external blocking Syncthing.

20

I installed Manjaro using the official iso file, with no modifications. Then I installed some non-system software, including Syncthing.

Today I re-installed Syncthing and Syncthing Tray, and set it to auto-start as a systemd user service, as described in the official docs. That seems to have fixed the issue.

Thanks for the help anyway!