Ever since upgrading our OS X Server to Mavericks we have had issues with AFP. Clients will randomly get disconnected (both Mountain Lion and Mavericks clients). Any files that user had open at disconnect are then locked by the server and can only be unlocked by rebooting. Looking in the Connected Users list on the Server App shows multiple connections from each user/host, some of them days old (previous connections). For the past few months I have been rebooting the server weekly so that people can get to their locked files.

This week I decided to have everybody switch to SMB as that seems to have fixed the problem. One issue. The e-mail I sent out told everybody to use smb:// instead of cifs://.  Well, ever since 10.9.2 Apple introduced a new bug that prevents you from copying files to an SMB2 (smb://) server, it gives the error in Finder:

The Finder can’t complete the operation because some data in “filename” can’t be read or written. (Error code -36)

And the Console shows the following messages:

smb_ntstatus_error_to_errno: Couldn’t map ntstatus (0xc000010c) to errno returning EIO
smbfs_set_create_vap: smbfs_setattr, error 5

A little bit of research shows that 0xc000010c error code to be something about an invalid SID being sent to the server, which it couldn’t map to a proper GUID so it aborts and returns an error.

Well that is just great, now all my users can’t create any files on the server. Way to win over the masses Apple.  I may be an Apple fanboy but seriously, have you heard of quality control?

I didn’t want to look (more) stupid by sending out yet another e-mail asking everybody to use cifs:// instead. I figured there had to be a way to default things to SMB1. I found a number of articles detailing how to do that on each client, but I didn’t want to go around editing each workstation (70+). There had to be a way to do it on the server.

Found it! I found the preferences on the server in /Library/Preferences/SystemConfiguration/com.apple.smb.server.plist. A google of that filename led me to this page in Apple’s open source repository. It mentions a key called ProtocolVersionMap which it says is a bitmap of which version are supported, by default it is 3 (bits 1 and 2, so it supports both SMB1 and SMB2). You need to edit this file and make the end of the file look like this:

    <string>WORKGROUP</string>
    <key>ProtocolVersionMap</key>
    <integer>1</integer>
</dict>

The important lines are the two in bold. This tells the SMB server to only support version 1 of the SMB protocol (i.e. cifs://). Now we need to tell the server to reload those changes. In theory this should happen automatically, but it didn’t seem to take effect without a manual reload from me.

sudo /usr/libexec/smb-sync-preferences

This will cause the SMB server to resync from the preferences file, without disconnecting any existing users (so it seems). Ignore the “already loaded” and “already in use” errors. Dunno why they show up.

Now when you connect to the server from any client (this only affects new connections, not existing) it will force to SMB1, even if you use smb://. You can test this by trying to copy a file before and after. Other than that I know of no way to tell if you are connected via SMB1 or SMB2, the mount command lists both as just smbfs.

Update 5/6/2014

Up until recently things have been going okay. One time previously the SMB server stopped accepting new connections. It was giving a “too many users” error. According to the docs, the default was 100 max connections and I was nowhere near that. So just to be sure I manually set the max connections value to 100 in case the docs were wrong. I restarted the server and things went fine. This was about a week ago. Yesterday, same problem. SMB connections were being refused saying max connections. I tried restarting SMB but found the entire server was pretty much frozen requiring a hard reboot. After the reboot everything came back up with one exception.

The SMB server was no longer authorizing connections. It was saying incorrect password. Some digging around in log files turned up the fact that it wasn’t even contacting the Password Server to try and authenticate. I sent out an e-mail telling everybody to go back to the extremely broken AFP method of connecting, switched everybody’s home folder back to AFP from SMB so they could login and then went home. This morning I looked and there were SMB users connected. I tried myself, suddenly it was authenticating connections again. Piece of garbage.