Hi,
I’m following this guide to set up SyncThing. I’m stuck at adding it to systemd, specifically with this line: podman generate systemd -f -n syncthing-toolbox I get bash: podman command not found.
Do I have to install podman? I think I already have it?
EDIT:
Somehow it was a temporary problem?? I just tested:
❯ podman ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f8dc4727d8e6 quay.io/fedora/fedora:40 --verbose --name ... 22 hours ago Up 38 seconds SuperGoed
9243a6664fb5 registry.fedoraproject.org/fedora-toolbox:40 toolbox --log-lev... 8 hours ago Up 3 hours syncthing-toolbox
So podman was recognised. I tried again:
❯ podman generate systemd -f -n syncthing-toolbox
DEPRECATED command:
It is recommended to use Quadlets for running containers and pods under systemd.
Please refer to podman-systemd.unit(5) for details.
/var/home/jonathan/container-syncthing-toolbox.service
Odd that podman wasn’t detected. Possibly a bad PATH read, not enough info to really tell.
As for the other “error”, basically what was happening is the old podman generate systemd used to create a raw systemd-unit file that could be used. This command has been depreciated preferring the use of something called Quadlet files. These Quadlet files are basically configuration files that are used by systemd generator to create the systemd-unit files at boot making things a bit more flexible and less complicated to create. If you wanted to go this route you’d create a Quadlet file and place it in /etc/containers/systemd/users/, run systemctl daemon-reload, then enable to service with systemctl --user commands.
If you are interested in learning how to create Quadlet files, podman-systemd.unit(5) has all the information you’d need. However, I’d recommend reading some blog posts to see some real world working examples while referencing the man page to see what each setting actually does.
I wouldn’t say one solution is better than the other in this case. If it works it works you know? It’s up to you on how you want to do it. Like I use a flatpak to run syncthing at the moment because it was available and worked. I was just sharing some information on what was going on and why it wasn’t working for ya
As an update, I’m sharing my own guide documenting how I used the Syncthing Flatpak with the Decky plugin to manage everything without using pods or layering.
@Jonasan I can highly recommend going for Syncthingy instead. You can install it via Bazaar (Flatpak) and it just works, really well.
It handles autostart, it helps you even to set it up as system app so that it will start BEFORE logging into the system. And it integrates nicely in the systray. I believe it is automatically build, so no worry about it not being maintained in the future.
Happy to help! Just posted an update in case someone googles about syncthing on bazzite game mode. Its good to have good results regarding the matter search engines!
All of the synthing flatpaks do. otherwise you need to layer or pod the process. Thats the point of the syncthing steam plugin. it uses the binary inside of the flatpak.
I thought, because I see the mentioned line (pointing to a container), that meant an external application was used with Syncthing Tray. For testing, I stopped syncthing-toolbox, to confirm it really is used by Syntching. And indeed, Syncthing Tray doesn’t work anymore in that case.
It’s not important, everything works. I don’t know what is meant by “binaries” and I cannot explain myself to you apparently. But no problem, I believe you, Syncthing Tray had everything inside itself, no other containers are needed. (Not important why that container seems to be there then and I have to point to it in Syncthing Tray).
(I really don’t understand a lot of things about toolboxes and containers and things like that, no sarcasm here!)
If you come from windows binary is the exe file. If everything works for you there is no reason to change anything. Only positive from that is one less thing to run (if you want to use the flatpak in game mode as containers dont run in that)
