10.7.4 has killed my SMB Shares

Try this.

First duplicate the plist file for the SMB service so you have a backup:

• cd /Library/Preferences/SystemConfiguration
• cp -vp com.apple.smb.server.plist com.apple.smb.server.plist.bak

Next stop SMB:

sudo serveradmin stop smb

Next edit the plist file to use your server's Kerberose realm instead of the LKDC. Example:

<key>LocalKerberoseRealm</key>

<string>YOUR.REALMNAME.net</string>

Now save the plist and restart SMB:

sudo serveradmin start smb

This restored my SMB service after it started failing to authenticate users.

cam85:

Did you happen to notice any smb crashes when you were experiencing this issue?

If you're seeing this issue can you verify whether running the following will fix the problem?

sudo touch "/Library/Preferences/SystemConfiguration/com.apple.smb.server.plist"

Yes, that works. For some reason sudo serveradmin stop smb gives me an error, but the "sudo touch" works. I like this method better because it will not start up samba sharing if it was nto running already.

I can confirm this solution as well. Every few weeks the smb service simply stops responding to client connections in what resembles a failed authintication attempt. (Windows machines state you have entered the wrong username and password and OS X clients' authentication dialogue box shakes back and forth)

Using the nerminal command:

serveradmin fullstatus smb

results in the status="RUNNING"

Attempting to restart the service or stop, start the service yeilds the error:

samba:error = "CANNOT_LOAD_BUNDLE_ERR"

The solution for me was to stop the smb service using:

serveradmin stop smb

And removing the smb option from every share in Server.app that uses smb. Waiting 1 minute, and then starting the service using:

serveradmin start smb

and re-enabling my shares in Server.app

What a pain. I wish I knew what caused the service to stop responding in the first place. I was unable to find anything in the logs.

Solution confirmed once again. Stopped the SMB service, removed SMB from individual shares, started SMB service, then added the option back to the individual shares. I was testing primarily from a Windows 7 client where the local Windows login does not match the Open Directory login being used to access the SMB share on my Lion server.

Once I knew I had some working SMB shares, I tested some different username formats, since I originally suspected that I was using the wrong format:

These formats did not work:

OD_DOMAIN\ODUsername

OD_HOSTNAME\ODUsername

ODUsername@OD_DOMAIN

ODUsername@OD_IPADDRESS

ODUsername@OD_HOSTNAME

The only formats that worked for me were:

OD_IPADDRESS\ODUsername

ODUsername

I find it strange that plain old ODUsername works, as this should pass the local machine name by default, thus my input would be changed to LOCALHOSTNAME\ODUsername. My Windows hostname does not match up with OD, so this shouldn't technically work...

As a control in my testing, I did not change the SMB sharing option from some of my shares, then tested these after the smb restart. Directories where I toggled the status off and back on again were working, while these "control" directories produce the following error when access is attempted (I tested from a Win7 machine). This error is produced before the authentication dialogue is presented:

\\IPADDRESS\Share

A device attached to the system is not functioning.

However, I when I applied this fix to all directories, this error is gone. I just found it strange that it was not revealed until I restarted the SMB service.

I'll have to test further to find out whether this issue is resolved permanently, or if it will come back at some point.

Quick update: This error is not a symptom of the SMB issue by the OP:

Jsledge27 wrote:

\\IPADDRESS\Share

A device attached to the system is not functioning.

I found that I received the error after connecting to one share at \\IPADDRESS\Share1 as UserX, then attempting to connect to another share at the same address \\IPADDRESS\Share2, where UserX does not have permissions to access Share2. Windows systems cache the credentials to \\IPADDRESS and do not prompt a second time when connecting to \\IPADDRESS\Share2, thus the error.

Jonathan's solution resolved an issue with my Mavericks server. After a reboot it stopped authenticating users for SMB access.

I think I'm going back to linux for servers or a good NAS product. Too many OS X Server issues and you can't update the server without updating the entire OS.

Thanks!