Syncthing service won't start automatically

Hello, good morning.

After each system reboot (I’m using Ubuntu 25.04), the Syncthing service doesn’t start automatically. I always have to start it manually with systemctl enable --now syncthing@myusername.service. How should I proceed?

Thanks.

Are you using an encrypted home directory?

No.

1 Like

What status does systemd report for the unit before you issue that command? There are some subcommands in systemctl to check dependencies. You should check those in addition.

Where did you get the systemd service file from? How did you install Syncthing at all?

systemctl status syncthing@myusername.service:

× syncthing@myusername.service - Syncthing - Open Source Continuous File Synchronization for myusername
     Loaded: loaded (/usr/lib/systemd/system/syncthing@myusername.service; enabled; preset: enabled)
    Drop-In: /run/systemd/system/service.d
             └─zzz-lxc-service.conf
     Active: failed (Result: exit-code) since Mon 2025-06-23 09:39:18 -03; 1 day 6h ago
   Duration: 1.535s
 Invocation: 18029c080c544d9f92aef1a02539a981
       Docs: man:syncthing(1)
    Process: 528 ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0 (code=exited, status=1/FAILURE)
   Main PID: 528 (code=exited, status=1/FAILURE)

jun 23 09:39:18 ubuntu systemd[1]: syncthing@myusername.service: Scheduled restart job, restart counter is at 4.
jun 23 09:39:18 ubuntu systemd[1]: syncthing@myusername.service: Start request repeated too quickly.
jun 23 09:39:18 ubuntu systemd[1]: syncthing@myusername.service: Failed with result 'exit-code'.
jun 23 09:39:18 ubuntu systemd[1]: Failed to start syncthing@myusername.service - Syncthing - Open Source Continuous File Synchronization for myusername.

Syncthing installed using: apt install syncthing.

Have you configured the service for several different user accounts by any chance? I suspect that it is not starting correctly because the ports are already blocked by another instance, or even the same user is starting a Syncthing instance via a different method.

Check the journal for pointers, and look at the output of ps axu | grep syncthing while the service fails to start.

journalctl to see output on why it’s not starting.

myusername 747 0.0 0.0 9376 1500 pts/1 S+ 08:52 0:00 grep --color=auto syncthing

Well, if that was the last of the logs, we know it was running on May 30th :person_shrugging:

sudo journalctl -u syncthing@myusername
mai 30 22:09:31 ubuntu systemd[1]: Started syncthing@myusername.service - Syncthing - Open Source Continuous File Synchronization for myusername.
mai 30 22:09:32 ubuntu syncthing[6127]: [start] INFO: syncthing v1.29.2 "Gold Grasshopper" (go1.24.1 linux-amd64) debian@debian 2025-03-01 17:42:47 UTC
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: My ID: redacted
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: Hashing performance is 166.63 MB/s
mai 30 22:09:32 ubuntu syncthing[6127]: 2025/05/30 22:09:32 failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://githu>
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: Overall send rate is unlimited, receive rate is unlimited
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: Using discovery mechanism: global discovery server https://discovery-lookup.syncthing.net/v2/?noannounce
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: Using discovery mechanism: global discovery server https://discovery-announce-v4.syncthing.net/v2/?nolookup
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: Using discovery mechanism: global discovery server https://discovery-announce-v6.syncthing.net/v2/?nolookup
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: Using discovery mechanism: IPv4 local broadcast discovery on port 21027
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: Using discovery mechanism: IPv6 local multicast discovery on address [ff12::8384]:21027
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] WARNING: Failed to create folder marker: mkdir /home/Shinobi/videos/9XFKzEvHZX/WtQhRdwf8Y/.stfolder: permission denied
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: Ready to synchronize "Shinobi" (redacted) (sendonly)
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: Failed initial scan of sendonly folder "Shinobi" (redacted)
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] WARNING: Error on folder "Shinobi" (redacted): folder marker missing (this indicates potential data loss, search docs/forum to>
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: TCP listener ([::]:22000) starting
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: Relay listener (dynamic+https://relays.syncthing.net/endpoint) starting
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: GUI and API listening on 10.0.0.9:8384
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: Access the GUI via the following URL: https://10.0.0.9:8384/
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: My name is "ubuntu"
mai 30 22:09:32 ubuntu syncthing[6127]: [MFZ4L] INFO: QUIC listener ([::]:22000) starting
mai 30 22:09:58 ubuntu syncthing[6127]: [MFZ4L] INFO: Joined relay relay://136.47.180.129:22067

Is that the end of the journal? Try with -f to make sure the latest is output.

sudo journalctl -fu syncthing@myusername
jun 25 08:15:10 ubuntu syncthing[533]: [MFZ4L] WARNING: Aborted scan due to an unexpected error: context canceled
jun 25 08:15:10 ubuntu syncthing[533]: [MFZ4L] INFO: Failed initial scan of sendonly folder "Shinobi" (hjgvq-fvnsc)
jun 25 08:15:11 ubuntu syncthing[533]: [MFZ4L] INFO: TCP listener ([::]:22000) shutting down
jun 25 08:15:11 ubuntu syncthing[533]: [MFZ4L] INFO: Exiting
jun 25 08:15:11 ubuntu systemd[1]: syncthing@myusername.service: Main process exited, code=exited, status=1/FAILURE
jun 25 08:15:11 ubuntu systemd[1]: syncthing@myusername.service: Failed with result 'exit-code'.
jun 25 08:15:12 ubuntu systemd[1]: syncthing@myusername.service: Scheduled restart job, restart counter is at 4.
jun 25 08:15:12 ubuntu systemd[1]: syncthing@myusername.service: Start request repeated too quickly.
jun 25 08:15:12 ubuntu systemd[1]: syncthing@myusername.service: Failed with result 'exit-code'.
jun 25 08:15:12 ubuntu systemd[1]: Failed to start syncthing@myusername.service - Syncthing - Open Source Continuous File Synchronization for myusername.

Sorry, I have no idea what that warning message means. It doesn’t look like the reason for Syncthing exiting though, just a side-effect of that. You’ll need to give a little more context (older lines, best from start to finish of one failing Syncthing service run).

I’d you want logs starting with the newest, that’s -r. -f is to continuously output new lines, that’s not useful here.

sudo journalctl -ru syncthing@myusername
jun 30 07:49:09 ubuntu systemd[1]: Failed to start syncthing@myusername.service - Syncthing - Open Source Continuous File Synchronization for myusername.
jun 30 07:49:09 ubuntu systemd[1]: syncthing@myusername.service: Failed with result 'exit-code'.
jun 30 07:49:09 ubuntu systemd[1]: syncthing@myusername.service: Start request repeated too quickly.
jun 30 07:49:09 ubuntu systemd[1]: syncthing@myusername.service: Scheduled restart job, restart counter is at 4.
jun 30 07:49:08 ubuntu systemd[1]: syncthing@myusername.service: Failed with result 'exit-code'.
jun 30 07:49:08 ubuntu systemd[1]: syncthing@myusername.service: Main process exited, code=exited, status=1/FAILURE
jun 30 07:49:08 ubuntu syncthing[525]: [MFZ4L] INFO: Exiting
jun 30 07:49:08 ubuntu syncthing[525]: [MFZ4L] INFO: TCP listener ([::]:22000) shutting down
jun 30 07:49:07 ubuntu syncthing[525]: [MFZ4L] INFO: Failed initial scan of sendonly folder "Shinobi" (hjgvq-fvnsc)
jun 30 07:49:07 ubuntu syncthing[525]: [MFZ4L] WARNING: Aborted scan due to an unexpected error: context canceled
jun 30 07:49:07 ubuntu syncthing[525]: [MFZ4L] INFO: Relay listener (dynamic+https://relays.syncthing.net/endpoint) shutting down
jun 30 07:49:07 ubuntu syncthing[525]: [MFZ4L] INFO: Detected 0 NAT services
jun 30 07:49:07 ubuntu syncthing[525]: [MFZ4L] INFO: QUIC listener ([::]:22000) shutting down
jun 30 07:49:07 ubuntu syncthing[525]: [MFZ4L] WARNING: Failed starting API: listen tcp 10.0.0.9:8384: bind: cannot assign requested address
jun 30 07:49:07 ubuntu syncthing[525]: [MFZ4L] WARNING: Starting API/GUI: listen tcp 10.0.0.9:8384: bind: cannot assign requested address
jun 30 07:49:07 ubuntu syncthing[525]: [MFZ4L] WARNING: Starting API/GUI: listen tcp 10.0.0.9:8384: bind: cannot assign requested address
jun 30 07:49:07 ubuntu syncthing[525]: [MFZ4L] WARNING: Starting API/GUI: listen tcp 10.0.0.9:8384: bind: cannot assign requested address
jun 30 07:49:07 ubuntu syncthing[525]: [MFZ4L] WARNING: Starting API/GUI: listen tcp 10.0.0.9:8384: bind: cannot assign requested address
jun 30 07:49:07 ubuntu syncthing[525]: [MFZ4L] WARNING: Starting API/GUI: listen tcp 10.0.0.9:8384: bind: cannot assign requested address
jun 30 07:49:07 ubuntu syncthing[525]: [MFZ4L] INFO: QUIC listener ([::]:22000) starting
jun 30 07:49:07 ubuntu syncthing[525]: [MFZ4L] INFO: Relay listener (dynamic+https://relays.syncthing.net/endpoint) starting
jun 30 07:49:07 ubuntu syncthing[525]: [MFZ4L] INFO: TCP listener ([::]:22000) starting

It’s configured to listen on that specific address, and you probably don’t currently have that IP number. Find that entry in the configuration and replace it with just :8384 instead.

2 Likes

Bingo. That’s it.

…but isn’t it unsafe to keep the GUI accessible from anywhere (even though my firewall already blocks that)?

Instead, can I make it accessible only via 127.0.0.1? What’s strange is that the IP of this VM is actually 10.0.0.9. I’m not sure why it was throwing an error.

Anyway, thank you very much for your help!

Yes, 127.0.0.1:8384 is safer and is the default. I suggested the open listen address as that’s effectively similar to 10.0.0.9 if that is the address of the machine and I guessed it was changed for a reason :person_shrugging:

The thing is, Syncthing is installed on a VM. That’s why I had changed it to this specific IP, so I could access its GUI from another machine.

Is there some kind of NAT involved maybe? That IP address may be the one you can reach the VM on from the outside, but it’s not necessarily the address that the guest OS sees on its interface. Virtualization software usually has different networking modes, with NAT being a common default.