Restic mount reliably fails on one of two mount points

Getting Help
1

I have two parallel setups: one for the user (several months old), one for the whole system (new). A backup script runs via cron and works well for both with a nearly identical script.

(un)mounting the user one has no problems. The second one reliably works (no errors in /var/log/syslog), but the mount point turns from a directory to a garbage ‘file’. Access is thereby impossible.

I guess there is some config or permission problem to explain the difference. I spent a lot of time making sure setups are identical, but just don’t see it. Some details below

Any pointers would be most welcome, thanks! Martin

before mount:

ls -al /media/restic/
drwxrwxrwx 2 restic restic 4096 Aug  5 11:21 browse-restic
drwxrwxrwx 3 restic restic    3 Aug  4 12:58 fullback

then run

$ restic -r /media/restic/fullback/smallbox -p /home/restic/bin/pw.txt mount /media/restic/browse-restic
repository xxxx opened successfully, password is correct
Now serving the repository at /media/restic/browse-restic
When finished, quit with Ctrl-c or umount the mountpoint.

ls -al /media/restic/
d????????? ? ?      ?         ?            ? browse-restic
drwxrwxrwx 3 restic restic    3 Aug  4 12:58 fullback

after ctrl-c I am back to what I had before. That happens permanently.

The essentially identical command for the user works fine:

restic -r /media/martin/linback -p /home/martin/bin/pw.txt mount /media/martin/browse-restic

/etc/fstab is identical for both. The setup and permissions on the server side are identical (freeNAS)

# for user backup
x.x.x.10:/mnt/nasvol/linux-back	/media/martin/linback	nfs4 rw,noauto,x-systemd.automount,user,_netdev  0  0
# for system backup
x.x.x.10:/mnt/nasvol/sysback	/media/restic/fullback	nfs4 rw,noauto,x-systemd.automount,user,_netdev  0  0
2

The mount point remainders with broken permissions look like the mount-point was not properly removed. I’d suspect that it is still considered as existing by the kernel. Can you check the output of mount (the system command, not the restic one) or take a look at /proc/self/mountinfo (at least your fstab looks like a linux system) regarding whether the mountpoint is still listed?

You could also try a beta build of restic to see whether that fixes the issue: https://beta.restic.net/?sort=time&order=desc . We’ve updated the library used to create the fuse filesystem in the mount command, maybe that has fixed something.

3

Hi Michael,

Thanks for the tips. Yes, I am on Ubuntu Linux 18.04. I have seen this garbled directory listing before, if an unmount has failed. But now it happens after a mount. Unmount restores the proper entry (though empty)

I tried restic_v0.9.6-346-geca0f0ad_linux_amd64, but that brought no change.

However! So far I had done all the access to the user restic through a shell with sudo -i -u restic. Logging in directly as the user restic (after giving him a password), then the mount works or rather shows up properly. Viewing the restic mount as my regular user again shows garbage.

That is strange, because all the top folders/files are world readable 755 or 644. And makes it impossible to access even my own users data

So some kind of permissions issue must exist. I don’t like the idea of giving that user a login ability. I just created him to run the full system backup per the instructions given.

Before mount and after ctrl-c from restic mount

cat /proc/self/mountinfo |grep restic
49 27 0:44 / /media/restic/fullback rw,relatime shared:28 - autofs systemd-1 rw,fd=27,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=14958
1154 49 0:67 / /media/restic/fullback rw,nosuid,nodev,noexec,relatime shared:849 - nfs4 x.x.x.10:/mnt/nasvol/sysback rw,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=x.x.x.33,local_lock=none,addr=x.x.x.10

after mounting with restic mount

cat /proc/self/mountinfo |grep restic
49 27 0:44 / /media/restic/fullback rw,relatime shared:28 - autofs systemd-1 rw,fd=27,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=14958
1154 49 0:67 / /media/restic/fullback rw,nosuid,nodev,noexec,relatime shared:849 - nfs4 x.x.x.10:/mnt/nasvol/sysback rw,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=x.x.x.33,local_lock=none,addr=x.x.x.10
2466 27 0:71 / /media/restic/browse-restic ro,nosuid,nodev,relatime shared:1703 - fuse restic ro,user_id=1002,group_id=1004
4

That description sounds like the mount is actually working as it should. By default FUSE mounts are only accessible by the user who created the mount. Not even root can access these mounts.
The option --allow-other should help in that case.

5

Yes, that was the solution! I was not aware FUSE is so restrictive, that explains some other problems I had. Thanks!

restic mount --allow-other -r /media/restic/fullback/smallbox -p /home/restic/bin/pw.txt /media/restic/browse-restic

Allows me full access to the backups. I can also use sudo now to mount as a user other than the restic one.