When Mac OSX SMB Connections Fail

Earlier today I had a problem with some Macs that could not establish SMB connections to our Windows File Server. There was no quick error, so the problem really “felt” like a firewall issue but strangely I was able to make a CLI connection to the file server using smbclient:


smbclient //server/share -U domain/username
Password:*******
Domain=[DOMAIN] OS=[Windows Server x] Server=[Windows Server x]
smb: \> exit

I started thinking that perhaps the Mac was doing NETBIOS name lookups and that nmbd might be knocking on the firewall. Turns out this was the problem. Opening up the following ports on the Windows File Server did the trick:

SMB uses ports:
UDP 137 (NETBIOS Name Service)
UDP 138 (NETBIOS Datagram Service)
TCP/UDP 139 (NETBIOS Session Service)

WARNING: Only open these ports to your trusted networks. Statistical data indicates that UDP ports 135 – 139 and TCP port 137 – 139 are amongst the most commonly scanned ports on remote computers.

SMB Printing in Mac OSX

Most Mac users simply access network printers using LPR, but occasionally, you will need to interact with networks that are unfriendly to this method and find yourself having to use SMB printing. It’s a little inconvenient, but overall pretty easy to configure. I found some great instructions here. The method varies depending on which version of the operating system you have, but this site has directions for OS 10.2, 12.3, and 10.4, so it pretty much covers all the bases.

Recovering From a Corrupt NetInfo Database on OSX.4

I managed to corrupt my NetInfo database on an OS 10.4 server a few weeks ago by not cleanly unmounting the drive after booting from DVD and resetting the admin password. Long story short, this left me with no users on the system at all. With no users, I could not log in to create one, so I had to blow away the NetInfo database and restore it to factory defaults. This should only be done when you only have a small number of users, and don’t mind having to re-create them. Only the user account information is deleted, and the user directory is retained, but you will have to manually add any users you may have back into the system through the GUI, making sure that the new “user” references the old “user’s” account directory.

If you have more than just one or two users, you should use the procedure to recover from one of your NetInfo database backups. A backup of your this database is made at 3:15 every day so long as the computer is running. It is stored in “/var/backups/”, and here are some instructions on how to recover it from it. If, however, you don’t care about re-adding users, and simply want to get into your system quickly, or if you don’t have a backup to restore from, here is how you can do it:

BEWARE: THIS WILL COMPLETELY ERASE ALL USER ACCOUNT INFORMATION FROM THE SYSTEM!!! You are warned.

1) Start by booting your Mac into single user mode. To do this, hold down both the “Apple” and the “s” keys as the system boots.

2) The system will have mounted the “/” filesystem read-only to protect against data loss. To get “/” mounted read-write, we have to run two commands:

# /sbin/fsck -fy

# /sbin/mount -uw /

3) Now “/” is mounted read-write, so we can start with the real work. First, rename your existing NetInfo database to something else so the OS will not see it on the way up:

# mv /var/db/netinfo/local.nidb /var/db/netinfo/local.nidb.bad

# mv /var/db/netinfo/network.nidb /var/db/netinfo/network.nidb.bad

4) Next, remove the “.AppleSetupDone” file so the OS will kick you back into the installer upon boot and you can recreate your users.

# rm /var/db/.AppleSetupDone

5) Finally, reboot your system and recreate your users, making sure they are pointed towards their existing account directories.

# reboot

Using My New Mac Mini

My new Mac Mini came in yesterday and I just got it all up and running. I had some misgivings about allowing the system to transfer over all my applications and information from the old system, but I went ahead and did it anyhow simply because I seriously doubted I could find all the CD’s for my software. For the most part, the process went smoothly, although I had to do a little cleanup afterwards because a few applications did not work after the migration.

I was also a bit concerned about what kind of performance I would get out of the new Intel processor because many of my applications are older and were compiled on the old PPC chips. This has turned out to be a total non-issue! I got the new Mini fully loaded with a 1.83Ghz Intel Core Duo processor, 2 Gigs of RAM, and a 160 Gig SATA drive, so even the older applications that require the carbon libraries scream right along.

While I would have obviously liked to get the Mac Pro, I am very much enjoying using my new Mini, and feel that I can recommend it fully.

Macintosh Finder Copy to Samba Share Problem

With the last Samba upgrade, we started having problems copying files to our Samba share from the Mac OSX finder.When attempting the copy we received an error reading: “The operation cannot be completed because you do not have sufficient privileges for some of the items.”

There were no permissions issues, which was substantiated by our unhindered ability to do UNIX copies to the same share, and the smb.conf file had not changed. After searching the groups and finding nothing of use, I set up a test environment with all the same versions and settings, and replicated the error.

Because the Samba share is mounted over NFS on the server, and because the Mac Finder creates that annoying place holder file before actually copying the real file, I suspected that the problem had something to do with file locking. With this in mind, I systematically turned off all Samba locks one by one until I found the ones that worked.

Finder Copy Error

Finder Copy Error

IMPORTANT NOTE: The Samba share point in this environment is mounted over NFS on the server. The error did not occur when the Samba share point was on a filesystem local to the server.

Here is what our share looked like before making the changes:

[your-directive]
read only = no
preserve case = yes
short preserve case = yes
csc policy = disable
share modes = no
level2 oplocks = no

Adding either of the two following directives resolved the problem:

locking = no
posix locking = no

Either one would have worked, but we ultimately decided to turn off posix locking because we wanted Samba to continue locking files for Windows connections, but stop locking them over NFS. Below is our share after making the change:

[your-share]
read only = no
preserve case = yes
short preserve case = yes
csc policy = disable
share modes = no
posix locking = no
level2 oplocks = no

The smb.conf man page has the following to say about posix locking:

posix locking
The smbd daemon maintains an database of file locks obtained by SMB clients. The default behavior is to map this internal database to POSIX locks. This means that file locks obtained by SMB clients are consistent with those seen by POSIX compliant applications accessing the files via a non-SMB method (e.g. NFS or local file access). You should never need to disable this parameter.

Default: posix locking = yes

The smb.conf man page has the following to say about locking:

locking
This controls whether or not locking will be performed by the server in response to lock requests from the client.

If locking = no, all lock and unlock requests will appear to succeed and all lock queries will report that the file in question is available for locking.

If locking = yes, real locking will be performed by the server.

This option may be useful for read-only filesystems which may not need locking (such as CDROM drives), although setting this parameter of no is not really recommended even in this case.
Be careful about disabling locking either globally or in a specific service, as lack of locking may result in data corruption. You should never need to set this parameter.

No default

Hopefully this is helpful. If anyone has anything to add, please post a comment.