MacOS Ventura: Failed to remove tempfile

[secwang]

Summary

Failed to remove tempfile at /var/folders/37/3fy66clj37d268n32wsfm8400000gn/T/gopass-edit3522339400/secret: failed to unmount /dev/disk5 from /var/folders/37/3fy66clj37d268n32wsfm8400000gn/T/gopass-edit3522339400: exit status 1

Steps To Reproduce

gopass edit

Expected behavior

exit 0

Environment

• OS: [e.g. Mac OS X High Sierra, Ubuntu 18.04, Windows 10, ...] Mac os x ventura
• OS version: [uname -a] Darwin xxxx 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:54 PDT 2022; root:xnu-8792.41.9~2/RELEASE_X86_64 x86_64
• gopass Version: [gopass version] gopass 1.14.9 go1.19.1 darwin amd64
• Installation method: [e.g. from source, brew, gopass repo] brew

Additional context

[secwang]

is sandbox error?

[dominikschulz]

I haven't tried Ventura, yet. Maybe Apple introduced some new "improvements"?

[davenaylor]

I upgraded to Ventura this evening and am experiencing this very same issue.

[fw8]

I had the same behavior prior to Ventura... and unfortunately upgrading to Ventura doesn't make the error go away.

Btw. the mount can then be easily removed by hand! However, editing or creating new secrets is not possible.

[lionello]

Same error is shown for me after Mac OS update, although gopass edit did appear to have worked.

[dominikschulz]

@fw8 This is very annoying, but the error reported should not prevent anyone from editing or creating secrets.
If that's the case, and especially if it did happen prior to Ventura, please do open a separate issue with the GOPASS_DEBUG_LOG output. This issue will be used to track the Ventura issue.

[opax]

I have the same issue with Ventura, gopass 1.14.10 go1.19.3 darwin arm64.

Executing with debug output looks like this:

GOPASS_DEBUG_LOG=1 gopass edit test
Initialized /dev/rdisk5 as a 16 MB case-insensitive HFS Plus volume
Unmount of all volumes on disk5 was successful
Unmount of all volumes on disk5 was successful
Unmount of all volumes on disk5 was successful
Unmount of all volumes on disk5 was successful
Unmount of all volumes on disk5 was successful
Unmount of all volumes on disk5 was successful
Unmount of all volumes on disk5 was successful
Unmount of all volumes on disk5 was successful
Failed to remove tempfile at /var/folders/dd/htl7qmvx5mj88rt0qhvs15mw0000gn/T/gopass-edit3300328917/secret: failed to unmount /dev/disk5 from /var/folders/dd/htl7qmvx5mj88rt0qhvs15mw0000gn/T/gopass-edit3300328917: exit status 1

And, as already reported, unmounting manually with e.g. umount /dev/disk5 succeeds without any problems.

[brianjkinney]

I am seeing this issue as well and it appears as if diskutil unmountDisk is not working correctly on Ventura.

$ GOPASS_DEBUG_LOG=1 gopass edit test      
Initialized /dev/rdisk3 as a 16 MB case-insensitive HFS Plus volume      
Unmount of all volumes on disk3 was successful      
Unmount of all volumes on disk3 was successful      
Unmount of all volumes on disk3 was successful      
Unmount of all volumes on disk3 was successful      
Unmount of all volumes on disk3 was successful      
Unmount of all volumes on disk3 was successful      
Unmount of all volumes on disk3 was successful      
Failed to remove tempfile at /var/folders/3k/l7_1t5hj3wnbb9kfcqnsmbr00000gn/T/gopass-edit1373982785/secret: failed to unmount /dev/disk3 from /var/folders/3k/l7_1t5hj3wnbb9kfcqnsmbr00000gn/T/gopass-edit1373982785: exit status 1            

I was looking at the code to determine what it's doing and it seems like the failure is on the eject:
https://github.com/gopasspw/gopass/blob/master/pkg/tempfile/mount_darwin.go#L83-L110

gopass runs a diskutil unmountDisk and then a diskutil eject on the device, but on Ventura the disk is still showing as mounted after the unmountDisk which causes the eject to fail.

$ diskutil unmountDisk /dev/disk3      
Unmount of all volumes on disk3 was successful      
$ diskutil eject /dev/disk3      
Volume failed to eject      

Note: I have omitted the quiet passed to eject so that stderr is not suppressed.

If I umount the device first, then I can eject it.

$ umount /dev/disk3      
$ diskutil eject /dev/disk3      
Disk /dev/disk3 ejected      

I was able to work around the issue with the following change: PR

It doesn't seem like this change should be necessary, but I'm not sure why the change in behavior. If diskutil unmountDisk was unmounting the disk as expected, this should just work.

[dominikschulz]

@brianjkinney Thanks a lot for the investigation and the PR. I'll try it out myself on Ventura and if it works as expected we'll merge it.

[brianjkinney]

I was digging into this a bit more, and from what I can tell the mount command doesn't get captured in the mount information for diskutil.

Here I create a disk and then mount it using the mount command which is how gopass handles it.

$ temp_dir=$(mktemp -d -t test-edit)
$ disk=$(hdid -drivekey system-image=yes -nomount ram://32768 | tr -d '[:space:]')
$ newfs_hfs -M 700 $disk
Initialized /dev/rdisk2 as a 16 MB case-insensitive HFS Plus volume
$ mount -t hfs -o noatime -o nobrowse $disk $temp_dir

You can see that diskutil doesn't see the disk as mounted and so when trying to unmount it doesn't appear to do anything.

$ diskutil info $disk | grep Mount
   Mounted:                   Not applicable (no file system)
$ diskutil umountDisk $disk
Unmount of all volumes on disk2 was successful
$ mount | grep ^$disk
/dev/disk2 on /private/var/folders/3k/l7_1t5hj3wnbb9kfcqnsmbr00000gn/T/test-edit.3urnZenR (hfs, local, nodev, nosuid, noatime, nobrowse, mounted by brkinney)
$ umount $disk
$ mount | grep ^$disk
$

If instead I use diskutil mount to mount the filesystem, now you can see that diskutil recognizes the filesystem as mounted and now diskutil umountDisk works correctly.

$ diskutil mount nobrowse -mountOptions noatime -mountpoint $temp_dir $disk
Volume untitled on /dev/disk2 mounted
$ diskutil info $disk | grep Mount
   Mounted:                   Yes
   Mount Point:               /private/var/folders/3k/l7_1t5hj3wnbb9kfcqnsmbr00000gn/T/test-edit.3urnZenR
$ diskutil umountDisk $disk
Unmount of all volumes on disk2 was successful
$ mount | grep ^$disk
$ diskutil eject $disk
Disk /dev/disk2 ejected

I believe that prior to Ventura, diskutil had this mount information, and so it definitely seems like a change in behavior after the upgrade. I'm not sure if this works for anyone on Ventura or if it's just some users seeing the failure.

My earlier PR was to attempt a umount if it appeared the diskutil unmounDisk didn't work. But instead this could also be changed to do one of the following:

1. Replace the mount command with diskutil mount
2. Replace the diskutil unmountDisk with umount

I'm not trying to rush things, just wanted to provide some possible alternatives that may be cleaner than my original PR.