Rclone 1.39 vs 1.40 mount issue

Help and Support
1

I have 2 remotes that are both exhibiting the same symptom. I have a Ubuntu 16.04 machine mounting a straight up GDrive remote and a B2 crypted remote. This works correctly on both 1.39 and 1.40. The mounted folders are exported to a Samba/CIFS share for simple access from Windows machines on the network. Here is where they differ. 1.39 works as expected. On 1.40, Samba clients can open the share and browse the root folder (and open files in the root folder), but cannot go into sub folders. I get an error that the folder is unavailable. There is no data in the log file. Both remotes exhibit the same behavior. My machine is setup with two rclone binaries (named rclone_1.39 and rclone_1.40) for testing purposes.

This command and share works as expected:
rclone_1.39 mount 555crypt: /mnt/555crypt -v --log-file /mnt/555crypt.log --transfers 8 --fast-list --b2-hard-delete --allow-other

This command works and allows local browsing, but any subfolders are unavailable via Samba:
rclone_1.40 mount 555crypt: /mnt/555crypt -v --log-file /mnt/555crypt.log --transfers 8 --fast-list --b2-hard-delete --allow-other

Has something changed in the way that mounts are handled between 1.39 and 1.40? It is also possible that I’ve gotten something screwed up, so feel free to call me out.

2

Yes lots of things!

Check the permissions - it might be worth adding --umask 000 to the mount

That helped in this thread Rclone moun in samba share for windows

3

I think I have the same problem, when I try to mount the rclone mount via samba 1.39 works great, same rclone mount stops working with 1.40

Ubuntu 16.04
Samba: Version 4.3.11-Ubuntu

Same command for both versions:

rclone mount --allow-other cache: /srv/backups/Account2 -vvv --umask 000

My samba config:

[test]
read only = no
locking = no
path = /srv/backups/Account2/test/
guest ok = no

Maybe something went wrong with the allow-other?

4

I managed to replicate this and I used git bisect to find the troublesome commit.

This is good news because there is an easy work-around --attr-timeout 1s (or choose 60s if your stuff doesn’t change much).

Even --attr-timeout 1ns fixes the problem.

I have no idea why this affects samba though!

commit fc32fee4add93e7a3bda180c7c1088f93c759d13
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Fri Mar 2 16:39:42 2018 +0000

    mount, cmount: add --attr-timeout to control attribute caching in kernel
    
    This flag allows the attribute caching in the kernel to be controlled.
    The default is 0s - no caching - which is recommended for filesystems
    which can change outside the control of the kernel.
    
    Previously this was at the default meaning it was 60s for mount and 1s
    for cmount.  This showed strange effects when files changed on the
    remote not via the kernel.  For instance Caddy would serve corrupted
    files for a while when serving from an rclone mount when a file
    changed on the remote.
5

It might be that I was too agressive reducing the caching to 0, and maybe I should have chosen 1ms or something like that.

6

You nailed it. I added “–attr-timeout 1s” to the string and it works fine. I also found that I needed to specify the cache directory since it is run from an interfaces script (as root). I should have realized this earlier as I have to specify everything else. I’m using sudo -u, but it still looks in the /root/ folder for everything, but runs as unprivileged.

Anyway, thank you for the tips.

1 Like
7

Use sudo -Hu to inherit the home dir of the user you’re executing as.

1 Like
8

That did it! Thanks a lot! Now my infinite backup plan can start over :wink:

9

How have I lived my life without knowing this? You learn something new everyday. Thank you!

1 Like