Forcing Mac OS X Mavericks Server to SMB1 only connections

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/ 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:


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.

5 comments for “Forcing Mac OS X Mavericks Server to SMB1 only connections

  1. larry
    May 3, 2014 at 9:56 pm


    I was just curious if all that worked out for you. I upgraded to Maverick’s at one point from Snow leopard, but my mac is primarily a server now as I have an external firewire drive attached that contains all my movies. I then share that drive and my home theater PC in the living room streams the movies that way. Ever since the Maverick’s update though, the smb stuff was messed up. So I guess if it worked for you, I may give it another try.

  2. May 3, 2014 at 10:06 pm


    It has “worked” in that it didn’t break anything per-se. I have discovered that there are a few applications that are having trouble with permissions. I cannot say if it is an SMB issue in general, or because I am now running SMB1. Quicken Essentials is one such application. It will give an error about not being able to open the data file read/write or something. If I duplicate the file(bundle), from the client, and then open the duplicate everything is fine. If I then pull up the server and examine the ACL permissions for both files, they are identical. For these issues I can’t figure out if it is an issue with the application itself not liking SMB or something else Apple broke in SMB. At this point there are so many bandaids in place it is hard to tell what is actually bleeding, so to speak.

    Overall, it is working at-least enough to keep my staff functional, though I couldn’t say if they are happy with all the quirks we have had in the past few months related to the file server. If 10.9.3 continues to improve the situation I will try to stick it out until they get everything fully resolved. If not I may look at switching to a Linux server as the file server, but that means switching back to AFP(1) or maybe just switching all the way over to something like a QNAP NAS unit(2). I’m not keen on going back to AFP since Apple has stated they are killing that protocol.

    Notes 1&2: The reason I would have to go back to AFP is because my authentication database is in Open Directory. And the Mac OS X LDAP service, for whatever reason, does not have the correct schema to allow SMB authentication. Don’t ask me how they do it themselves. There are patches that can be applied to the schema to make it work, but if I am going to go that direction I would rather kill OD all together and go to a generic LDAP. The only thing keeping me from doing that right now is MCX (Managed Preferences). We are behind the curve so I haven’t yet migrated to Profiles instead, though I am slowly working through that now.

  3. Peter Trondsen
    August 22, 2014 at 6:56 am

    I’ve been having some issues with SMB all of suddenly, and I think when I upgraded to 10.9.4, it killed this little trick of forcing SMB1 connections. I find stopping and starting the service has helped. My issue is that I have Window’s users connecting, and don’t have a choice of AFP for them. I still use AFP for the Mac users, and it’s been stable. However, Mavericks Server has been far from stable, although 10.9.4 has been better. Hopefully 10.9.5 can bring a level of stability.

  4. James
    October 3, 2014 at 1:04 am

    I had an OS X 10.9.5 server that absolutely refused to authenticate OpenDirectory users from Windows or Mac clients over SMB until I implemented this little trick! Thank you!!

  5. Bill
    June 10, 2015 at 9:33 am

    I found a solution to enable and require smb signing on OS X Yosemite with Server 4.1 :

    I edited the /Library/Preferences/SystemConfiguration/

    I had to use TextWrangler (free download at )

    Add this to the file:



    Restart the machine.

    Hope this is helpful.

Leave a Reply

Your email address will not be published. Required fields are marked *