macOS, -reverse mode, fs.Mount failed: read-only file system

[extr15]

Hi, thanks for your work. The normal mode of gocryptfs works fine in my macOS, but the reverse mode doesn't work:

fs.Mount failed: read-only file system
Maybe you should run: /Library/Filesystems/osxfuse.fs/Contents/Resources/load_osxfuse

I don't have /Library/Filesystems/osxfuse.fs/Contents/Resources/load_osxfuse, but I tried /Library/Filesystems/macfuse.fs/Contents/Resources/load_macfuse, which had no output and gocryptfs still failed with the same error.

My macOS is 10.14.5, and I compiled gocryptfs by:

Install Macfuse
Install go
Download / Clone this repository
Run bash ./build-without-openssl.bash

I tried gocryptfs -d -fusedebug -fg -reverse plain cipher, and the last few output:

23:57:24.475219 rx 3: ACCESS n1 {u=501 g=20 x}
openBackingDir "" -> 10 "" <nil>
23:57:24.475374 tx 3:     OK
fs.Mount failed: read-only file system

I appreciate your help.

[rfjakob]

Checking in the code, the one thing that is different in a reverse mount is that it is read-only (ro).

Can you check if a normal mount also fails when you mount with -ro, like this?

gocryptfs -ro cipher plain

[page-down]

macOS 11.6 macFUSE 4.2.0

gocryptfs 2.1 without openssl gocryptfs 2.2.0-beta2 without openssl

$ gocryptfs -ro cipher plain
...
fs.Mount failed: read-only file system
...

Tried using another fuse program, mounted with the ro read-only option, and everything works fine. This does not appear to be an issue caused by macOS, macFUSE, or go-fuse.

[valeriangalliat]

Hey! I'm running into the same issue

I could work around it by commenting this line: https://github.com/rfjakob/gocryptfs/blob/a2b54cfccd7d67529f87309c84ab7c00a8b6a4b0/mount.go#L443

macOS 12.1 macFUSE 4.2.4 gocryptfs v2.2.1-32-ga2b54cf-dirty

Actually, I tracked it down to the pollHack function in go-fuse poll_darwin.go which tries to write a file to the mountpoint as a way of asserting that the FUSE server is properly started... which is why we get a fs.Mount failed: read-only file system error during the mount.

https://github.com/hanwen/go-fuse/blob/0f728ba15b38579efefc3dc47821882ca18ffea7/fuse/poll_darwin.go#L35

It looks like the Linux pollHack only accesses the "hack file" as O_RDONLY (and I realize that's thanks to a commit of yours @rfjakob https://github.com/hanwen/go-fuse/commit/fee50bf01cd60f66c82493761756b2c345a86aa3) so I assume we could apply a similar patch in poll_darwin.go? I have a proposal PR for this here https://github.com/hanwen/go-fuse/pull/420

[rfjakob]

Nice! Does your patch fix the problem? You will have to sign Google's CLA (Contributor License Agreement) otherwise hanwen cannot merge the patch. hanwen is employed by Google and go-fuse is developed on company time as far as I understand.

[valeriangalliat]

Yep the patch did fix the problem!

I signed the CLA when I saw the bot comment and re-pushed to make the CI pass so everything should be good on that end :relaxed:

[page-down]

@valeriangalliat

... so everything should be good on that end

I'm not sure. It seems to me that no GitHub PR has ever been merged after 2019. It looks like you need to submit in Gerrit Hub.

quote from hanwen

please upload a change to gerrit hub as descibed in CONTRIBUTING.

[krim404]

@valeriangalliat forgot to push the change to gerrit-hub Fixed in upstream of library go-fuse

I recompiled gocryptfs with latest version of go-fuse (vendored) on MacOS 12.5.1 on Apple Silicon, problem seems to be solved.

[rfjakob]

Fixed via https://github.com/rfjakob/gocryptfs/commit/0ec7ffbfe96887f25feb7fda60b984ea18a42e0f