Creating a systemd startup script for SpiderOakOne

#1

Hello Silverblue developers and administrators!

Today I installed Fedora Silverblue 31 and, after some work, everything works fine!

However I have on little problem: the backup service SpiderOakOne doesn’t start automatically anymore at boot time. In the past there was an option in SpiderOakOne to enable this but for some reason the option is removed or is just not shown. Maybe because I installed SpiderOakOne without privileges? I thought that in the past there also was an option in ‘Tweak -> Startup applications’ to add a script but that’s somehow also gone?

Because there is now GUI-way anymore to solve this problem I started searching and found this solution to create a systemd startup script.

I created the following systemd service/script:

/etc/systemd/system/start-spideroak.service

[Unit]
After=network.target

[Service]
ExecStart=/var/home/trakker/SpiderOak/startup-script/SpiderOakONE.sh

[Install]
WantedBy=default.target

Now the bad news: when I enable and start this systemd service/script nothing happens :frowning:. I don’t even get an error message :frowning:!

I’m not an expert on systemd so I don’t now why it’s not working. Does anybody know what the reason could be?

Thanks in advance :slight_smile: !!

Scott Trakker
(not real name)

#2

Try to add User and Group inside the Service section.

#3

I tried the following but neither worked:

User=trakker
Group=wheel

or

User=trakker
Group=trakker

I also don’t get any error messages (?).
But thanks for the advice!

#4

It’s been a while since I’ve used spideroak, but if I remember correctly this utility is similar to dropbox and runs as part of the user’s session. I think what you’re looking for is for this unit to start when you log in, not when the computer boots. To start I’d move the unit file to your home directory here: ~/.config/systemd/user/

then enable it with; systemctl --user enable --now start-spideroak.service

It’s likely the startup script requires a graphical session (I may be completely wrong here), but give this a shot before going deeper. Hopefully you’ll also get helpful information to debug via: journalctl --user-unit=spideroak.service
Cheers,

1 Like
#5

Hello Mr Guitar!

I solved it! But a little bit differently then you described. First: thanks for thinking along!

I wanted to move the file start-spideroak.service to the folder ~/.config/systemd/user/ but when I did this I found out that that folder doesn’t exist. Not only that: I also found out there is a folder called autostart in the directory .config! I looked in this directory and saw that it was empty. To find what would happen when I added an application with Tweaks -> Startup applications, I added Firefox and saw that a .desktop file was created. After that I searched on the internet how to write a desktop file. I found this webpage and created a simple desktop file with the following content:

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Terminal=false
Exec=/var/home/trakker/SpiderOak/startup-script/SpiderOakONE.sh
Name=SpiderOakONE

And that was it! I logged out and logged back in and yes: SpiderOakOne was started!!

Before I created the desktop file I also tried your solution. I made the folders systemd and user and moved the service file there. I enabled it and tried to launch it. Still nothing happened but when I looked at the logs I found this:

Started start-spideroak.service.
start-spideroak.service: Failed to determine supplementary groups: Operation not permitted
start-spideroak.service: Failed at step GROUP spawning /var/home/trakker/SpiderOak/startup-script/S>
start-spideroak.service: Main process exited, code=exited, status=216/GROUP
start-spideroak.service: Failed with result ‘exit-code’.

So it has something to do with the group statement.

I’m not going to dive deeper into it. I’m happy that it works now!!
Thanks for pointing me on the .config directory!

#6

Ah yeah. I should have thought of this. If I remember this is essentially how spideroak will start itself on a regular install. Glad you solved it and it’s working!

…In the future if you have to mess w/ systemd units for users, I would drop the User= & Group= lines because it’s going to run under your session anyway. :wink:

1 Like