We have been troubleshooting several reports from offices with bound OS X servers where Mac and PC clients are unable to connect to shares using AFP or SMB. Additionally these offices have reported that Macs will randomly drop their AFP connections to the OS X server.
When the connection problem occurs often times the server shares will display generic ACL GUIDs: a series of numbers and letters instead of the group name. In cases such as these restarting Directory Services generally resolves the problem- at least temporarily:
sudo /usr/bin/killall DirectoryService
Other times the GUIDs display normally but the connection problems still persist. In these cases two things are suggested:
Nest AD users into local groups and then use the local groups to populate the ACLs
Flush the group membership cache by running this command:
sudo dsmemberutil flushcache
Generally these problems occur most often on Leopard servers- Snow Leopard servers have improved group membership caching.
Problem: A 10.5.8 server was not allowing SMB or AFP connections. The server was bound to AD but "id" commands were failing- sometimes.
Looking at the logs I saw that they were filled with launchd errors:
com.apple.launchd[1] (org.openldap.slapd): Throttling respawn: Will start in 10
These were causing very, very poor performance and pretty much preventing Directory Service from operating; that in turn prevented any logins.
The first thing I attempted was to unbind the server but as it couldn't connect to the domain I did a Force Unbind, deleted the edu.mit.kerberos file and the Directory Services folder and restarted. I then re-bound the server and immediately unbound: this ensured that the server's AD account would be removed.
From the unbound server I took these actions:
Changed the Windows role to Standalone server
Stopped the SMB services
Opened Terminal and ran "sudo –s /usr/libexec/slapd –Tt"
This returned:
could not stat config file "/etc/openldap/slapd.conf": No such file or directory (2)
slaptest: bad configuration file!
I then viewed the contents of the directory: cd /etc/openldap/ls
There was no slapd.conf file present but there was a slapd.conf.default file so I renamed it: "cp slapd.conf.default slapd.conf"
I then re-ran the slapd command: "/usr/libexec/slapd –Tt" and it returned:
bdb_db_open: Warning - No DB_CONFIG file found in directory /private/var/db/openldap/openldap-data: (2)
Expect poor performance for suffix dc=my-domain,dc=com.
config file testing succeeded
Since LDAPv3 is turned off in Directory Services this shouldn't be a problem
Snow Leopard client copying file to SMB will get a –50 unkown error and the copying will halt. This only happens to Snow Leopard and only to SMB. Copying the same files to AFP works fine. It is also only on certain files. We can take this file to another Snow Leopard machine and reproduce it every time.
Cause
We found out that it has to do with files with resource fork. I think Snow Leopard and Leopard no longer embed resource fork into files anymore. But I am guessing these files were touched or created by older Apple OS. This explains why out of thousands of files, we only see some files with this problem. This is due to the fact that the Snow Leopard Client now defaults to using NTFS Streams rather than AppleDouble files (dot underscore files) to store the resource fork.
Solution
Turn off NTFS Streams support in Snow Leopard. You can do this on the client by running this command.
echo "[default]" | sudo tee -a /etc/nsmb.conf
echo "streams=no" | sudo tee -a /etc/nsmb.conf
Of course this would be a pain if you have to touch every clients. An easier way is to touch the share by creating a file at the root of the share called ".com.apple.smb.streams.off". As this is a hidden file, it is probably best to do this from the command line.
cd /Volumes/sharename/
touch .com.apple.smb.streams.off
No reboot is needed. Client just need to dismount and mount the share again.
Problem: AD bound 10.6.x Macs were experiencing problems connecting to SMB shares on Windows servers. Users could not connect to the shares, or it would take several minutes to open/browse folders.
Cause: It was found that the issue happens when there is a folder or file on the share for which the security list includes an “Unknown SID”. When listing the content of the share, the OS X Directory Service plugin attempts to resolve all SIDs to AD objects. In this case, the plugin encounters a “Unknown SID” and expends 60 seconds attempting to resolve the SID. Once 60-second timeout is reached, the plugin skips the entry and will list the share contents. Now, if there are multiple files or folders of “Unknown SIDs”, the time for listing the content will multiply base on how many of these “Unknown SIDs” on there thus explaining the different delay time users are experiencing.
Resolution:
Test indicates that once these “Unknown SIDs” are removed from the affected file/folder, the speed of SMB will return to normal. The mount and content listing of the share will take seconds instead of minutes.
Apple will take the finding back to their product engineering to determine how they might be able to mitigate the timeout issue from OS X.
The problem of resolving this issue for server administrators is that it is not practical to identify these “Unknown SIDs” and remove them manually. After some research, it seems that Microsoft has a tool to do this.
SUBINACL - Display or modify Access Control Entries (ACEs) for file and folder Permissions, Ownership and Domain.
Download the MSI and install it to your file server. You can then run it using the following syntax. It will removed all the “Unknown SIDs” from the files and folders you specify.
This will clean out all “Unknown SIDs” from the path you specify and all the directories below that. You can also use a /TESTMODE switch to test it out. It will run the command and show you the result without actually modifying anything. It is recommended that you run it under testmode once.
Bound 10.6 machines require that all users attempting to log in with AD credentials have either a correct path to an accessible home folder or have “force local home folder” ticked in Directory Utility.
Here are some things to try:
Look at the user’s account and see if they have home folders listed. If they do, make sure they are valid and remove them if they are not. You might simply want to remove them full stop- this has resolved problems like this in the past. Something else to keep in mind: Snow Leopard has horrible problems connecting to SMB shares so if a user has a SMB home folder defined in their AD account it could simply failing to connect and halting the login process.
