Mounting onedrive on startup/login/restart/reboot

Hi! I am trying to mount my onedrive service every time I startup or reboot. The problem that I have is that my script is inconsistently working. I made a systemd service linked to /usr/bin/mount-onedrive.sh. Here is how the service looks like:


[Unit]
Description=OneDrive Setup
#Requires=NETWORK.target
#After=NETWORK.target

[Service]
ExecStart=/usr/bin/mount-onedrive.sh

[Install]
WantedBy=multi-user.target

And here is the script:


#!/bin/bash

sh -c "rclone --vfs-cache-mode writes mount onedrive: ~/OneDrive"

echo Onedrive Stopped

I made sure to use “chmod u+x /usr/bin/mount-onedrive.sh” and enabled the service.
If I run the script by hand, it works no problem, but if I restart the system or reboot or power down and restart it, it’s like a lottery. Sometimes it works, but more often it dose not.

I even tried to run it in crontab:


@reboot /usr/bin/mount-onedrive.sh

And still nothing.

Is there a way to register a command that will run on startup(NO .SH SCRIPT, JUST THE COMMAND) in Garuda?

First, this line

can contain this one:

No need for a separate script.

Next two things to check. One,

Do these need the full path?

Two,

This won’t work for system-wide scripts, and also remember that system services are running as root (so how will that affect rclone?).

Therefore, you probably want to convert this into a user service, place it under $HOME/.config/systemd/user and enable it with systemctl --user.

Then it will run when you log in and as your user.

8 Likes

Cheching right now.

Hi! I ended up changing the service into:

[Unit]
Description=OneDrive Setup

[Service]
ExecStart=sh -c "rclone --vfs-cache-mode writes mount onedrive: ~/OneDrive"

[Install]
WantedBy=default.target

This is one of the variants that I have tried

[Unit]
Description=OneDrive Setup

[Service]
ExecStart=sh -c "rclone --config=$HOME/.config/rclone/rclone.conf --vfs-cache-mode writes mount onedrive: $HOME/OneDrive"

[Install]
WantedBy=default.target

I have placed it inside ~/.config/systemd/user and ran the command "systemctl enable mount-onedrive.service --user".

It is running properly if I start it, but still, no effect on reboot.

What service status is shown after login?

I don't know what exactly are you talking about.

Here is a report of enabled unit files:

UNIT FILE                                STATE   VENDOR PRESET
libinput-gestures.service                enabled enabled
mount-onedrive.service                   enabled enabled
pipewire-media-session.service           enabled enabled
psd.service                              enabled enabled
pulseaudio-bluetooth-autoconnect.service enabled enabled
xdg-user-dirs-update.service             enabled enabled
dirmngr.socket                           enabled enabled
gpg-agent-browser.socket                 enabled enabled
gpg-agent-extra.socket                   enabled enabled
gpg-agent-ssh.socket                     enabled enabled
gpg-agent.socket                         enabled enabled
p11-kit-server.socket                    enabled enabled
pipewire-pulse.socket                    enabled enabled
pipewire.socket                          enabled enabled

14 unit files listed.

What is the status after login for the service you created?

The status is inactive:

I checked with:

systemctl is-active mount-onedrive.service

And it printed inactive.

Or maybe I don't know exactly how to check it...sry!

systemctl status $mount-onedrive.service

This command did not show the mount-onedrive.service, but after I start it manualy it appears.

It's a user service, so check with

systemctl --user status mount-onedrive
2 Likes

I usually find inconsistent/unreliable starts are a result of timing issues.

This can often be fixed by adding several seconds of sleep before the service is executed.

Another option is to start only after network-online.target.

3 Likes

I'd probably recommend an After target rather than adding an extra sleep in there.

If rclone is failing to start for that reason it might also have an option to wait or retry. :thinking:

2 Likes

aug 16 01:20:48 asus systemd[1796]: Started Mount OneDrive.
aug 16 01:20:48 asus sh[1803]: Failed to create file system for "onedrive:": failed to get root: Get "https://graph.microsoft.com/v1.0/drives/f0561d32560b3528/root": dial tcp: lookup graph.microsoft.com: no such host
aug 16 01:20:48 asus systemd[1796]: mount-onedrive.service: Main process exited, code=exited, status=1/FAILURE
aug 16 01:20:48 asus systemd[1796]: mount-onedrive.service: Failed with result 'exit-code'.

Here are the logs form:

systemctl --user status mount-onedrive

I tried with after and with a delay aswell.

Maybe my code was bad. Can you give me an example?

I know the After hook, but the param...

Like this:

After=network-online-target

??

Try this instead:

After=network.target 

You could also try adding:

Requires=network.target 

Or:

Requires=network-online.target
After=network-online.service
2 Likes

This should be a .

Also consider doing some searching around rather than expecting a copy-paste solution for a something that’s not technically a Garuda issue.

1 Like

Ya, sorry about that, my initial post contained that typo. My followup post had the correct target syntax.

3 Likes

I managed to make mount it successfully on boot but with a 5 sec delay.

Maybe it is not working because I don't have a network-online.target in ~/.config/systemd/user

Here is what the service looks like right now:

Unit]
Description=Mount OneDrive
After=network-online.service

[Service]
ExecStart=sh -c "sleep 5s && rclone --config=/home/andre/.config/rclone/rclone.conf --vfs-cache-mode writes moun
t onedrive: /home/andre/OneDrive"

[Install]
WantedBy=default.target

It's kind of junky but it works. I will try to find another way.

Thanks for help guys!

1 Like

I believe this is the solution. It needs some refinement, but it basically answers the main question.

Yes.

This does not exist. Change the extension to target and it will probably not require the 5 sec sleep (as already suggested).
Test to confirm.

1 Like

Hi! Sorry for the late response. The answer is no, it is not working because I do not have a network.target.wants directory inside ~/.config/systemd/user/.