Can't connect to AFP shares with 10.10.4 I just updated the Mac Mini that I use as a file server to the 10.10.4 and the Server App to 4.1.3. After I updated I can't connect anymore to the AFP share that I see in the Finder sidebar on the client, a MacBook Pro.

If I restart the sharing service in the Server App, the connection is successful. After a while, if I click again on the Mac Mini in the MBP Finder sidebar, it says "Connecting..." and then "Connection failed".

The web server on the Mac Mini doesn't respond either. I can't connect either with the "Screen Sharing" button and sometimes it just disappears from the sidebar.

On the MBP when the sharing connection fails it says:

14/07/15 14:10:23,438 sharingd[174]: SDSharePointBrowser::handleOpenCallBack returned 65


or:

14/07/15 15:14:36,418 NetAuthSysAgent[318]: DNSAddressResolver:Resolve CFNetServiceResolveWithTimeout failed
14/07/15 15:14:36,418 NetAuthSysAgent[318]: ERROR: AFP_GetServerInfo - connect failed 64
14/07/15 15:14:36,419 sharingd[179]: SDSharePointBrowser::handleOpenCallBack returned 64
I'm not 100% sure this is exactly related to the question at hand, but it might help some with this issue.


  TL;DR: make sure your machine does not include . or \


First. back in OSX 10.9.x Apple changed the default file share service from AFP to SMB2, meaning if you use Finder to connect to a machines file share the machine will try SMB then it should try AFP if SMB fails.

I have just spend far too long looking at Wireshark conversations between a 10.10.5 client and 10.11.3 file server to see what was going on and I think may have found the reason this sometimes fails for some users.

First a setup that seems to work:
The server computer name is configured to Computer 1 (note the space) in the System Preferences &gt; Sharing pane. the netbios name for this machine is different but that does not come into play when connecting via Finder.

This results in Bonjour populating the client machine with a computer 1 in the Shared section of the side bar. when you click on this shared item and then click the Connect As... button the following conversation happens between the client and server:

CLIENT: Tree Connect Request: \\computer 1._smb._tcp.local\IPC$
SERVER: STATUS_SUCCESS
CLIENT: Create Request File: srvsvc
...
CLIENT: Finder receives Directory listing


This works as expected, you click on the server enter your credentials and get access to the resources.

Now a configuration that does not work, same setup as above but this time the server name is changed to computer.1 (using a dot instead of a space), this results in the following client server conversation:

CLIENT: Tree Connect Request: \\computer\.1._smb._tcp.local\IPC$
SERVER: STATUS_BAD_NETWORK_PATH
CLIENT: Tree Connect Request: \\&lt;ip address&gt;\IPC$
SERVER: STATUS_SUCCESS
CLIENT: Finder displays Connection Failed


There are two interesting parts to this:


The client escapes the . to \. causing the server to report back a bad path
As soon as the client notices the bad path error it tries connecting with the server IP address, that succeeds, but the client does not ask for a directory listing and displays the Connection Failed.
The connection does not fall back to AFP when SMB fails.


This seems like a bug in the OS's handling of invalid characters to the SMB protocol and proper fallback to either IP or AFP in the case of a failure.

I tested all of the US face special characters are the following characters are cause this problem: . (period) and \ (backslash). Every other character seems to work fine (e.g. !, @, %, ? ...) though I did not do an exhaustive check as the ascii character space.