MacOS: Apps complain they cannot save existing documents starting with v2.5.0

[doits]

I have the following problem with MacOS Pages and Numbers documents as well as Microsoft Excel documents on MacOS: I open an existing document and try to save it. It fails, saying the document doesn't exist any more (though I still see it in finder). I can specify another filename and save it successfully. Then it behaves differently:

Numbers can save the new document multiple times without error. Unless I close the file and reopen it, then the error is back again.

Microsoft Excel cannot save the document a second time (after it was saved with a different name). The error comes up again and a new name must be chosen.

❌ The problem started with the following gocryptfs version:

gocryptfs v2.5.0.HEAD without_openssl; go-fuse v2.5.0; 2025-05-12 go1.24.3 darwin/arm64

❌ It is still present in the latest version:

gocryptfs v2.5.4.HEAD without_openssl; go-fuse v2.5.0; 2025-05-12 go1.24.3 darwin/arm64

✅ The last working version without this problem is:

gocryptfs v2.4.0.HEAD without_openssl; go-fuse v2.3.0; 2025-05-12 go1.24.3 darwin/arm64

❌ I tried to mount it with current master version but the mounted directory is empty, so I couldn't further test it:

gocryptfs v2.5.4-8-g9b6e47f without_openssl; go-fuse v2.7.3-0.20250306214706-e3463465126a; 2025-05-12 go1.24.3 darwin/arm64

No special mount options:

gocryptfs -ko allow_other -badname '*conflicted*' -extpass xxx src/path mount/point

Can I further debug this to help it getting resolved in newer versions?

[3Galley]

Ive been experiencing the same issue since 2.50 in Mac and incorrectly reported on the wrong thread looks like. My bad (#892 (comment))
Any existing Ms Excel or Ms Word Document cannot be updated within a mount point. It can only be "saved as" a new file with a different name. This is quite inconvenient and ive kept my version at 2.33 due to this issue.

Today I ran several tests to further document the issue and hopefully help find the bug win 2.50+ in Mac using the options --debug --fusedebug --fg

Please find attached the output of the debug mode for just a couple test operations as follows:
-I mounted the volume
-Created the new file excel file Book1.xlsx at the root (saved ok)
-added some data to some cells and saved (gave errors, same errors as my original post before)(#892 (comment))
-Saved the file after closing the 4 error dialogs as Book2.xlsx (saved ok)
-Closed the file, exited Excel
-Dismounted the volume

I can do further testing and provide the logs as needed :)

debug log.txt

Thank you !

[rfjakob]

Thanks for the log. There's A LOT going on.

Can you again capture the log, change some data in Book1.xlsx, and write down the exact time when you click "Save"?

[rfjakob]

Does this also happen with TextEdit? Maybe this generates a less noisy log.

[3Galley]

Thanks for the log. There's A LOT going on.

Can you again capture the log, change some data in Book1.xlsx, and write down the exact time when you click "Save"?

Of course :)

Ive Captured another log with the same options --debug --fusedebug --fg
Order of actions is as follows:
-mounted the cypher dir
-opened the excel file Book1.xlsx
-Pressed save at 00:54:00.654310 , at line 2443 of the log ( I added a comment also in the file)
-Excel gives multiple error messages as shows in my prior screenshots, same errors always
-excel stays open but the Book1.xlsx vanishes from the mounted dir
-closed excel

gocryptfs saving excel file log.txt

[3Galley]

Does this also happen with TextEdit? Maybe this generates a less noisy log.

I captured one for TextEdit
This time I was noting each time for each action as an index if it helps you find where stuff happens:

Event Index:

-01:09:11.938980 tx 2: OK
Mounted CypherDir

-01:09:35.167052 tx 2: OK
Open Folder

-01:09:53.649931 tx 4: OK
Open File TextEditFile

-01:10:29.557235 rx 3: LOOKUP n1 ["TextEditFile.rtf.sb-da588eb6-lxiYfa"] 36b
Attempt to save on same file after adding some data, error

-01:10:35.739331 tx 2: OK
After Saving with error

-01:11:17.829937 tx 4: OK
Close after not being able to save error

-01:11:53.920084 tx 4: OK, {tA=1s {M040755 SZ=192 L=6 501:20 B0*4096 i0:92685518 A 1749100230.085491 M 1749100229.582910 C 1749100229.582910}}
Dismount from Desktop

TextEdit error saving log.txt

Please dont hesitate to let me know if you need any other captures

Talk soon :)

[doits]

I updated to Macfuse 5.0.5 to see if it fixes the problem, still no luck though. Using to the new backend=fskit doesn't help either.

[doits]

I ran a manual bisect between v2.4.0 and 2.5.0 and identified the following:

• last working commit: 6fbe61d
• first commit were the error happens: 0dfa7f8
• following commits between did not compile so I couldn't test it: 9958b63, 1d7dd0a

I suspected the go-fuse update might be the culprit. I tested around and finally: Indeed that is the problem. gocryptfs v2.5.4 with go-fuse v2.4.0 works:

• git checkout v2.5.4
• edit go.mod so that it has github.com/hanwen/go-fuse/v2 v2.4.0
• go get github.com/rfjakob/gocryptfs/v2
• make build
• gocryptfs --version: gocryptfs v2.5.4-dirty.HEAD; go-fuse v2.4.0; 2025-07-03 go1.24.4 darwin/arm64

No error!

---

I tried to upgrade it further and to use go-fuse v2.8.0. It compiled fine but the error is still there.

So the culprit seems to be the updated go-fuse?

[doits]

I was having it today and ran the same manual bisect with go-fuse. To keep it short:

• last working commit: hanwen/go-fuse@c1a4d6c
• commit introducing the error: hanwen/go-fuse@3502146

I'll probably open an issue there.

[rfjakob]

@doits nice work. How did you test when you bisected go-fuse? With gocryptfs? Can you check if https://github.com/hanwen/go-fuse/tree/master/example/loopback also shows the problem?

[doits]

Can you check if https://github.com/hanwen/go-fuse/tree/master/example/loopback also shows the problem?

Good idea! I was bisecting with gocryptfs before (changing go.mod on each try).

I just checked it with the example loopback (from go-fuse v2.8.0 and v2.5.0) and it does not have the problem in either case. I used the same file which has problems inside gocryptfs for the check (a numbers document).

For reference:

• in go-fuse dir: git checkout v2.8.0
• GOOS=darwin go build -o example_loopback ./example/loopback/...
• mkdir a b
• copy file to directory a
• ./example_loopback -allow-other b a
• open b to open mountpoint in finder
• open file in finder and save --> no problems

[rfjakob]

Maybe I'll try https://www.scaleway.com/en/hello-m1/ .

@3Galley thanks for the log with timestamp. It looks like the file is actually saved. Can you confirm? Is the new content there when you open it again?

[doits]

Maybe I'll try https://www.scaleway.com/en/hello-m1/ .

I can sponsor some time for you if you want. Do you accept donations (through github or somewhere else)?

It looks like the file is actually saved. Can you confirm? Is the new content there when you open it again?

In my case everything is saved, yes. Closing the file and reopening works. Though if you do not close it it refuses to save again.

FYI: I just tried gocryptfs v2.6.0, the error persist unfortunately. And there you cannot use go-fuse 2.4.0 anymore (because of the newish directory api), so no way to work around it with older go-fuse.

[rafjaf]

@rfjakob @doits I think this PR #950 fixes the issue