The remote user name can be found in the f_mntfromname field from the statfs() call.

@eskimo, There's a new problem I just ran into: If the host is a Windows server, the domain name of the mounted volume resolve to a name that I cannot use - neither directly nor with the proposed SRVResolver. For instance, I set up a Windows server with the netbios(?) name "win-serv", and a volume named "WinServer". When I Get Info on the mounted volume, it shows as: smb://win-serv/WinServer When I retrieve the domain name, e.g. with statfs, the name I get is just "win-serv", but that can't be used as an IP address. I found that I can resolve this name with the shell cmd smbutil lookup win-serv, though. So my questions are: Is there an API for doing what smbutil lookup does? How do I tell that I need to use this method? I guess I could just always fall back to it when I cannot reach the server via its given name, but is there a clearer indicator that this is a WINS(?) and not a usual DNS name? I have a related question on StackOverflow but that hasn't gotten me anywhere, either. This entire WINS/NetBIOS thing is a mystery on macOS, it seems.

BTW, I found out that taking the common name from the certificate is not a reliable identification method to identify Synology NAS systems, because their cert can be self-signed with a custom name. Instead, Synology NAS can be reliably located with the SSDP protocol. I've published code for this here: https://github.com/tempelmann/SSDP-Browser

(Argh, this damn forum software lost my edit to the original post above after I submitted it because I had been logged out due to inactivity. Sonow I have to type it in again. Grrr!) New findings: When I close the Prefs window, the other window becomes briefly activated and then immediately deactivates. I used CGWindowListCopyWindowInfo to compare the windows of the correctly vs the badly behaving app versions, and found no differences. So it's rather something where my window get explicitly deactivated. I have no such calls in my own code, though.

Nevermind this - it was indeed a bug in my code, but not where I looked. I have a helper app that may keep running in the background, and that is tied to the running app in a way that if they're not synched, like it is when the app is signed for TestFlight, it gets something wrong.

I have submitted this to Apple (case number 102307509885). So far, they have not acknowledged anything, though. And the WWDC seems to put a halt on all communications.

Oh my. 8 Years later and I am now seeing the same issue: After making changes to the state of my window, I invoke [self invalidateRestorableState] from my view controller, and yet, when I quit the app soon after (e.g. within a few seconds), the encodeRestorableStateWithCoder handler is not called and then the app restores an older state at the next launch. This is bad.

That looks like decomposed (NFD) unicode form, where an ä is a combination of an a and the two dots, encoded in separate unicode chars. And somehow Xcode(?) is unable to compose them as they should be. Weird. You might be able to fix this by running the strings thru code that re-composes into NFC format, but I guess you have already fixed them all by hand.

Thanks for the warning. I still have an app that runs even on 10.11, so I build it with Xcode 13.4 (running on Monterey) and then use Xcode 14 or 15 to upload it to Apple.

After some more digging, I suspect that the information is stored in the various /Library/Preferences/com.apple.networkextension.….plist files. I tried to alter the file, but that led to the system refusing to boot (fortunately, this was done in a VM). I wonder if there are APIs to access/alter these files in a way that won't damage them.

Thank you for looking into this, Quinn. (The VM I had used had no snapshot (stupid of me), so when I borked it, I had to ditch it and start over, installing a new system from scratch, and then installing Xcode and all the other tools again, which took me quite a while that I would have liked to avoid. Also, I'm glad to be using VMware on a Intel so that I can make snapshots, as the support on Silicon is still a bit ... lacking in this regard :) Ah, creating a new user - of course! I should have known that. Also, there's another related issue: In my testing with a fresh VM I noticed that when I download two versions of my app (release and beta, both signed with my dev ID and notarized, and then both downloaded from same server and thus quarantined), I found that macOS prompted me twice for the "Local Network" permission, i.e. one for each app version I launched. That's different from TCC permissions, where a single permission was always applicable to ALL versions of an app with the same signing ID. And even worse: Even though the System Settings then list the app twice, both use the same name even though I had named them differently, and right-click - Show in Finder shows the SAME app instead of the two separate apps that required to be acknowledge when they accessed the network. So, that appears to be another (minor) bug, though I don't know which would be the proper behavior: Require the permission only once for all apps with the same signing ID, or require them for each version but then list them also properly as individual instances with their own names and file system paths. Can you confirm this misbehavior?

In case others run into this, let me add this warning about the SRVResolver code: In the function QueryRecordCallback, the code first makes some assertions before checking the errorCode. That's likely to cause problems because if you get an error (such as if a user doesn't give your app permission to use the network calls), the asserts may get triggered. To fix this, move the assert calls inside the code that checks for error == 0.

To get started, look at the SRVResolver sample code. In case others run into this, let me add this warning about the SRVResolver code: In the function QueryRecordCallback, the code first makes some assertions before checking the errorCode. That's likely to cause problems because if you get an error (such as if a user doesn't give your app permission to use the network calls), the asserts may get triggered. To fix this, move the assert calls inside the code that checks for error == 0.

Bundle ID and designated requirement are all the same. Path is not, as mentioned above. UUID is also different, as they're different builds. But that just confirms what I suspected: That the privacy permissions are separate for different versions of the same app. However, my concern was that even if that's done on purpose, then System Settings.app / Privacy / Local Network shouldn't show the SAME app version multiple times but should list separate apps, i.e. the different versions it has recorded so far. To illustrate: ... Here I was going to reproduce the issue and show you a screenshot of the Settings app showing multiple instances of the same app, each pointing to the same path. But now that I had re-installed Sequoia and run each app version, they do not multiply in the Local Network list any more as they did before. And the screenshots of this effect that I had done before in the VM are lost when I borked that system. Sigh. Alright, let's drop this for now. I'll get back to this thread should I encounter the problem again. Actually... I just read https://developer.apple.com/forums/thread/737416 which confirms that it's possible that multiple app instances are listed. So you know about this effect. Then let me get back to the issue with that: If you have multiple app instances listed under "Local Network", and if you right-click on them to Reveal them in Finder, you'll get the SAME app revealed each time. This means that the code that lists the multiple instances in the Settings pane does not keep them separate for the sake of indentifying them to the user, which is clearly a bug. Agreed? I'd write a bug report but since I fail to be able to reproduce this, I believe it wouldn't get even any attention. But if you do, could you do something about it, please? Later Ahh - it appears that app versions with the same Signing ID are listed as one instance. Only if the Signing ID is different, e.g. for MAS vs. Indie releases, it's listed multiple times.

Adding to my last "Later" comment: No, sometimes, even new versions with the same Signing ID get added as unique entries. I can't make sense of when this happens and when not, but here's the result: And all 3 "Find Any File" items point to the same file and not, as expected, to the different versions that are all on the disk, at different paths.