Tahoe 26.4 breaks custom paths with NetFSMountURLSync?

Question

Created 5h

Replies 1

Boosts 0

Participants 2

Just wondering if anyone ran into this issue.

I use NetFSMountURLSync for my application with which I allow the user to use a custom path as a mount point (instead of "/Volumes"). This has worked just fine for at least a decade now, but ... since the Tahoe 26.4 "update" mounting to a custom path only generates errors.

Note: Mounting to "/Volumes" works correctly (mountpoint = NIL).

Since I'm unaware of any changes; is this a bug introduced by Tahoe 26.4, or should I be using a different function to mount a network share?

Boost

Answer 1

DTS Engineer OP

Apple

21m

I use NetFSMountURLSync for my application with which I allow the user to use a custom path as a mount point (instead of "/Volumes").

Just to confirm, are you mounting with the "no UI" flag? The actual issue here is that mount points outside of "/Volumes/" are now triggering a user approval dialog, which means the mount then fails if you pass in kNAUIOptionKey.

Since I'm unaware of any changes, is this a bug introduced by Tahoe 26.4, or should I be using a different function to mount a network share?

It's at least partially a bug (r.172210106), but I'm not sure what the parameters of the fix will actually be. In particular, the previous behavior around what was allowed here:

I allow the user to use a custom path as a mount point (instead of "/Volumes").

...was significantly broader than it should have been, allowing apps to target mounts that they didn't otherwise have access to or authorization from the user. Exactly what will trigger the approval dialog may continue, but at a minimum, mounts to:

/Volumes/ (the default)
Any location inside an app’s own container

...should work without triggering the dialog.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0