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?

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.

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.

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.

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.

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.

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.

(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.

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

@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.

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

I found the solution myself by trial-and-error: The NSURL resource key NSURLVolumeNameKey contains the original name. It's not clearly documented that it does, but in my tests that did return the desired result.

@eskimo, With the code from SRVResolver I can indeed resolve QNAS._smb._tcp.local. Problem is: If the host name is a plain one, like syno.local, then I get neither an error nor a callback. And using a Timeout for a local-only NS resolve seems wrong to me. How should I best handle this? Is there a way to tell when I need to use the SRV record resolver?

Alright, I figured out a way to identify the server by contacting it via https and then checking its certificate. That should be pretty reliable. Below the code I use, though I ran into one complication: The mount URL I get for my QNAP NAS is: "QNAS._smb._tcp.local", but that is not a valid host name I can use in a NSURLRequest! I need to transform that into the actual host name, which is "QNAS.local". Since the former is a Bonjour related name, and when I browse the Bonjour registry with BonJeff, I can find the mapping, this seems to be an overly complicated method. I wonder what the proper way is to get the basic host name from such a service name. I've googled for a while but could not find anything about it. For now, I simply remove all components from the host name that start with an underscore, but I'm not sure if that's a safe method. #import <NetFS/NetFS.h> #import <Security/Security.h> #import "AppDelegate.h" @interface AppDelegate () <NSURLSessionDelegate> @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { CFURLRef furl = CFURLCreateWithFileSystemPath(NULL, CFSTR("/Volumes/TheNAS"), kCFURLPOSIXPathStyle, true); NSURL *url = CFBridgingRelease(NetFSCopyURLForRemountingVolume (furl)); NSArray *parts = [[url.host componentsSeparatedByString:@"."] filteredArrayUsingPredicate:[NSPredicate predicateWithBlock:^BOOL(NSString* _Nullable part, id _Nullable bindings) { return ![part hasPrefix:@"_"]; }]]; NSString *addr = [parts componentsJoinedByString:@"."]; NSLog(@"host: %@ -> %@", url.host, addr); NSMutableURLRequest *request = [[NSMutableURLRequest alloc] init]; [request setURL:[NSURL URLWithString:[NSString stringWithFormat:@"https://%@", addr]]]; NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration] delegate:self delegateQueue:nil]; [[session dataTaskWithRequest:request completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) { NSLog(@"Done."); [NSApp terminate:self]; }] resume]; } -(void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential * _Nullable))completionHandler { SecTrustRef trustRef = [[challenge protectionSpace] serverTrust]; SecCertificateRef certRef = SecTrustGetCertificateAtIndex(trustRef, 0); CFStringRef name = nil; SecCertificateCopyCommonName(certRef, &name); NSLog(@"name: %@", name); // reject the challenge because we have all we wanted completionHandler (NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil); } @end

Oh hell! It's not my fault, it's Apple's. The signature appears to be outdated, or refences an expired cert. The fix is to temporarily change the system date to before Oct 1, 2019 for the installation.