Tahoe 26.4 breaks custom paths with NetFSMountURLSync?

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

Hi Kevin, thanks for replying 😊

I am indeed using the kNAUIOptionKey option. Thank you for pointing that out - I would have never found this on my own 😊

Removing this option now works for mounting but kind-a defeats the purpose of calling NetFSMountURLSync since it now shows 3 dialogs (even after the initial approval, and storing the credentials in keychain - it now always asks all 3 questions):

1. Asking for Approval
2. Asking for username and password
3. Asking which share to mount

Basically everything one would want to avoid from happening especially when considering that mounting the the default "/Volumes" path, and that using "mount_smbfs" totally ignores this new "feature".

Note: I did report this unexpected behavior in Feedback Assistant (not sure if that would even be the correct place to do this).

For now I'll disable this option (mounting to a custom mountpath using NetFSMountURLSync).

Just being curious, what do you mean with "Any location inside an app’s own container" ?

Again; thank you very much for the prompt response 😊

Hello, why do not use NSWorkspace.shared.open(url) instead?

Removing this option now works for mounting but kind of defeats the purpose of calling NetFSMountURLSync since it now shows 3 dialogs (even after the initial approval, and storing the credentials in the keychain - it now always asks all 3 questions):

Yes. To be clear, I was simply pointing out how kNAUIOptionKey was involved with this, not suggesting removing it was a fully acceptable alternative.

Note: I did report this unexpected behavior in Feedback Assistant (not sure if that would even be the correct place to do this).

Yes, that's the right place. What was the feedback number?

Just being curious, what do you mean with "Any location inside an app’s own container“?

First, just so this is clear, mounting in your app's container doesn't work "today" (macOS 26.4), but is something that should work once we've corrected the current bug.

In any case, every sandboxed app has its own private directory hierarchy which it can freely store files inside. In API terms, it's the location returned by "NSHomeDirectory()" in a sandboxed app. FYI, if you haven't adopted the app sandbox, then I think that's a choice you should reconsider.

Would this allow me to mount a network share to a custom mountpath, by providing URL, username, and password without macOS asking any questions (besides the initial permission question when the app runs for the first time doing a mount)?

No, not really. Theoretically, you might be able to pass in the user/pass as part of the URL, but it would always mount in "/Volumes/" and there are probably cases where it would present UI. Practically speaking, you'd be better off calling NetFSMountURLSync() without a mountpoint.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Yes. To be clear, I was simply pointing out how kNAUIOptionKey was involved with this, not suggesting removing it was a fully acceptable alternative.

That makes sense and is how I interpreted it. For now I had to disable it though so user do not run into issues. Or better set: I do not get bombarded with support questions 😊

Yes, that's the right place. What was the feedback number?

Feedback number: FB22380104

Thank you for the details on mounting inside app's container. Learning something new every day 😉

That makes sense and is how I interpreted it. For now, I had to disable it though so users do not run into issues. Or better set: I do not get bombarded with support questions 😊

Fair enough!

Feedback number: FB22380104

Perfect, thank you. FYI, it's likely that you'll be notified that this bug is a duplicate in the next few days. Many developers interpret this as meaning that their bug was unnecessary and is being "ignored“; however, that's a misunderstanding of what's going on, particularly when someone at Apple (like "me") asks for a bug.

As you might imagine, the combination of our own testing and the volume of users means that it's pretty likely that SOMEONE has filed a bug "before you". So, yes, that means that many bugs are effectively telling us about an issue we already "knew" about. However, what gets missed there is that the reason to file a bug isn't just to "tell us about the problem“; it's also about documenting impact so we can properly prioritize work and scheduling.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware