Need help with fusermount error msg

Making progress with my attempt to view my respository, but still not there yet (I HAVE gotten this to work well, in the past) -

tomc@ANB:~/programs$ ./restic -r /media/tomc/usbHD2-lv1/_restic-bkup/dropbox/ mount /view
enter password for repository: 
repository 268a4ff8 opened successfully, password is correct
Mountpoint /view doesn't exist, creating it
mkdir /view: permission denied
unable to umount (maybe already umounted?): exit status 1: fusermount: entry for /view not found in /etc/mtab
tomc@ANB:~/programs$

“Permission denied?” - I can’t account for this

Maybe the fusermount error message is merely artifactual…?

Would appreciate help with this!

Mountpoint /view doesn't exist, creating it
mkdir /view: permission denied

The permission denied error comes from an attempt to create the mountpoint. Presumably /view doesn’t exist, but your (non-root) user doesn’t have access to write in /.

Try mounting it somewhere under $HOME.

1 Like

Well, but…

tomc@ANB:~/programs$ ls -d */
view/
tomc@ANB:~/programs$ ./restic -r /media/tomc/usbHD2-lv1/_restic-bkup/dropbox/ mount /view
enter password for repository: 
repository 268a4ff8 opened successfully, password is correct
Mountpoint /view doesn't exist, creating it
mkdir /view: permission denied
unable to umount (maybe already umounted?): exit status 1: fusermount: entry for /view not found in /etc/mtab
tomc@ANB:~/programs$ 

/view exists, and was created by me (tomc) as a user only.

Grasping at straws, I deleted /view, and reran the command. I got precisely the same error message.

I’ve no idea what to try next.

Your own user should not be able to create directories in / unless you have non-standard permissions.

What is the output of: ls -ld /view ~/view

How did you create this directory in the first place?

Okay, I’m dumb, the answer is in your post:

This indicates that the directory ~/programs/view exists, which is not the same as the directory /view. Adjust your restic mount command accordingly and try again.

I was just about to comment about that. And it appears that you’re saying I’m referencing that dir (/view) incorrectly in my command. Hope you’re right, as that would be a great explanation for the problem I’m having. Am off to check this out…

Thanks!

Yep, prefixing the path with a / makes it absolute, which means the path starts at the very root of the filesystem. Run these commands and observe the output:

ls -l /
ls -ld /view

The first shows you the contents of the filesystem root, which should be things like bin, etc, home, and so on. The second should return an error because there is no view directory that exists under the filesystem root.

And…we have a winner!

So, my only ever intermittent interaction with the Linux command line remains a stumbling block. My expertise is treating psychological trauma, not parcing path strings, and it shows. Apparently “/view” is NOT the way to refer to a dir in the pwd. Didn’t know. Do now.

Very happy to have access to my backup. Thanks for riding along with me today until I got home. A huge help, as I really do have work to do, but an empty /home dir is in my way. I can now restore and get back to work.

And I continue to love the elegance, directness, and simplicity of restic. Very very nice to have this backing ME up! Ditto for the restic forum…

1 Like

Thanks. That little piece of command line code is going into my notes, as it makes the distinction very clear.

Those notes are part of what I’ll be restoring, now that I have access to my backups. Nice to have this all back!

1 Like

You’re correct. ./view or simply just view will do the trick. (Explanation for ./view: . always refers to the working directory, so ./view means “a directory called view that exists under the working directory.”)

Most commands will parse a path as relative to the working directory by default, unless it’s prefixed by / – then it becomes absolute. (A notable exception is your shell when running a command. Generally, typing foo won’t run an executable called foo in your working directory; it will instead search the directories named in your $PATH environment variable for the binary, unless you have . in your path which is non-default and a security hazard. However, you can type ./foo instead to force your shell to look in the working directory instead.)

Glad you got access to your backups!

1 Like