mount repository on read-only filesystems with --no-lock fails

[unclesamwk]

Output of restic version

restic 0.8.1 (v0.8.1-121-g94ec55f)
compiled with go1.9.2 on linux/amd64

How did you run restic exactly?

(/data type ext4 (ro,relatime,errors=remount-ro,data=ordered))

/usr/local/bin/restic mount --no-cache --no-lock -p /tmp/secret.pw -r /data/somefolder1/somerepo4567 /mnt/somerepo4567

Save(<lock/5e59d1c2e1>) returned error, retrying after 434.695773ms: OpenFile: open /data/somefolder1/somerepo4567/locks/5e59d1c2e168d883167983d8ed6961dcc807be6ef860243abf372049a7f01d21: read-only file system
unable to create lock in backend: OpenFile: open /data/somefolder1/somerepo4567/locks/5e59d1c2e168d883167983d8ed6961dcc807be6ef860243abf372049a7f01d21: read-only file system
unable to umount (maybe already umounted?): exit status 1: fusermount: failed to unmount /mnt/somerepo4567: No such file or directory

What backend/server/service did you use to store the repository?

local/restic

Expected behavior

Mount repo read-only without trying to access/write/read a lock file inside the read-only repo folder

Actual behavior

Fails while accessing/writing to lock folder inside the read-only repo folder

Steps to reproduce the behavior

See above

Do you have any idea what may have caused this?

Bad implementation of --no-lock arg

Do you have an idea how to solve the issue?

Don't try to access lock folder inside read-only repository on read-only filesystem when --no-lock is provided

Did restic help you or made you happy in any way?

Not fully yet

[unclesamwk]

Its a bug?

[fd0]

Hey, thanks for the report. Only very few of restic's commands work without locking, and mount isn't one of them. The reasoning behind it is that the code fails hard when data is removed from the repo (e.g. via prune or forget) while the mount is active. I don't consider this a bug at the moment.

What's your use case?

[unclesamwk]

"Mount repo read-only without trying to access/write/read a lock file inside the read-only repo folder"

[fd0]

I was interested in the background: Why do you want to do that? Is it because you have a restic repo on a read-only medium like a DVD? Or is it for safety reasons? Or a read-only (lvm?) snapshot of some kind?

I think this is not a bug (at least for now, maybe it's a feature request?) but I don't have the full picture yet, so I'm trying to understand what your motivation is :)

[unclesamwk]

Hello,

the usecase is to mount a repository inside of a readonly path.
The readonly path is a ro volume inside a docker container.
Therein the repo must be mounted ro and will be scanned via clamd. A list of malware hits is generated.
To ensure security - repo may contain executable malware - inside the whole docker container and the repository write access must be avoided.

It is essentially to be able to mount a repository readonly or be able to provide a writeable locking file path outside of the repo (for example in /tmp) if real readonly can not be implemented in restic.

[fd0]

Thanks for the feedback. I understand your use case a bit better now.

You can work around this limitation in restic already, if you're able to mount new volumes in the container: Either mount a new tmpfs at the locks/ subdir in the repo, or use mount --bind to mount a different directory there. It's not pretty but works.

[jsissom]

I backup my files on a Windows box to an NTFS hard drive. Today I tried to restore on my mac. NTFS is read-only on the Mac. I was unable to do so. This command:

restic mount --help

implies that it will work since it says no-lock is a global option. It appears it is not and now I cannot restore my backup. Since a restore shouldn't over write the source, I believe this should be a valid option for mount. Any command that writes the repository could fail when given a read-only repository.