Error while traversing – Ownership, permissions or filetype?

Hello! Filesystem watcher throws me an “Error while traversing”. I start the service loged in as root, but only have user1 permissions I do not understand why that is the case.

Set up

  • I start Syncthing logged in as root.
  • The directory holds volumes for Docker containers.

The patch

If I chown the folder recursively to user1:user1, that fixes the problem.

Other symptoms

Any ideas? Thanks in advance :star_struck: :pray:t4:

Short answer is that it isn’t a Syncthing issue…

Issue #1:

From your StackExchange post, the following two sets of commands are the same, but don’t have the same results:

root@computer1:~# systemctl --user kill syncthing
root@computer1:~# systemctl --user status syncthing
user1@computer1:~$ systemctl --user kill syncthing
user1@computer1:~$ systemctl --user status syncthing

The first two commands kill and check the status for the Syncthing user-level systemd service for root, while the other two commands do the same for user1.

Both of the systemd status outputs show that neither root or user1 have Syncthing enabled to auto-start (note the “disabled” status):

× syncthing.service - Syncthing - Open Source Continuous File Synchronization
     Loaded: loaded (/usr/lib/systemd/user/syncthing.service; disabled; preset: enabled)

So if there are no other methods being used to start Syncthing, there shouldn’t be a running Syncthing after the two “systemctl --user kill” commands above.

I recommend:

  1. Temporarily stop issuing any more systemctl commands.

  2. Reboot the computer.

  3. Log in, but don’t issue any more systemctl commands yet.

  4. Check for any running instances of Syncthing:

    ps -ef | grep syncthing

If the command above returns anything but itself, you need to backtrack and find out how else Syncthing is being started at system boot time before continuing with any other steps.

(On a related note, generally speaking, it’s better to use “systemctl stop” instead of “systemctl kill” so that if ExecStop is defined in the systemd unit file, it’s used. Sending a kill signal directly to a process usually results in a graceful shutdown, but the end result might be different than via a normal shutdown.)

Issue #2:

To me, it says that Syncthing is somehow running as user1 and not root. How exactly are you starting Syncthing while logged in as root?

  • How does Docker containers fit into the picture?
  • Are you trying to use Syncthing on a set of files that the containers are also accessing on the host?
  • Which Linux distro?
2 Likes

I rebooted it and it seems to be returning more than just itself. I can also access the web GUI even though it is “disabled” in systemd. I am not familiar with the output of ps, so I will try to figure things out, but here is the output in case someone can help:

user1       626       1  0 15:31 ?        00:00:00 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0
user1       751     626  7 15:31 ?        00:00:06 /usr/bin/syncthing serve --no-browser --no-restart --logflags=0
root        2768    2738  0 15:33 pts/0    00:00:00 rg -i --color always syncthing

Also, for good measure, I ran systemctl --user status syncthing as root and user1 and the service is inactive for both.

How is it starting?

  • Crontabs are empty for all users.

Answers to other questions

I log in as root and run systemctl --user start syncthing

Correct.

The machine we are talking about is Debian 12.

So, it is 2 processes running as user1. The parent started by root and the son started by the “lp” user. No idea about it.

cat /etc/passwd | rg 7 
lp:x7:7:lp:/var/spool/lpd:/usr/sbin/nologin

but after doing everything mentioned in the previous post, the ouput of ps -ef | rg syncthing changes to:

user1       626       1  0 15:31 ?        00:00:00   /usr/bin/syncthing serve --no-browser --no-restart --logflags=0
user1       751     626  0 15:31 ?        00:00:13     /usr/bin/syncthing serve --no-browser --no-restart --logflags=0
root        6285    2738  0 16:45 pts/0    00:00:00           rg -i --color always syncthing

And all processes where started by root :thinking:

You seem to be looking at column four of the ps -ef output, which is the percentage of CPU used by the process, and taking this as a numeric uid for who “started” the process? I don’t know why you’re doing this but it doesn’t make any sense to me. The user ID of the process is in the leftmost column – user1.

1 Like

From left to right, the columns are:

  • UID = user ID that owns the process
  • PID = process ID
  • PPID = parent PID
  • C = CPU utilization
  • STIME = start time
  • TTY = controlling terminal
  • TIME = run time
  • CMD = command

Both Syncthing processes are owned by user1, with init (PID 1) starting Syncthing (PID 626), followed by the first Syncthing starting the second Syncthing (PID 751).

(For more verbose output that includes a process tree: ps -efH)

Since the first Syncthing was launched by init, it means it wasn’t systemd because init is the predecessor of all other processes, including systemd. So regardless of if systemctl --user stop syncthing is run as root and/or as user1, it won’t stop the Syncthing process listed in the ps output above.

Linux distros that use systemd have a pared down list of services started by init, so it’s very unusual to start Syncthing that way. Chances are that you previously added an init file to Debian 12’s /etc/init.d/ directory.

1 Like

Don’t do that.

For security reasons, there should be a minimal set of network services running with root privileges.

Syncthing runs perfectly fine with regular user privileges, so resorting to running it as root is just avoiding a file/directory permissions issue (that will eventually cause problems later on).

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.