Weird problem: kernel[0]: osxfuse: caller not a member of osxfuse admin group (80)

[Nickolay Olshevsky]

Hi all,

I have weird problem on one of the Mac installations of fuse-based application.
It works fine on thousands of installations, however on one fuse doesn’t mount, giving the error message in console:

2017-01-31 11:04:08,000 kernel[0]: osxfuse: starting (3.5.4, Dec 1 2016, 22:16:35)
2017-01-31 11:04:08,000 kernel[0]: osxfuse: caller not a member of osxfuse admin group (80)
2017-01-31 11:04:08,000 kernel[0]: osxfuse: caller not a member of osxfuse admin group (80)

I’m trying to mount at ~/MyDrive.
Fuse kext is running:

kextstat |grep fuse
125 0 0xffffff7f829ab000 0x19000 0x19000 com.github.osxfuse.filesystems.osxfuse (3.5.4) A300818E-4DF9-37E4-A8A0-FDCE7A8B0C8C <7 5 4 3 1>

The system has weird permissions as I see:

id=1226335343(username) gid=1019100241 groups=1019100241,206(com.apple.loginwindow.netaccounts),705(com.apple.sharepoint.group.5),702(com.apple.sharepoint.group.2),12(everyone),62(netaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),704(com.apple.sharepoint.group.4),223(com.apple.access_loginwindow),703(com.apple.sharepoint.group.3),701(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator),204(_developer),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh)

Folder at mountpoint is created:

drwxr-xr-x 2 magnus 15441 68 31 Jan 11:19 MyDrive

So, anybody has any guess what happens here? And, where those weird group/user ids came from? Seen this on some systems.
Thanks!


Best regards,
Nickolay Olshevsky

[Sam Moffatt]

Hi Nickolay,

I suspect you’re using something like allow_other or allow_root which needs special privileges (https://github.com/osxfuse/osxfuse/wiki/Mount-options#allow_other) and the error message is that the user who is trying to execute the mount doesn’t appear to be in group 80 which is the admin group. 

The output you have shows you’re a member of the admin group so I’m not sure if that’s your account or someone elses. Is the user an admin on the device and is the context this is running under including that group ID?

Cheers,

Sam

P.S. Most of those groups are normal apple groups plus at each of the sharepoint groups will map to a share on your computer somewhere. I wouldn’t be worried about them.

Sam Moffatt
http://pasamio.id.au

--
You received this message because you are subscribed to the Google Groups "OSXFUSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-group+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nickolay Olshevsky]

Hi Sam,
Thanks for the reply.

I forgot to mention - I’m using ‘allow_other’ when mounting.
That’s was TeamViewer session to the user’s account who experience this problem.
And id output was from the same account, i.e. user is indeed in admin group.
Application is run in user’s context - i.e. by Finder from /Applications/ , so as I understand it should inherit user’s group permissions?

The strange-looking for me was user’s id and his group - while on other systems it’s 501 and 20 (staff), here these are 1226335343 and 1019100241.


Best regards,
Nickolay Olshevsky

To unsubscribe from this group and stop receiving emails from it, send an email to osxfuse-grou...@googlegroups.com.

[Sam Moffatt]

Hi Nickolay,

I believe those IDs are generated when you connect the Mac to a network directory service like Active Directory. I don't quite understand why it doesn't think it the group ID is correct for what ever reason if the session is ok otherwise. Is it possible that it is being launched under some other context?

Cheers,

Sam

--

Sam Moffatt

http://pasamio.id.au

Note: I'm not at my desk, responses may be delayed. Apologies for the typos, smartphones aren't all that smart. 

[Nickolay Olshevsky]

Hi Sam,

As I checked in activity monitor process is run by the same userid. I.e. should be included in ‘admin’ group.

Or there is other, better way to check the process context/group ids?

Best regards,

Nickolay Olshevsky