Restic mount /mnt/restic

Getting Help
1

I’m new to restic and getting back into FreeNAS after letting it go several years ago. I backup some Windows folders over our LAN to FreeNAS / S3 (Minio).

c:\> restic backup d:\share

I want to restore files by browsing the snapshots from any windows machine on my LAN.

I mounted the repository

root@freenas[~]# restic mount /mnt/restic

Using Cyberduck or WinSCP I can login as root, SFTP to the snapshots and restore files. Perfect!

I created a FreeNAS user and attempted SFTP that new user account and access denied, however I am able to browse /mnt and even some other directories. It looks like the restic folder is owned by root and the group is wheel both with read and execute rights so I added the new user to the wheel group but that didn’t help.

I’d appreciate any guidance.

2

Can’t you just mount the repository as the user you created, instead of as root?

3

What rights does the user need, I added him to Operator group but still get this error when attemping fuse mount:

Welcome to FreeNAS
freenas% ./gobackup
freenas% repository 15185ba0 opened successfully, password is correct
mount_fusefs: exit status 71
also, the following messages were logged by a library:
2020/01/30 20:42:30 mount helper error: mount_fusefs: /dev/fuse on /mnt/restic: Operation not permitted
unable to get restore terminal state: 0x5
error in cleanup handler: input/output error
unable to umount (maybe already umounted?): unmount /mnt/restic: operation not permitted

gobackup script works fine as root

export AWS_ACCESS_KEY_ID=myaccesskey
export AWS_SECRET_ACCESS_KEY=12345678
export RESTIC_REPOSITORY=s3:http://192.168.53.4:9000/fcni-freenas
export RESTIC_PASSWORD=tramp123
restic mount /mnt/restic &

4

No idea, that’s entirely a FreeNAS related question. Personally I don’t use it.

I would make a new directory under the user’s home, and try to mount the repository there.

5

I’m not sure how FUSE works on OpenBSD, but if it’s like Linux, there would be a /dev/fuse device. A user needs write access to this device in order to mount FUSE filesystems. On Debian, installing the FUSE userspace utilities creates a fuse group, and /dev/fuse is owned by root:fuse with 660 permissions, so putting a user in the fuse group gives them the necessary privileges.

1 Like
6

@Sumo Any luck yet? How are things progressing?

7

Hello @Sumo @rawtaz and @cdhowie ,

Here’s a possible solution, but I’m not sure it’s the best way to approach this. Please let me know what you think.

The important thing to know about fuse mounts is that by default they are only accessible to the user that started the mount. In restic, the main way to work around this is the --allow-other flag for restic mount. However, by default this will allow all users to access the mount.

A better approach might be something like:

sudo pw groupadd restic_mnt   # Create a group.  This group will be given access to the mount.
sudo pw groupmod restic_mnt -M my_user   # Add the Primary user to the group.  Replace "my_user" with the main user you want to mount as.
sudo pw groupmod restic_mnt -m second_user  # You can add an additional user like this.  Just replace "second_user".  Whatever user you're using WinSCP with will need to be added here.
sudo install -d -g restic_mnt -o root -m 0750 /mnt/restic_mnt
sudo install -d -g restic_mnt -o mount_user -m 0770 /mnt/restic_mnt/restic_mount  # Replace "mount_user" with the user you'll be mounting as.  This user should be part of the "restic_mnt" group.
# Then you can mount with something like this:
restic mount --allow-other /mnt/restic_mnt/restic_mount

Creating two levels of directories seems to be crucial here, because it will prevent access by any user. Even if the directory you’re mounting to itself doesn’t allow other users, once --allow-other is used it will allow anyone to see it. So you need a parent directory to be marked non-readable and non-executable by everyone but a certain group. In this case, I suggest making a group, creating a directory owned by root, but only readable/executable by that group, then creating a sub-directory owned only by the user you want to mount as, but with read and executable permissions for that same group again. When you mount to that sub-directory as that user, as I understand it, standard Unix permissions would prevent access to that mount, except by that group, and possibly root.

Maybe I misunderstood your question though, in which case I apologize.

Does this make sense to you @rawtaz and @cdhowie ? I’m trying to do it in a way that maintains some user security while providing the requested functionality.

Good luck,
jedi453

8

@fd0 We should really implement --fuse-options (since -o is taken) to allow the standard comma-delimited fuse options. default_permissions,allow_other,uid=N,gid=N,umask=007 would solve this without resorting to the above hack.

9

Maybe --mount-options is a more generic name for the option?

10

Thanks for asking. I had other problems so I reformatted my freenas machine to clear up the mess I had made. I’ve put fuse-mount on the back burner.

11

I think that’s a good idea. I’m not sure how to pass the options to the fuse library, we need to find out how to do that and (ideally) just pass on the string from the flag.

12

@fd0 We should really implement --fuse-options (since -o is taken) to allow the standard comma-delimited fuse options. default_permissions,allow_other,uid=N,gid=N,umask=007 would solve this without resorting to the above hack.
I’m using Winscp

13

--mount-options is more generic which is good in the longer perspective. This way, in the unlikely case that we change from FUSE to something else in the future we don’t need to change the name of the option, and users won’t have to change their scripts, etc.

1 Like