No more auto probe/mount on macOS Sierra (10.12), requires sudo?

[congma]

On macOS Sierra (10.12), using the most recent OSXFuse stable release (3.5.2), with fuse-ext2 compiled from source (up to current HEAD at 400dfacd), there is a behavior change which I believe is a bug.

Desired behavior: External ext4 filesystems are probed and available in macOS "Finder" app without explicit privilege-escalation using sudo. After plugging in the external USB drive, it should be available in Finder and can be mounted/umounted by the user. This is the old behavior on Mac OS X 'El Capitan' and earlier.

Current behavior: the FSes can no longer be probed without sudo rights. After plugging in the drive, nothing happens. The command fuse-ext2.probe /dev/xxx returns with exit code 252, but using sudo, it exits successfully. Similarly, the command fuse-ext2 /dev/xxx path/to/mountpoint fails with 252, but succeeds only under sudo. The mounted FS must be umounted with sudo, too.

Although use is still possible, I wonder if this is a limitation due to the increasingly draconian restrictions in place since macOS 10.12. Is there a workaround to restore the old behavior? Or is there something that needs to be fixed in the fuse-ext2 code?

[muammar]

Is fuse-ext2 working for you in 10.12.1?. I compiled the package, but it does not work for me even with sudo...

[congma]

Is fuse-ext2 working for you in 10.12.1?

Yes. I'm using it to read ext4 partitions on a GPT volume.

[muammar]

Yes. I'm using it to read ext4 partitions on a GPT volume.

I have double boot on my macbook pro, and I cannot make it work. It stopped since September 24. I don't understand why. Thanks for replying.

[Jerry-Ma]

I am currently experiencing the same thing. I really would like to have the WM manage the external drives, instead of having to issue sudo via command line.

Another note is that, if I do sudo fuse-ext2 ..., the mounted partition will be of root privilege and is not accessible directly. However, if I do it with sudo mount_fuse-ext2 ..., it works as expected, i.e., the mounted directory is owned by the current user.

[surak]

@Jerry-Ma I don't even see this "mount_fuse-ext2" available. Should we join this issue with a similar one, https://github.com/alperakcan/fuse-ext2/issues/34 ?

[Jerry-Ma]

@surak I believe the mount_fuse-ext2 is used by OSX to mount the filesystem. If you look in to /sbin/ there are a number of similar commands:

❯ ls /sbin/mount_*
   /sbin/mount_acfs@    /sbin/mount_exfat@      /sbin/mount_nfs*
   /sbin/mount_afp*     /sbin/mount_fdesc*      /sbin/mount_ntfs@
   /sbin/mount_apfs@    /sbin/mount_ftp@        /sbin/mount_ntfs.orig@
   /sbin/mount_cd9660@  /sbin/mount_fuse-ext2@  /sbin/mount_smbfs*
   /sbin/mount_cddafs@  /sbin/mount_hfs@        /sbin/mount_udf@
   /sbin/mount_devfs*   /sbin/mount_msdos@      /sbin/mount_webdav*

By default, fuse-ext2 installs this command in /usr/local/sbin, however, according to my experience with ntfs-3g, it needs to be placed in /sbin (which requires disabling SIP)

Should we join this issue with a similar one, #34 ?

Yes I think so. I checked #34 and tried the fork from @gpz500 (later on I found his work has been already merged to this repo), but with no luck.

I did some investigation, and found the issue seems to be some mis-communication between diskarbitrationd and fuse-ext2. From diskarbitrationd log, I can see that it tries to "probe" the ext4 drive but the probe program (should be fuse-ext2.util -p) for some reason returns failed signal.

For now, I created a shell script for manually probing and mounting Linux drives using diskutil, e2label and fuse-ext2.util

[gpz500]

Hello everyone! I don't think this issue should join #34, because even if the symptom is the same (inability to automatically mount an ext4 filesystem at the insertion of an external drive), the cause seems quite different. In the #34 it was an incompatible option (defer_permissions) passed to fuse-ext2 executable by fuse-ext2.util -m (the mounting process' last step). In this case fuse-ext2.util -p invocation fails, which is a more preceding step. Something must have changed from El Capitan to Sierra: a deeper investigation is needed to find out why the probing under diskarbitrationd is failing on Sierra, but in this moment I don't have much time to dedicate to this... Does anyone have some more information?

[Jerry-Ma]

@gpz500

I spend some time trying to understand where it goes wrong and based on the very limited knowledge I have about how fuse and diskarbitrationd works, it seems that the fuse-exst2.wait never returned successfully, which, according to the logging message, might be due to the fact that it doesn't see the CFNotification posted from libfuse. I tried a different version of fuse_wait from https://github.com/bfleischer/fuse_wait but still no success.

[bayoubengal]

Took me 4 days of trial and error and reading through apple source code, but I have the solution to this problem. file system plugins must be code signed to work. move all the scripts into Contents/Resources and run everything from there. the entire bundle should be owned/grouped by root/wheel. the "command" values in the bundle for the executable keys must be the exact name of the script/binary file in Contents/Resources....it cannot be a posix path.

[bayoubengal]

FYI. the probe "command" key is processed in DAFileSystemProbe() in DAFileSystem.c. you can see in that function that the command path is obtained through a call to ___CFBundleCopyResourceURLInDirectory(). Therefore, trying to give the system a path name to run will not work.