Open Radar

 
Summary:
Under 10.12, an issue exists when trying to connect to a server via the NetFSMountURLSync API
If the user has obtained a kerberos ticket, and requests a share that does not exist from the server ie. smb://server.contoso.com/Non_Existent_Share_Name
So via the 'mount volume' command in AppleScript.
Or via the NetFSMountURLSync API in python
Or simply via the Go -> Connect to server menu item

The NetFS API performs as expected by first creating a folder in /Volumes in order to mount the requested share into, however when it attempts to mount the share, it finds that the share name does not exist on the server. Because (presumably) /Volumes is now owned by root in 10.12, NetFS is unable to remove the folder it created in /Volumes as it attempts to remove it as the user, rather than as the root user.


Steps to Reproduce:
1. Obtain a kerberos ticket that is able to authenticate you to a file server (smb://example.contoso.com)
2. Use the connect to server dialog box and enter your file server and a non existent share name (smb://example.contoso.com/Non_Existant_Share)
3. Receive an error message indicating there was a problem connect to the server "example.contoso.com"
4. Observe the contents on /Volumes
5. Note the folder called "Non_Existant_Share" owned by the currently logged in user and unable to be removed by anyone other than root due to the permissions on /Volumes

Expected Results:
When an error is returned trying to mount a particular share from a server, NetFS should clean up after itself and remove the directory it created in /Volumes

Actual Results:
NetFS leaves a folder in /Volumes with the name of the requested share. This folder is unable to be removed by anyone other than root

Regression:
This behaviour does NOT occur in 10.11.6 and earlier

Notes:
Attached a gif showing the observed behaviour.