[3.8.3, Mojave] osxfuse_admin_group is 0 after initial install, 80 on kext reload

[emou]

Repro case: OSX Mojave, osxfuse 3.8.3, seems to work with 3.9.0 although I couldn't find any related changes that explain why.

• On a fresh OSX installation install for the first time, allow the blocked extension in the preferences pane.
• The admin_group is set to 0:

$ sysctl vfs.generic.osxfuse.tunables.admin_group
vfs.generic.osxfuse.tunables.admin_group: 0

• Unload the module (reboot works as well)

$ sudo kextunload -b com.github.osxfuse.filesystems.osxfuse

• Load it again

$ sudo /Library/Filesystems/osxfuse.fs/Contents/Resources/load_osxfuse

• admin_group is now 80 ("admin"):

$ sysctl vfs.generic.osxfuse.tunables.admin_group
vfs.generic.osxfuse.tunables.admin_group: 80

[ipatch]

Can confirm getting the same reset behavior on macOS 10.13.6

sw_vers

Output

ProductName: Mac OS X
ProductVersion: 10.13.6
BuildVersion: 17G6030

[emou]

Note that it seems to work in 3.9.0 using the installer from the github releases page.
@bfleischer Is the installer in 3.9.0 by any chance setting the group in a postinstall script?
If yes, do you plan to fix it in the core code, so this behavior doesn't depend on the installer?

[bfleischer]

When FUSE is installed, the installer tries to load the kernel extension, but does not initialize the admin group sysctl. Later when you try to mount a volume, FUSE detects that the kernel extension is already loaded and does not set the admin group either. As a workaround you can unload the kernel extension after the installation is complete or reboot your Mac.

[ipatch]

@bfleischer

Not trying to contradict what you said above but from my experience the FUSE kext does not load until I try to mount a file system that relies on the kernel extension itself. That said, I install osxfuse via brew along with the various fuse file systems, ie. fuse-ext2 and ntfs that I work with via brew as well. Before I upgraded to 3.9.0 the other day I was having to set the below,

allow_other: 1
admin_group: 506

A specific group I set up for various users on my box to mount file systems. I was having to set both of those settings every time the 3.8.3 kext was unloaded then loaded, ie. the settings were not persisting through reloads.

And on a completely separate note I have not been able to mount a ntfs file system without superuser perms, ie. I'm having to use sudo to mount ntfs file systems peresently, ie. running both 3.8.3 and 3.9

I've put together an asciicast that can be viewed below,

https://asciinema.org/a/246431

And, have converted the cast to a gif attached to this post,

[emou]

@bfleischer thanks for the reply! However, I am still wondering why the behavior with 3.9.0 is different vs 3.8.3 on a fresh OSX Mojave install. Immediately post-installation (after allowing the extension) with 3.9.0 the osxfuse admin group is set to 80, while with 3.8.3 it is 0.

[bfleischer]

The issue is fixed in the new 3.9.1 release.

@emou Like I said code-wise there is no difference between 3.9.0 and 3.8.3 in this regard. When installing FUSE there is a race between the installer loading FUSE, which sets the admin group to 80, and the system preferences loading FUSE after the user clicked on the allow button, which does not set the admin group at all. The behavior is pretty much undefined and depends on who wins the race.

[emou]

The behavior is pretty much undefined and depends on who wins the race.

@bfleischer so there's nothing that you think can be done to fix this?

[bfleischer]

Please see my previous comment, the issue is fixed in 3.9.1 and 3.9.2.