Mounting via systemd.automount causes unusual file permission problems

Suspected Bug
1

What is the problem you are having with rclone?

Setting up an rclone systemd.automount via fstab makes the mountpoint and its files only accessible for root, although

  • uid and gid parameters are correctly set for myuser and
  • myuser effectively is the owner of the mountpoint and the files inside.

For root, everything looks fine and as it should be:

root@machine /home/myuser > ls -la | grep OneDrive
drwxr-xr-x  1 myuser myuser          0 May  4 15:36 OneDrive

The files inside can be listed and read without any problems. Note, that myuser is shown as the owner of the mountpoint.

But myuser cannot even see who is the owner of the mountpoint, although he owns the mountpoint and has all necessary permissions (as seen via root):

myuser@machine:~$ ls -la | grep OneDrive
ls: cannot access 'OneDrive': Permission denied
d?????????  ? ?      ?               ?            ? OneDrive

I've got about 10 cifs shares in my fstab, which are similarly configured regarding uid and gid. They work as intended and are accessible for myuser.

Run the command 'rclone version' and share the full output of the command.

rclone v1.58.1
- os/version: debian 11.3 (64 bit)
- os/kernel: 5.10.0-13-amd64 (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.17.9
- go/linking: static
- go/tags: none

Which cloud storage system are you using? (eg Google Drive)

OneDrive

The command you were trying to run (eg rclone copy /tmp remote:tmp)

No command, but my configuration line from fstab:

OneDrive:    /home/myuser/OneDrive    rclone    rw,noauto,nofail,x-systemd.automount,args2env,vfs_cache_mode=writes,config=/home/myuser/.config/rclone/rclone.conf,cache_dir=/var/cache/rclone,uid=1000,gid=1000    0    0

The rclone config contents with secrets removed.

[OneDrive]
type = onedrive
token = {[...]}
drive_id = [...]
drive_type = personal
region = global

A log from the command with the -vv flag

As I'm actually not executing a command, there's no log.

Some extra information you might find helpful.

  • Problem has persisted for months and also with version 1.57.
  • As it has persisted for months, I've restarted dozens of times.
  • I've tried uninstalling and reinstalling rclone, made no difference.
  • I've tried using other folders as mountpoint, that made no difference either.
  • The filesystem of my home drive is ZFS. It was set up using this tutorial.
  • I suspect rclone to be the source of the error, because cifs shares that are mounted via fstab do not show this behavior.
2

hello and welcome to the forum,

try adding --allow-other

3

After a quick search, I've found out you have to use allow_other instead of allow-other when inserting this option into an fstab configuration. Now, my fstab configuration line looks like this:

OneDrive:    /home/myuser/OneDrive    rclone    rw,noauto,nofail,x-systemd.automount,args2env,vfs_cache_mode=writes,config=/home/myuser/.config/rclone/rclone.conf,cache_dir=/var/cache/rclone,allow_other,uid=1000,gid=1000    0    0

Unmounting via umount /home/myuser/OneDrive and reloading the config via systemctl daemon-reload.

And it works!

myuser@machine:~$ ls -la | grep OneDrive
drwxr-xr-x  1 myuser myuser          0 May  4 16:51 OneDrive

Thank you so much! :partying_face:

4

Is rclone running as root? --allow-other may help.

It is not recommended to run fuse filing systems as root (its complicated) so I suggest you run it as your user if at all possible. I'm not sure how to organise this in /etc/fstab though.

5

When using fstab, it is.

The option you mentioned was already suggested and actually fixed my problem.

What you could try, when you don't want to run rclone as root, is to manually create a mount and automount service as a systemd user service. Although I haven't had any problems with this fstab solution for years. It works reliably, at least for cifs.

1 Like
6

You don't need a system user service. You can just specific the user in the service file.

I use systemd dependencies to make sure services are running so if something goes away, the service depending on it stops as well as that's easier for me to setup.

Also allows me to go after other services start up, like the network.

In general, I always say use what works best for you. If /etc/fstab meets your needs, use it.

1 Like
7

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.