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
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 > 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$
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$
CLIENT: Tree Connect Request: \\<ip address>\IPC$
CLIENT: Finder displays Connection Failed
There are two interesting parts to this:
- The client escapes the
\. 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.