I downloaded the latest release and just moved the binary into
/bin to replace my previously installed binary that I got through
dnf -I’m using Fedora-.
Is there anything else I should take into consideration for it to work well, or this will do the trick?
It might not be able to self update this way.
Ideally, stuff under
/bin is a symlink) should be left to the OS. Manually replacing a file installed by the package manager will cause conflicts when upgrading packages to newer releases – i.e. DNF still thinks that it was the one who installed Syncthing, so DNF will either downgrade your newer
/usr/bin/syncthing or spit out an error the next time
dnf upgrade is run.
It also means that Syncthing’s built-in auto-upgrade and the upgrade button in its web UI won’t work because
/usr/bin/syncthing is normally owned by
root, so you’ll need to manually replace
/usr/bin/syncthing as needed. (Fedora compiles Syncthing with auto-upgrade disabled.)
If Syncthing must be available to multiple users, it’s better to put it under
/opt (short for “optional”) in a
/opt/syncthing, or some other choice of subdirectory.
/opt/syncthing is ideal because the directory and file ownership are easy to manage to allow Syncthing to auto-upgrade itself (if that’s of interest).
/usr/local/bin is another option, but setting up auto-upgrade is more complicated because Syncthing can’t normally write anything else there so it won’t be able to create a temporary file during upgrades.
If Syncthing is only going to be used by a single user, the best option is
~/bin. By default the subdirectory doesn’t exist, but it’s part of the default search path. Since it’s owned by the user running Syncthing, the upgrade button in the web UI and auto-upgrades work as expected.
- Some users don’t like to see a
~/bin subdirectory, so
~/.local/bin is another option if having it hidden is preferred.
- It’ll avoid confusion later if the system package is uninstalled, but since
~/bin are searched before
/usr/bin there’s generally no conflict at a shell prompt.
- However, it’s not necessarily true for a desktop environment. For example, launching Syncthing from the “Activities” menu in GNOME loads
/usr/share/applications/syncthing-start.desktop, which in turn runs
If using systemd to auto-start Syncthing, anything other than
/usr/bin/syncthing requires updating the systemd unit file for Syncthing (e.g.
And if you remove the system package for Syncthing, you’ll have to create your own systemd unit file (e.g.
As a service, Syncthing runs unconfined under SELinux on Fedora, so no potential issues there.
Or copy it to
~/.config/systemd/user/syncthing.service and replace
ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0
ExecStart=%h/.local/bin/syncthing serve --no-browser --no-restart --logflags=0
or any other path in your home, without root access.
Thanks guys for the useful tips, I totally missed the point of dnf getting confused, The only reason I did it this way, I didn’t want to modify the
.desktop file, but that turned out to be lazy and dumb
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.