Mac OS X Server Cross-platform Issues

Information and links related to using Mac OS X Server with Windows clients and servers

Last updated December 19, 2007

On this page:

Have you found a Mac OS X Server problem with Windows clients or Windows networks? Have you found a new solution? Let us know.



Mac OS X Server actually started shipping before Mac OS X did. It includes SMB file and printer sharing and WINS support for Windows clients, as did the AppleShare IP server before it. Mac OS X Server comes bundled with Apple's XServer hardware and is available as a separate software product.

Version History (recent)

Mac OS X Server 10.2.4 fixes some cross-platform issues. February 26, 2003 -- Apple released Mac OS X Server 10.2.4, which has a number of bug fixes and improvements, including fixes for AFP, SMB and NFS file services, and Open Directory, as well as cross-platform problems with Microsoft Word. Some of the improvements in the upgrade (which requires Mac OS X Server 10.2.3) include the following cross-platform issues:

If you find this upgrade to the Server software solves any of the cross-platform problems listed on our Mac OS X Server Reports page, please let us know.

Security Update 2002-08-02. August 5, 2002 -- Security Update 2002-08-02 works for Mac OS X client as well as Mac OS X Server. Apple describes the update:

Security Update 2002-08-02 includes the following updated components which provide increased security to prevent unauthorized access to applications, servers, and the operating system. Apache v1.3.26 OpenSSH v3.4p1 OpenSSL v0.9.6e SunRPC mod_ssl v2.8.10

Mac OS X Server 10.1.4 update improves mail services. April 17, 2002 -- Apple has posted Mac OS Server 10.1.4, an upgrade to the server for Macintosh and Windows clients. Apple lists two improvements to the mail services:

Mac OS X Server 10.1.1 update improves SMB printer sharing, WINS registration. November 21, 2001 -- Apple has posted a Mac OS X Server v10.1.1 update, which improves services for Windows clients, among other improvements. From the Apple readme file:

This update delivers improved improved reliability and performance of Apple file services, Apache web and Mail services under heavy load. Enhancements have also been made to improve server administration, SMB printer sharing, WINS registration and system clock accuracy.

MacWindows Reader Reports

Tips for accessing Mac OS X Server from Windows 2k client

October 26, 2001
Adam Glick of HelpDesk

I just spent the better part of the afternoon trying to get a Windows 2000 client to connect to a fresh OS X Server 10.1 install and wanted to pass on these observations and maybe save others some headaches:

1. Apple's got a few wrinkles to work out in the SMB/Samba setup.

2. Many people are having a less than smooth time getting it to work (checkout the OS X Server discussions at Apple)

3. Server MUST have static IP and be in same subnet as Win clients

4. Server MUST have fully qualified DNS record

5. Server will show up fine in existing network neighborhood with existing WINS server if you tell it to register itself with WINS

6. Unless you enable the Authentication Manager you will never, EVER be able to get your Windows clients to log in (enables correctly passing encrypted passwords)

7. Make sure you reset the user's passwords after you enable Authentication Manager.

Other than that, performance of 10.1 on a G4-350 was impressive. Gave it lots of RAM (768) and a hardware RAID 5.

Top of page

Win 2000 clients making files that other users can't modify

Here we have a problem where noone can modify a file created by a Windows client. Several fixe are described.

October 26, 2001
Adam Glick

A gotcha: when a Windows 2000 client copies a file/folder to a share point, or modifies an existing file, ownership of the file or folder is switched to THAT user, not even the administrator can do anything to it. You have to manually reassign permissions back to the correct owner at the server. Someone in the discussion groups came up with a workaround for this by editing the samba .cnf file but restarting loses the changes.

August 5, 2002 -- A pair of readers (Kevin Pedersen and Dave Pooser) note that Apple Knowledge Base article 106570 solves this problem.

Kevin Pedersen also finds that Mac OS X 10.1.3 has a positive effect:

I've found that since upgrading to OS X 10.1.3 the smb.conf file can be left unlocked (sudo chflags nouchg /etc/smb.conf) and Server Admin won't muck with it anymore.

Dave Pooser also added this tip:

Here's a way to map other names to the user shortname so you can still log into Windows as "John Doe" instead of "johndoe" but authenticate to the server. The explanation:

1) Go to /etc/smb.conf and add the line

username map = /Library/Samba/

In the [global] setting. If you're like most of us, you've already locked that file in fixing the group-witeable bug; if not, you'll need to lock the file or it will get gorked every time you use the Server Admin WindowsServices fix (see Kbase article 106570 for details).

2) Then, in /Library/Samba/ create a file using your text editor of choice. The format is

shortname = "Windows Username"


bsmith = "Bob Smith"

Also note that you can map one shortname to multiple long names. When you're done, lock the file per the instructions in Kbase article 106570. You will lose the ability to configure Windows service settings from Server Admin, but you'll lose that when you address the group-writeable bug anyway.

Top of page

Mac OS X Server as a Primary Domain Controller for a Windows Domain

April 3, 2002 -- The web site has an article describing how to set up OS X Server as a Primary Domain Controller for a Windows Domain. Joel Rennich describes the article:

It's a fairly easy procedure for anyone that isn't too afraid of the command line. The same essential procedure could also be done with a machine running OS X Client and Samba.

Top of page

Authentication problem with Windows clients; Win clients can't log on

We first have reports of the problem, followed by some suggestions.The most notable suggestion--using the "short name"-- is described in Apple Knowledge Base article 106561.

July 12, 2002
Bastiaan de Beer

The clients are Wintel PCs with NT4, Service Pack 6 and W2000, Service Pack 2. The server is a Mac OS X 10.1.5 server with the latest updates installed, and I have a test server with the same configuration.

When I try to connect the Windows clients, I can see the server in the same workgroup - there is no NT domain on our network. When I want to log on (as one of the users or administrators) the logon gets denied with the following dialog box:

Enter Network Password
Incorrect password or unknown username for: \\servername
Connect As: [ fill out ]
Password: [ fill out ]

After this incident I find in the log file on the OS X server these lines:

[2002/07/10 11:11:30, 1]


User "(username)" failed to authenticate with "dsAuthMethodStandard:dsAuthSMBLMKey" (-14091)

[2002/07/10 11:11:30, 1]


Rejecting user '(username)': authentication failed

On my test server there are no problems doing the log on.

July 18, 2002
Reuben Herfindahl verified our July 12 report by saying he also had the same authentication problem with Windows clients and a Mac OS X Server. Another reader named Mark offer this "You need an NT domain on a PDC for everything to work OK."

July 31, 2002
Todd Carson

We've encountered the same problem with Windows users authenticating to an OS X server that was mentioned in your news on July 12th. The problem suddenly appeared this morning; previously, Windows users could log in and mount shares normally, and I don't remember anything that was done to the server that could have caused this. Interestingly, before this we'd been plagued by an error 5015 in Server Admin whenever we tried to create new users or change passwords. That problem has disappeared, but now Windows users aren't being authenticated.

With regards to the update on this story posted on July 18th, which mentions NT domains, we do have an NT domain on a PDC, and the problem still occurs. Could the reader who contributed that, or anyone else, clarify what exactly needs to be done? Does the OS X Server need to somehow be made a member of the domain? Do all the Windows machines need to be members of the same domain?

Problem seen with OS X Server 10.3.7

December 21, 2004
Steve Maser

I run an OS X Server (10.3.7) to host files for my Mac and Windows clients. There are no "home directories" on the server. It's strictly a file repository.

Recently (like in the past month), some -- but nowhere near a significant minority -- of my Windows clients have been able to *authenticate* to my server (the standard login/password prompt), they see the share points, but when they go to open a share point that the login allows, they are getting an "Access Is Denied" message and can't open the share point.

I'm not seeing any commonality on the Windows computers that can not do this. It seems like it affects Win 2000 machines more than XP machines, but I have some XP machines showing this.

The oddity is -- on one affected Win 2000 machine I have to play with here, if I create a new account on the machine that is an "administrator" account -- I can not access the share point. If I change it to a "standard user" account (same account name/password on the 2000 machine, but different than the login/password on the server), then I can open the share point! Which makes no sense at all.

Suggested solutions

August 1, 2002
Craig Moritz

I called Apple tech support and received an answer regarding OS X Server 10.1.3 and Win 2000/XP clients not working: It applies to all Windows machines but 2000/XP was my last hurdle this week. I broke down and called Apple support. The solution for Win XP/2000 connecting appears to be to make sure the Owner of the folder is a member of the Group that accesses the folder also. I made the Win 2000 user the Owner of a test folder with all other other options off and was able to get in. I then went back and made the Win 2000 user the Owner of the folders that he needed to get into as a member of the Groups. No more problems.

So after three days of getting OS X Server 10.1 to work with OS 9, OS X, Win 98, Win ME and now Win 2000/XP, here are my suggestions:

1: Insure that "Encrypt Windows Passwords with Authentication Manager" is selected when installing or after the fact as stated previously.

2. Make everyone changes their login to the 8 letter "short names" that are setup under the Users and Groups.

3. Double check the Permissions on the shared folders by using Get Info on the hard drive shared folders. They should be the same as set through the share points. Change manually if not correct.

4. Insure that the folder Owner and access Group in Privileges contain the same person as noted above. If that does not work, make the Win 2000/XP user the Owner of the folder. This does not appear to affect any other OS's just NT based.

August 2, 2002
John Schumacher

I have seen the same log entries as are quoted in July 12 posting. We have had this problem on some but not all of our Windows clients. Our problems ceased after creating user accounts on the local (offending) Windows clients with the same username and password as the Mac OS X server account. Our impression was that for whatever reason the username and password that were used to access the Windows client workstation were being sent to the Mac OS X server.

August 2, 2002
Eric Likness

I concur with John Schumacher's thought that the Windows client is sending username and password over the network as soon as you try to connect to the volume from Windows. This is what I've seen 'exactly' on AppleShare IP 6.X every since it first started shipping. It was only by accident that I discovered that the Win98/95 Microsoft Networking login (which we never used since we had no NT Domain or NT servers to connect to) is the key to connecting to AppleShare IP over SMB. Once I synchronized the Microsoft Networking login with the AppleShare IP login, I would merely double-click to connect to the Drive after mapping it to a free drive letter on Win95/Win98. My guess is this mechanism is still the one being used under the Samba based SMB infrastructure within OS X server.

August 26, 2002
Kyung Eigenraam

When you have a Windows NT4 Server acting as a PDC (in my case I have a Windows NT4 Small Business Server which is by default a PDC !) AND a Mac OS X Server AND problems with Windows clients, you'll have to boot the MacOS X Server BEFORE booting the Windows server.

It seems that when the NT Server was booted first, the Windows clients don't authenticate any longer with the Mac OS X Server. I repeated this situation a few times in reverse orders (Mac first, Windows second/Windows first, Mac second). This problem does not occur with a Windows NT/2000 server which is not a PDC.

Apple's solution

August 8, 2002 -- John Engelke sent Apple's answer: the Windows client must log in with a User name that matches the user Short Name as defined in Mac OS X Server. Engelke writes:

The problem where users can not log in using SMB is documented in an Apple Knowledge Base article 106561. The cryptic error message "dsAuthMethodStandard:dsAuthSMBLMKey" means the full user name is incorrectly being used. Apple specifically instructs users to only use the user's "short name" when logging in from a Windows client. For instance, if the name is "Turkey Foo" and the short name is "turkeyfo" then only "turkeyfo" may be used. The article does not specifically mention this error but takes care of it.

August 9, 2002
Scott Boone

This is a "known" issue with Samba--well, that isn't the right word. Samba under OS X uses the user name to authenticate, which, because Apple is a big weenie, is limited to 8 characters. The Samba project hasn't yet "fixed" this, well, I guess because it probably isn't much of a problem as far as they are concerned.

As for Apple and its users, by implementing another Samba feature, the username map, this can be worked around (and I'm surprised that Apple didn't do it). Basically, you can add a

Username map = "/path/to/text/file/"

Line in your config that allows you to map short user names to longer or other ones. The format of that text file is:

userjoe = joe "Joe Public" publicstuff

scott = scott scottb "Scott Boone" Windows

As you can surmise, the third entry (public stuff) is like an alias. Of course, doing this on Server would be VERY time consuming. We can only hope Apple sees the light and changes things for Jaguar (probably not).

August 21, 2002 -- Apple's Mac OS X 10.2 Server web pages are saying that the Jaguar-based server no longer limits Windows users to 8-character user names and updates Samba. (An August 9 reader report noted that Mac OS X Server 10.1 limited Windows/SMB user names to 8 characters.) Eric Zelenka reports:

I'm happy to say that Mac OS X Server v10.2 provides support for user short names up to 255 bytes (for Unicode) in length. In addition Mac OS X Server now supports multiple short names for each user record.

Top of page

General suggestion for Win clients not connecting to OS X Server.

August 5, 2002
Tim McManus

Here's a simple trick that should do the trick. I lost power this evening and was updating OS X Server this past week. Every time I restarted the machine, Windows machine could not connect. This solved the problem:

In the server Admin software, stop and restart Windows services. It should work like a charm. I haven't tried to figure out what is causing the problem, but just doing that seems to fix the problem. Works for me. I am running a WORKGROUP and the machine is the primary WINS machine for the WORKGROUP.

Top of page

TIP: for Win clients logging into OS X Server, the username map. Fixed in 10.2

August 9, 2002 -- Scott Boone has another suggestion for Apple solution to the problem of Windows clients logging onto OS X Server:

This is a "known" issue with Samba--well, that isn't the right word. Samba under OS X uses the user name to authenticate, which, because Apple is a big weenie, is limited to 8 characters. The Samba project hasn't yet "fixed" this, well, I guess because it probably isn't much of a problem as far as they are concerned.

As for Apple and its users, by implementing another Samba feature, the username map, this can be worked around (and I'm surprised that Apple didn't do it). Basically, you can add a

Username map = "/path/to/text/file/"

Line in your config that allows you to map short user names to longer or other ones. The format of that text file is:

userjoe = joe "Joe Public" publicstuff

scott = scott scottb "Scott Boone" Windows

As you can surmise, the third entry (public stuff) is like an alias. Of course, doing this on Server would be VERY time consuming. I can only hope Apple sees the light and changes things for Jaguar.

August 21, 2002 -- Apple's Mac OS X 10.2 Server web pages are saying that the Jaguar-based server no longer limits Windows users to 8-character user names and updates Samba. (An August 9 reader report noted that Mac OS X Server 10.1 limited Windows/SMB user names to 8 characters.) Eric Zelenka reports:

I'm happy to say that Mac OS X Server v10.2 provides support for user short names up to 255 bytes (for Unicode) in length. In addition Mac OS X Server now supports multiple short names for each user record.

August 21, 2002 -- Scott Boone also points out Apple's statement that OS X v10.2 Server also has Samba using OpenLDAP:

Wanted to pass along a note that from reading the 10.2 Server pages on Apple's site, I am thinking that Apple has "fixed" the 8 character username issue, as well as dealt with the Samba problem.

This is only preliminary, as I haven't used Jag or its Server, but the Apple docs state that they have integrated Samba authentication for the OpenDirectory server (in other words, they have compiled Samba to utilize OpenLDAP). I also noticed a field in the Workgroup Manager software that appears to allow you to create a list of "short names" for each user.

Now if they just worked on getting name mangling to work a little better (since HFS+ uses a funky encoding, some "special" symbols don't appear very aesthetically in Windows) things would be perfect!

Windows client Error 50203 problem with Jaguar Server.

October 28, 2002
Kimmo Gläborg reports a new problem with Windows clients accessing Mac OS X 10.2 Server, as well as the fix:

After upgrading my 10.1.5 server to 10.2.1 I couldn't get my Windows 2000 clients to connect to SMB shares on the server. When trying connecting from 10.x clients over SMB I just got this error mess:

"An error has occurred (error = 5023)"

Just spoke with an Apple Support representative and he confirmed my SMB problems in 10.2.1 Server is not unusual.

The thing is that the client setting on the logged on user in Mac OS X 10.2.1 server is overriding settings done even in Workgroup Manager.

Go to System Preferences locally on the server. Under System ->Accounts check box in the user setting option to "Allow user to log in from Windows". If this little box is unchecked, that setting override all other server settings regarding Services for Windows.

Apple also recommends to uncheck "guest access" under Server Settings-> File & Print -> Windows.

These fixes resolved my problems.

October 30, 2002
Ethan Lowry of Apple says this is not quite true:

This is not the whole story. The problem they are encountering is an authentication problem. Their Windows users are not able to authenticate because the password server is probably not running on the server (See page 88 of the Server Admin Guide for more info). By selecting the "Allow user to log in from Windows" in System Preferences, they are actually creating a hashed password for the user in a shadow file. All users that use the password server should be able to connect.

Ethan Lowry
AppleCare Engineering

October 30, 2002
Steve Maser comments on the same suggestion:

The problem with this is that (from what I see here locally), not all the accounts on the server show up in "Accounts". I've never been able to see them all there.

And, yes, my "allow user to log in from Windows" boxes are all unchecked for all my server users, too.

The 5023 error is something that definatly happens on OSX *client* if you don't toggle this box.

But I've never seen this happen on OSX Server.

October 30, 2002
Shawn Brisbay

I also had problems getting my Win machines to log on to the Jag Server. What I finally had to do was turn on password server and create my users in NetInfo/root not NetInfo/local. I had previously created all of my users in /local but with 10.2 that is no longer a possibility. After creating shares matched with the /root users they all log in fine.

A fix with Apple's help

November 11, 2002
Kevin Poole

I thought I'd pass along exactly what one major problem is with Windows clients not being able to log into Mac OS X Server 10.2: Windows users *must* have accounts on the server that are set to use the Password Server option (accessible in the Advanced tab of Workgroup Manager). The problem is, the Password Server in 10.2 will not run unless DNS Service is running on the 10.2 server. Configuring DNS is typically a very complex process, especially for people expecting out-of-the-box Windows compatibility (like me).

Fortunately, the Apple Server tech I finally reached went above and beyond in helping me resolve the problem. He directed me to a app he wrote himself, which is a simple GUI tool for setting up local DNS service. It eliminates the need to manually edit the DNS configuration files, which can be very tricky (trust me, I tried it). And it worked for me on two servers like a charm. Once DNS is running, you may have to use the Open Directory Assistant to make sure the Password Server is properly set up and running. Then you'll have to manually set each Windows user account to use the Password Server and you'll add the new DNS info to your Network settings in System

Preferences on the server. There are a few other details to be aware of, but I think any Apple Server tech group can probably walk people through all of them at this point. If you get someone who's not aware of the solution, ask to be handed over to someone who does.

In any case, I was finally able to get my 10.2 Server to work properly with Windows clients, and I'm happy to know that Apple's techs are working to resolve it.

As this is an issue that's of utmost importance to Network Admins everywhere with 10.2 Server, I'd suggest that everyone try to disseminate the information throughout the Mac community, at least until Apple updates its Knowledge Base with the necessary instructions.

Win clients connecting to OS X Server 10.2.1 using Active Directory

(NOTE: for a discussion of Mac OS X clients integration into Active Directory, see the MacWindows Active Directory Reports page.)

November 18, 2002
Eric Benfer

I am so close to nirvana. I have setup Directory Access to pull the users and groups from our Active Directory domain into my OS X Server 10.2.1. All the users from the AD show up in Workgroup Manager. I can assign AD users to local groups. OS X Mac users can get into the server using their Active Directory user name and password. I am so close to it all coming together. (I followed Chuck Simciak instructions to get this far.

The problem is when Windows clients try to connect Using their AD user they cannot authenticate. If I enable the password server for a local NetInfo user a windows PC can connect with that user. However I cannot / have not been able to figure out how to enable the password server for the Active Directory users in Workgroup Manager. Mac OS 9 users also cannot connect using their AD user and password.

To sum up...

Active Directory Users and Groups show up in WorkGroup Manager. Mac OS X 10.2.1 users can connect to the OS X Server 10.2.1 via their AD user. Neither Windows nor Mac OS 9 clients can connect via their AD user. Windows clients can connect using a local user with the password server enabled.

November 19, 2002
Michael Bartosh

You can get this to work by doing pass-through authentication in samba (configured in smb.conf... security = Domain) to the Active Directory.

This isn't the most secure process in the world, but it does work, as long as the Mac OS X Server is able to look up the user in the AD.

November 19, 2002
Christopher Thon

We've had some experience with this too. We've posted our method at the JAMF Software web site. Our experience was somewhat different than what I've seen posted elsewhere in that some of the implementation environments required the users' server-based home directory to be a mount point (that is, /not/ a subfolder viewable by all on a mounted server) because of FERPA laws affecting disclosure in educational environments.

March 21, 2003
Christian Raymond can get Mac LDAPv3 authentication with Microsoft Active Directory through a Mac OS X Server, but not for Windows clients:

We have a AD domain with a few Mac clients. We try to use OS X server as a file server for both win and Mac clients, having them connecting with their AD username/password. here is what we have so far.

We use OS X server 10.2.4. After the initial setup, I ran Directory Access, and configure LDAPv3 with the standard Active Directory mappings, and edit the config to connect using a valid DN. to get the DN, I used ADSI edit on my windows server (available on the Server CD, in the support folder). My DN looked something like this :


But, this is different for each AD schema. I then added the LDAPv3 to the authentication search path, on the main window of the Directory Access app. Now when I launched the Workgroup Manager, I selected the LDAPv3 in the At: popup, and unlocked it, and there it was, all my AD users and groups.

So now Macintosh clients can connect using AD username/password. But not the Windows clients. After reading a few comments, I launched Open Directory assistant to start the Password server. This got the Windows clients connecting with OS X server's username and password. But I still can't connect the Windows boxes with AD accounts. I could re-created users in the Netinfo database, but I don't want to do it for 200 or so users.

March 24, 2003
Carib Mendez

I had the same problem. I then tried joining my Mac to the Domain via smbpasswd (smbpasswd -j Domain -r PDC) and setting up domain security for the SMB stuff. This allowed my Windows clients to connect to the server using domain password information. More info can be found in the O'Reilly book Using Samba on all Mac OS X clients.

March 2, 2005
Chris Jasper has another suggestion for Windows XP clients on Mac OS X with Active Directory:

We had a lot of problems with logins and domain membership with SP1 before we installed Active Directory so we spent a lot of time looking for fixes for "missing" AD domain.

Try this: On the XP box go to the Run command and type gpedit.msc, open up Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options and set the policy called "Domain Member: Digitally encrypt or sign secure channel data (always)" to disabled.

This should remove any requirements for membership of a Windows 2000/2003 AD and allow the XP boxes to connect to the Mac Servers.

Win machines crash when Macs open Word X on OS X Server

February 19, 2003
Per Thörnblad reports a problem with Mac OS X Server where Windows clients can crash when sharing a Word X file with Mac users:

We have a Mac OS X Server 10.2 and mixed clients, Mac OS X 10.2.3, Win2K and Windows 98 SE. On the Mac OS-machines we use Microsoft Word X ,10.1.3, and on the Wintel machines we use Word 2000. If one of the Mac-users opens a Word document from the server and then one of the Wintel-users tries to open the same document, Word 2000 on the Wintel-machine crashes after a delay of some 30-60 sec.

If the same operation is done by two Wintel users the number two user gets a message that the document is already opened by user xx and that the document will be opened in write protected mode, then the document opens OK.

February 25, 2003
Andrea Mariottini has a theory:

As I mentioned in the past it seems Mac OS X doesn't have the same mechanism of file locking for AFP and SMB, so a file locked by an AFP session is free for a SMB session and vice-versa. This could cause problems.

Our above report on Mac OS X Server 10.2.4 makes reference to improving abilities with Word files, which might indicate that this problem is fixed. If you can verify this, please let us know.

Mac OS X Server SMB file copy yields files with strange names

March 7, 2003 -- Apple Knowledge Base article 107325 describes a problem with Mac OS X Server and SMB file copies that results in the the resource fork getting split out. The article describes the symptoms, as did a reader:

I recently came across a weird problem moving files from a Win 2000 Server SP3 to a Mac OS X Server 10.2.4 on Xserve. I have a Win 2000 Server SP3 as a file server. When I log in to an XP or OS9/OSX box, I proceed to move files from the 2000 server to my new OS X server and it creates multiple files of the original.

Let's say I have a TIF file named "dinner with.tif." Two more files will appear after I transfer the original "dinner with.tif" file. One is called "DINNE~JA" and the other one as "DINNE~TJ" (this is looking at it on network neighborhood from a PC)

Looking at the transferred files sitting inside the Mac File Server (Mac OS X) I get the following file names:

dinner with.tif
dinner with.tif/AFP_Afpinfo/$DATA
dinner with.tif/AFP_Afpresource/$DATA

Weird thing is...when I move files from my WIN XP Pro machine to the OS X File Server I don't get multiple files.

Win XP Service Pack 2 can't connect to Mac OS X and ASIP

Readers have verified that this problem is caused by security update 885250, which SP2 automatically downloads.

A reader also offered an alternative to deinstalling the update.

Reports of the problem

October 29, 2004
Paul Vail

Wondering what you have discovered about Windows XP Pro SP2 clients having trouble logging into existing accounts on Mac OS X Server 10.2.8? I've a customer that had two Dell boxes working beautifully with XP Pro SP1 that now cannot get to the server (no changes there) after the update.

Disabling the Firewall completely doesn't seem to restore functionality. They both get either network path doesn't exist or authentication failed errors.

November 1, 2004
Artur Kruus

We're also having trouble logging into existing accounts on Mac OS X Server 10.2.8 with Win XP SP2. I've a customer that had two Dell boxes working beautifully with XP Pro SP1 that now cannot get to the server (no changes there) after the update.

Disabling the Firewall completely doesn't seem to restore functionality. They both get either network path doesn't exist or authentication failed errors.

February 22, 2005
Nicholas Eley

We have a number of clients who use Windows XP PCs to connect to Apple servers (a mixture of the old Mac OS 9 AppleShare 6.3.3 and the new Mac OS X 10.2.8/10.3 servers). Since SP2 has been installed on the PCs we've started to notice that one-by-one, the PCs can no longer connect to the file servers. The server is visible on the network but the PCs cannot connect to any of the share points.

February 22, 2005
Theresa Ewing

I just upgraded my win machines with Service Pack 2 and now have the problem connecting into the our Apple network. I was wondering if there was a correction work around?

February 24, 2005
Terry Ammons sees the problem with Mac OS X 10.2.8 Server:

I'm running OS X Server 10.2.8 on an Xserve. The Windows machines were running XP with service pack 1. The upgrade to Service Pack 2 is the only thing I can think of that changed.

I have seen many postings about this but have not seen any real answers. I have looked at all of the similar issues regarding earlier versions of the server OS but we were working just fine until December. The PC's can see the network servers but when I go to log on, it just tells me that the name and password is not correct. I have made the PC name fit the short name on the server. I don't know if server 10.3 fixes this but I don't really have a grand to invest in the upgrade yet since everything else was working fine.

February 24, 2005
A reader named Adroc sent us a link to an Apple discussion board:

I had the same problem with XP no longer connecting to AppleShare IP. I found on the Apple discussion boards that others were having this problem - there is something in the most recent XP update that is conflicting - if you remove a portion of the update - you will be able to connect again - not sure if this works for OS X servers

February 24, 2005
Brian Smith sees the problem with both OS X 10.2 and AppleShare IP

I have had the same problem connecting to a MacOS X 10.2 desktop at home and my AppleShare IP 6.3.3 server at work. It seems that SP2 really wants domain info. Even if I have both my 10.2 box and my SP2 (professional) box in the same Workgroup, it still doesn't work. I have had this problem ever since I installed SP2 months ago. Clean reinstalls of XP do not "cure" the problem. MS seems to have made a fundamental change in the authentication of SP2.

February 24, 2005
Nathan Nelson has the problem with AppleShare IP, but the latest Mac clients can't connect either:

I am supporting a company with a number of PC clients connecting to an Apple server running OS 9, and AppleShare IP 6.3.3. Since SP2 has been installed on the PCs we've started to notice that one-by-one, the PCs can no longer connect to the file servers. The server is visible on the network but the PCs cannot connect to any of the share points. Windows 2000 also works fine. Interestingly, it would appear that MacOS 10.3.8 using SMB cannot connect to the old server either.

February 24, 2005
Michael Kuntscher suspects the Windows XP firewall:

Keep in mind that SP2 automatically enables Windows Firewall, which by default blocks File and Printer Sharing ports.

You'll need to specifically allow File and Printer Sharing traffic before your Macs will show up again:

Start -> Control Panel -> Windows Firewall

If Windows Firewall is set to "On", make sure that "Don't allow exceptions" is unchecked, then click the Exceptions tab at the top. Check the File and Printer Sharing option.

Click OK and then the Macs should eventually show up again in most cases.

February 24, 2005
Ken Reichel

We also can't connect after updating to SP2. I guess I'll just roll it back! (Sigh)

The problem and Mac OS X 10.3 Server

February 24, 2005
Glen Christensen saw the problem with AppleShare and fixed it with Mac OS X Server 10.3:

A client of mine experienced exactly the same symptoms as described by Nicholas Ley and Theresa Eking. They are using four Windows XP machines with SP2 and an AppleShare IP 6.3 server.

This setup had been working for 5 months without problems, until last week. The server is visible and pinball, but when logging on they get an error.

Eventually we installed Mac OS x server 10.3 and things have been working fine since. Since it had been working OK for a long time I suspect that perhaps it has something to do with a security of other type of Microsoft update.

February 24, 2005
Nathan Reilly has not had this problem with Mac OS X Server 10.3:

I've not had any issues (as yet) with XP SP2 connecting to 10.3 Servers. There are only 10 PCs, though.

February 28, 2004
Brian Smith says 10.3 does not help:

I have had the same problem connecting to a MacOS X 10.2 desktop at home and my AppleShareIP 6.3.3 server at work. It seems that SP2 really wants domain info. Even if I have both my 10.2 box and my SP2 (professional) box in the same Workgroup, it still doesn't work. I have had this problem ever since I installed SP2 months ago. Clean reinstalls of XP do not "cure" the problem. MS seems to have made a fundamental change in the authentication of SP2.

At work, we have a 10.3.8 machine. It has the same problem. A Windows 2000 box has no problem accessing it.

Security update 88520 is the cause

Readers report that the problem is caused by a security update that SP2 downloads, and not by SP2 itself.

March 2, 2005
Jonas Amrén of Sweden:

This hotfix, 885250, which deals with vulnerabilities in SMB, may likely be the cause of the problem. I had a similar case where a Win XP/SP2 PC (Swedish) connects to a ASIP 6.3 Server (Int. English) recently.

It had been working okay (with SP2) for a couple of months, until the 14th of February, when this update was installed, automatically, exactly as Win XP SP2 is by default, supposed to do.

It took a little while to find it, but when we went through the log on which updates that had been installed recently,and we tracked what they where supposed to fix, we found this candidate, removed it, restarted and it worked!

In "Add/Remove Programs" in the Control Panel, you can see what has been installed recently, if you check the little box on top of the page, so you can see all "Hot fixes" .

There can you also remove them, if you want. A tricky thing seems to be that even if you remove the hotfix, manually hide it, and tell it not to install automatically again, when a new update appeared a week later, it installed it again. I haven't found a way round that yet, so for now, Automatic Updates is OFF.

Or go to Windows Update, and check installation history there.

By default SP2 has: Firewall-ON and Automatic Updates-ON

(See also here for info on Windows security updates.)

March 2, 2005
Rob (no last name) saw the problem connecting not to Macs, but to Windows 98 machines.

We suddenly began having issues connecting to our Win 98 machines after the upgrade to Windows Service Pack 2. We ran some systematic upgrade tests, and it appears once one of the security patches gets downloaded and installed after installing SP2, the problems begin. For us, the computers that do not have the later critical security patches but run SP2 do not suffer from this problem. Those that have the automatic updates/installations turned on would see this problem as soon as the patch is made--which could occur overnight.

March 4, 2005
Daniel McKeel

Uninstalling hotfix KB885250 allowed me to connect to a Samba share on our ASIP 6.3 server from my Win XP SP2 machine. Reinstalling the hotfix reconstituted the problem.

March 4, 2005
Sammie Chan

After applying the KB885250 critical patch (Vulnerability in Server Message Block) to all 70 Win 200 Pro computers at the office two weeks ago, they all stop being able to properly connect with an ASIP 6.3 server. As a test, I removed this critical patch from one Win2K Pro box and it regain the ability to connect, mount and use the ASIP 6.3 server. Looks like MS "fixed" something in SMB that legacy Windows systems (ASIP 6.x mimics Win 95 file sharing) depends upon.

March 4, 2005
Bernd Hois of Austria

Deinstalling the hotfix 885250 solved our problems we suffered from. All Windows PCs that had SP2 and the hotfix installed couldn't connect to our Mac Os 9 file server.

March 4, 2005
Brett Pearce

We have 5 XP machines and on every one of them, once KB885250 hot fix is removed then access to our AppleShare IP server is restored.

An alternative to deinstalling

March 4, 2005
Chuck Hogye offers an alternative for accessing Mac OS X Server:

I can verify this is a problem and documented that it started around the same time the Microsoft Security Update MS05-011, 885250, was installed. Removing this update is very risky. A workaround is to delete the user from the Mac OS X server and re-enter the user with a different password. So far, this has worked. The login problem also extends to AppleShare IP 6 servers. Removing the user does not fix the problem on AppleShare IP. Since ASIP is no longer supported, I am not going to pursue it further.

Deinstalling caused an access problem

March 9, 2005
Yvette from Australia

We have an AppleShare IP 6.3 server running 6 Win XP machines and 8 Macs. We have removed MS update 885250, four of the Win XP desktop machines are now fixed and have no access problems, but 2 win XP laptops can only log in as guests. We have always had guest access turned off but now this is the only way the XP laptops can log on. Have tried creating new share folders, remade workgroups, upgraded IP from .0 to .2 etc. with no luck.

If you've seen this problem after removing security update 885250

The Oposite problem: Mac can't access Win XP 2 machine

November 8, 2004
Stephen Power

I, too, have recently upgraded my Windows XP laptop to Service Pack 2. My Mac "sees" the computer, but I cannot connect. I can, however, log onto the Mac from my PC, but have lost the ability to network print via the Mac.

If you've had a problem with Win XP SP2

Win XP problem with Mac OS X mapped drives

March 2, 2005
Jason Dunn

I have been researching a problem that has come about since December 2004. I have several Windows XP computers that connect to an OS 10.3 server. The Windows XP computers are connected to a domain that the OS 10.3 server is not a part of. I have tested this with Windows XP SP2 computers that are not a part of the domain as well with the same results. Here is the problem.

XP computers map a network drive on the OS 10.3 servers with no problem. If you open the Windows Search program, the Windows XP computers will get an "Access Denied" to the mapped drives. Currently, the best solution is to "Log Off" Windows and log back in. The drives reconnect and are accessible. I did not experience this issue with OS 10.3.6 but noticed this with OS 10.3.7. I had also upgraded to the Entropy PHP 5 during this time. I do not know of any changes on our network that would cause this.

Potential cause of the problem

March 4, 2005
Jerry Natowitz

Samba 3.05, introduced in 10.3.7 I believe, introduced this problem.

Suggested workaround

March 4, 2005
Stephen Yoch reports

I work for a hospital network and we are experiencing the exact same problem. Unfortunately, logging out and back in does not always fix the issue for us, though. We have managed to work around the problem by mapping to a different folder on the share.

For example, originally we mapped to the drive like this:


That worked until recently when some users noticed that they could not "save as..." from any windows program to the share. They received the error "Access Denied".

We changed the share to:


And now they seem to be able to access everything correctly.

Strangely, all users could access the mapped drive through the windows file system explorer. Seems they only had problems when in a program and tried to select the mapped drive to save a file to.

If you've see this

Slow Windows client access to Panther Server

April 8, 2005
Steve Dockery's Windows clients are seeing very poor Mac OS X Server performance:

Mac clients can access our Xserve at full speed, whether logging on using AFP or SMB, but Windows clients (Win XP and Win2K) get such pathetically slow performance that they can't really use it. It takes up to 20 seconds for any folder on the server to open, even if it has only one or two items in it.

Our Xserve is running Mac OS X Server 10.3.8 with all the latest updates. It's bound to an Active Directory server.

I need to solve this ASAP, because it's making my claims of cross-platform compatibility for the XServe and Mac OS X Server look bogus.

Suggestions from readers

April 11, 2005
Alan Sill points to the old problem of mismatched Ethernet duplex settings, which we've been reporting about since the days of Windows NT Server:

Windows clients notoriously do not negotiate network link duplex settings reliably. Depending on your network setup and router, you can find that rather than negotiating to 100 Mbits/sec, full duplex, you can find failure on one side or the other for the auto negotiation, resulting in a 100-half duplex connection. (Note that if either side fails on this negotiation, the link defaults to half duplex.) This can cause the kind of slowdown that you mention.

Note that you have to set one of precisely two conditions: either (1) BOTH sides have to be set to auto negotiate the duplex setting and speed, and succeed, or (2) BOTH sides have to be hard-set to 100-full.

It does not work to leave one side at auto negotiate and leave the other hard-set -- despite the hard-setting, you will get a 100-half duplex connection.

We saw such slow performance until we hard-set both sides of the Windows client computer links to 100-full, after which we saw normal speeds. Note that for some reason, the auto negotiation (if set on both sides) works much more reliably with Apple machines.

April 11, 2005
Scott Turner also suggests Ethernet:

Apple has articles in the KB about problems with Ethernet handshake causing these issues.

I've been battling it on and off for 2 years now. Power cycling hubs sometimes works, other times I'll flip the Ethernet handshake settings on the Intel Ethernet chip's driver settings and get the speed back up.

Right now my Tablet PC 2005 via Intel 802.11b/g mini-PCI card to an Airport Extreme via 100-base-TX to a Dual 2 2 GHz G5 is unusable. But if I jack the Tablet into the same hub as the G5 it zooms.

April 11, 2005
Sumeet points to Active Directory:

I think your problem may be due to a couple of reasons:

1. Your AD is too large for lookupd to handle. You may want to look at

/var/log/SystemLog for lookupd errors.

2. Use another form of Auth instead of AD. LDAP comes to mind, but you need to reconfigure some AD stuff. NIS of you want to install SFU 3.5, which is free

3. The best thing you can do is create local accounts if at all possible. Using nis to create the tree and then moving it to a local file will work, but it's tedious since the /etc/passwd file is entirely ignored until you do some nib tricks.

April 11, 2005
Ben Harper also thinks the problem is in Active Directory:

We have an Xserve running an architecture firm full of Windows users, and the speed is awesome. The Xserve is setup to be the PDC and manages permissions and user information internally I think perhaps your problem is binding it to an active directory server, and obtaining the information between the AD Server and the Xserve is causing the problem. Working on the connectivity between the two would probably be the place to start. If there is a Samba AD debug mode, I would turn it on; from my experience that reveals what the problem actually is.

 April 15, 2005
Steve Dockery responded to the suggestions readers gave earlier this week

I tried the suggestions people gave about Ethernet connections, but that wasn't the problem. It doesn't matter if the speed and duplex is manually set on both ends.

However, I don't understand WHY it works, but I do have a solution.

What we were doing was accessing the Xserve via a shortcut we put into Network Places. This works for our Windows 2000 Server, and I would expect it to work for the Xserve. However, it doesn't seem to work properly for the Xserve.

But there is another way to access it that DOES work. If you browse directly to it by going to "Entire network" in the Network Places window, it acts normally. Once you get to the Xserve, you can right-click on the volume you want, and select "Map Network Drive" which will put that volume into your "My Computer" window, associating it with a drive letter. Then, you can access it from there at normal speed.

Why does this work, but not the other way? No idea yet, but there must be some technical difference in how the two methods work that the Win2K Server doesn't care about, but which bolluxes up the Xserve. It may yet turn out to be AD related. If I solve it, I'll send an update.

Meanwhile, many thanks to everyone for their suggestions!

Another suggestion: VIA Ethernet chips are the problem

July 13, 2007
Joel Amar

I have a suggestion for slow Windows client access to Panther Server. I was struggling to resolve the same issue with our two OS X Servers and HP Procurve 10/100/1000 switches with no success. After a while it came to my attention that only PCs with VIA Ethernet chips where connecting and transmitting data very slowly to the servers, clients with Realtek and Intel Ethernet chipset were acting fine. After installing Intel/Realtek Ethernet PCE cards, without changing anything on the switches or the Server, the problem disappeared.

Previous to this, I tried installing different network card in the OS X server, and changing the settings -- I tried everything and every combination (Duplex/10/100/half/full/autonegotiotion/TCP-IP, DNS setttings software updates 10.3, 10.4 etc.) on the Wintel and Server unsuccessfully.

Windows clients locked out of Tiger Server/AD

June 21, 2005
Gavin Walsh has workaround to a problem with Windows clients accessing Mac OS X 10.4 Server. Unfortunately, the workaround needs to be repeated often:

I have a Tiger Server with Windows and Mac clients authenticating their access to it via an Active Directory. Every time I use the Workgroup Manager to change permissions and save it, our Windows computers can no longer access the share points on the server. The work around for this is to comment out "auth methods = guest opendirectory" and restart windows file services. Users can then access their share points on the server.

This is a problem as every time you change a permission on the server via the Workgroup Manager you need to go back in to the smb.conf file and re-comment out the line as the server overwrites it when you save your changes from the workgroup manager and restart windows file services (users then get disconnected from the server).

Is there any way to keep the commented line in the smb.conf file?

August 17, 2005
Martin Boegner

I am having the same problem that Gavin described above on a G5 XServe running 10.4.2, authenticating against our Active Directory. The workaround is functional. I wish I could say what could keep the commented out line in the smb.conf file, but at least I can relay what has not worked so far. I tried to restrict the permissions to read-only for all users on /etc/smb.conf, but that didn't work because it seems that the file is just getting overwritten when changes are made. I also tried commenting out the "auth methods = guest opendirectory" line in the /etc/ smb.conf.template file with a semicolon, but that didn't seem to work either after stopping and restarting the Windows File sharing service.

August 31, 2005
Massimo Sanna

I run into the same problem you talk about on your web site. I've been waiting since June for a 10.4.3 to come out and solve this problem. Every time I set up the AD/OD integration on one of our Xserve, everything is fine for a couple of hours, then it loses AD connection. When I reboot it, it just locks out with a blue screen, unless I detach the Ethernet cable and restart it locally.

Until a 10.4.3 release comes out I will log-in with local users in our Tiger file servers.

November 28, 2005
Bob Sneidar

Concerning the problem of Windows Users getting locked out of SMB, I too am experiencing this. I believe it's a bug in the server. I do not have to reconfigure anything. I just stop and start the server and all is well.

It should be noted that when browsing the network neighborhood the server does not show up for Windows Users until after I restart the Windows service. Once I do that the server is browsable again. I have to think the Windows stack is crashing somehow.

I contacted Apple tech about this problem. They are aware there is a problem but they have so little feedback on the issue that they have nothing to work from as yet. I would suggest encouraging those in the discussion to contact Apple especially if they can reproduce the problem, or if the problem occurs frequently.

One of the things that seems to be a part of the problem is that numerous SMBD processes are spawned and stranded, that is there are no logged in SMB users to account for them. One theory is that when users disconnect the processes are not terminated, however when I try to reproduce this the processes terminate normally.

Another theory is that a Windows virus or worm that attacks Windows servers may be using aggressive brute force tactics to gain access to the server from a PC on the same LAN as the server. The repeated attempts to log in to the server may be overwhelming it. What would be especially useful is to know if the problem goes away for anyone right after patching their PC's or running a virus sweep that detects a virus or worm infection.


September 3, 2005
Gary Pederson

Both my Windows and Mac users were locked out of SMB connections to my Tiger Server with AD authentication (My Macs are OK with AFP/AD).

Gavin mentioned that commenting out "auth methods = guest opendirectory" in /etc/smb.conf solves the problem until a change/ restart.

I suspect /etc/smb.conf.template is being used to generate smb.conf. So I've tried commenting out "auth methods = guest opendirectory" in / etc/smb.conf.template.

I don't know if this is the solution, but I do know that I've changed the access settings of share points with and without restarting the Windows Service a few times and "auth methods = guest opendirectory" in /etc/smb.conf remains commented and SMB/AD access has been working for 24 hours.

March 20, 2006
Rob Campbell has another suggestion

I had this problem, too, when I upgraded a client's Panther Server 10.3.9 directly to 10.4.5. You couldn't see the Mac server from the Windows XP Pro machines Then, I saw that the GUI for DNS was sort of blown, so I recreated and voila, I have connection again.

April 3, 2006
Andre Beckedorf found another workaround

I just wanted to let you know of a temporary workaround for the problem. Instead of fixing it on the OS X side, one has to change the authentication settings on the Windows boxes. Here is how to do that: 

Start -> Run "secpol.msc"
In the tree open and click Security Settings -> Local Policy -> Security Options
Scroll the left pane down to 'Network Security: LAN manager authentication level'
Change this to 'Send NTLMv2 response only'

It works for me. Also, from my investigations I can say, that only Intel Macs (10.4.5) seem to be affected by the problem.

Hundreds of processes on Tiger Server

NOTE: There are workarounds described below, as well as a verified fix.

The problem:

August 19, 2005
Bill Matthews reports a problem with Tiger Server 10.4.2 that brings it to a crawl when a small number of Windows clients are connected:

We're running Mac OS X Server 10.4.2 and we've encountered a new problem recently. Our primary file server recently exhibited some serious lag, and after a bit of digging I discovered that there were 240+ smbd processes running, despite only having about a dozen Windows clients connecting to this server. Each session was using between 0.1% and 0.6% of the CPU, so it quickly ate up all of the available CPU resources. Some were owned by our Windows users (although when I checked their computers, they had only one connection open to the server), but about half were owned by root.

Once I turned off the Windows service via Server Admin, all the smbd processes quit and things went back to normal. I turned Windows service back on, and after about 30 minutes, 3 smbd processes spawned, each owned by root, and each using about 40% of the CPU resources. This only started about 2 or 3 days ago. I haven't had a chance to reboot the server as it's our primary file server and I'm currently on the road, so I'd rather do it in person.

August 23, 2005
Chad Caswell

In response to the user have hundreds of smbd processes, I had the exact problem. No one on Apple's support pages could come up with a solution.

Our server is on a university network so I complained to the IT people. They swore up and down that it was a problem with my server.

The next day, the problem mysteriously disappeared. I didn't make any changes to the server. It's been problem free for over a month now.

I also set "max smbd processes = 10" in /etc/smb.conf, which may have helped.

August 25, 2005
Matt Fulghum:

We're seeing the same thing here at the University of Alabama; about once every two hours or so, if there's any Windows activity at all, our Xserve G5 freaks out. No resolution yet, but I'm trying the limited number of client connections trick. Unfortunately, we are running a large lab, so I really need the ability to support about 250 logged in users.

August 25, 2005
Bob Buell describes what he has attempted to deal with the problem:

The server in question is an upgrade to 10.4.2 from 10.3.9. Last Friday we had 196 smbd processes that were running on one of our file servers, we did a killall and restarted Samba. This freed-up the CPUs which through the day gradually ate 100 percent of the processors. At the time we were setting up 80 XP laptops and 30 XP desktops to join the domain login server. Login server is 10.3.9 with the mount point being the problem 10.4.2 file server only running AFP and Samba. The idea is to allow people to login to a PC or a Mac and access the same files. We were using one login account located on the file server in question to setup the XP machines. We hope to test multiple users this week. Last year at this time had problems with to many people joining the domain at one time. We abandoned the domain login for an easier direct approach with a custom visual basic GUI straight to the file server for hundreds of people. With the introduction of Tiger we had hoped to get the PDC working for a larger scale than the six XP people who actually used the Panther Login server as a PCD.

Another topic, unfortunately we also tried to upgrade our Panther PDC login server to Tiger. We had issues with this and are back to 10.3.9. The problem seemed (per Apple) to be with DNS forward and reverse even though it has been working for the last five years. We will try again next month.

Bottom line is that Panther was working great.

December 6, 2005
Steve Fair

We are also having the problem of hundreds of SMBD processes bringing our print server to a screeching halt. The print server is a Tiger 10.4.3 client fully patched and updated. It has been running great for months until about a week ago when I noticed the complete unresponsiveness of the machine. I tracked down the spawning of SMBD through Activity Monitor. As soon as the machine was rebooted, the processes would take down the computer within 2 minutes.

Once Windows sharing was disabled, everything works fine. I have created another 10.4.3 client with Windows sharing enabled that currently works fine. No solution has been found, yet.

March 24, 2006
John Cheng is seeing the problem with a desktop Mac:

I'm experiencing the hundreds of stranded SMBD processes on my dual core 2.3 GHz when Windows Sharing is turned on. Each consumed about 0.5 percent of CPU, which, in turn, consumed the whole box.  In the midst of trying to troubleshoot I set the "max smbd processes = 10", and then Windows XP could not connect to the Mac at all.  I reverted back to the original smb.conf but still no luck. I restarted the service and Mac did not help either.


December 12, 2005
Douglas DiBella

I've seen this problem and it really sucks! I can write a ton about the problem and would be glad to share the details. I noticed two problems.

1. SMBD log would grow and fill the entire system volume overnight and crash the system

2. SMBD spawning... to eventually halt the system.

I narrowed it down to unnecessary login attempts, my solution was to use firewall service to block samba/cifs access from external sources. This has resolved the problem, but I still don't consider it solved.

December 16, 2005
Galen Sprague

Do you have a maximum client connection limit set on your Windows Services? I have had problems with this and had to set it to unlimited. Also could you have PC clients running an app that is calling the server or running an App off of the server?

May 11, 2006
Mark Fisher

We've had the same problem, as described by several users. One thing that helps, temporarily, for us is unbinding the MacOSX server from the Active Directory domain that it is using for authentication. Then we add it back again. Windows users can again log on and the SMBD processes are normal. Seems like we need to do it every so often and we have no idea what triggers the problem.

The Fix

May 19, 2006
Stéphane Nouhaud edited the launchd file, which is a system daemon used to run scripts automatically. Nouhaud suggests:

I have the mysterious trouble with Samba and many, many SMBD processes who filled the process table of Tiger workstations when Windows sharing is on.

After some tests I think I’ve found solution.

I modify the launchd entry of SMBD process (org.samba.smbd) by adding a new program argument:
-F (newline after the /usr/sbin/smbd)

I made this modification with freeware Lingon utility.

And after that: No more SMBD process overflows, and samba works okay for me.

June 8, 2006
Bill Raab verified the fix:

In regards to your suggested solution I tip my hat. It worked wonderfully. This problem was easy to reproduce. I tried after implementing your fix and it worked. 

The fix also works for Tiger clients

June 19, 2006
Marek Wawrzyniak saw the problem of slow Mac OS X 10.4 performance with Windows file sharing clients logged on, caused by hundreds of SMBD processes on Tiger. While previous users saw this on Tiger server, Wawrzyniak had the problem on the Tiger client. The fix for the server also worked on the client

Tiger 10.4.6 client (not server) starting in Terminal:
smbclient -L localhost -U% and I have 500 smbd processes. The solution from Nouhaud fixed all problems (adding -F parameter).

Using Win XP to set ACLs (access control lists) on an Xserve Windows share

August 31, 2005
Phil Ershler

According to page 58 of the "Windows Services Administration For Version 10.4 or Later" manual, "The ACLs for folders in Mac OS X Server share points are compatible with Windows XP ACL settings. A Windows XP user can use Windows Explorer to set the ACL permissions of shared folders, and the changes will affect Windows, Mac OS X and Unix clients that access the folders."

I have set the ACLs on a share point so that I have Full Control over that share point. The issue is, I cannot from an XP client, that I have logged into (with my username and password in my LDAP/OD database), figure out how to use Windows Explorer to set the ACL's. I can set ACL's on a share local to the XP machine but not on an XServe Windows share. When I do a right click on the share (on an XP machine) I cannot get find anywhere to set the ACL information.

Now I have found a tantalizing bit of information in the O'Reilly book "Using Samba" 2nd Edition (covering Samba 2.2 and 3.0). (Checking on Tiger Server reveals that it is running version 3.0.10.) On page 260 under Configuration Options for ACL's is a boolean option named "nt acl support" which says "If yes, allows users on Windows NT/2000/XP clients to modify ACL settings". It goes on to say the default is yes and the scope is Share. If I look in /etc/smb.conf I do not see an entry for "nt acl support" under the share portion of the config file. Has Apple redefined the default for this option to be no? I've got a "sandbox" 10.4.2 server. I guess I'll try adding this option to the config file and see what happens.

September 3, 2005
Philip Ershler sent a follow-up

I did try the experiment of adding the following line to /etc/

smb.conf in the [Share] section (that I described in my first e-mail)
nt acl support = yes

In my case I actually had to add the [Share] label. But adding this option seems to have fixed the problem.

Now comes the issues of understanding the in's and out's of ACL's.

September 3, 2005
Jason Staloff also provided a solution and a link:

I used SWAT to look at the full config for a totally vanilla SAMBA on Tiger Server. Click on the View button, then Full View, it basically dumps the whole environment.

nt acl support = yes
also maybe interesting an undefined option...
acl compatibility =

There is more info about turn on SWAT for Tiger at Mac OS X

If you can verify any of this

SlowAuthentication/login of Windows clients to Mac OS X Server

A reader offers a fix below.

August 31, 2005
Matt Vlasach says his Windows clients take a long time to log in:

I have a 10.3.9 Server G5 box, running as a PDC for about 24 Win XP SP 2 clients. File sharing and transfers work great (after I applied a nice 'netbind seperator = +' fix to smb.conf). However, login speeds are disappointingly slow, about 20 seconds.

This seems to be more of a Open Directory issue, not SMB. After close inspection, it uses a NET_AUTH login method, which fails within 1 second, stalls 20 seconds, then tries a LSA method (which tries and fails in < 1 second), then a SAM_NETLOGON (or something) and it works within a second. Basically, this NET_AUTH thing is not doing its job well, but the SAM_NETLOGON is. I have no idea what determines the order of these authentication methods, or if they are adjustable.

But sometimes it work within 5 seconds. I don't get it, maybe there is more to that 20 second delay than I realize (ie 20 seconds due to current system activity, number clients etc). I do know that many windows servers can authenticate users within 2 seconds, which would be ideal.

But, I would say with this login delay fixed, we will have a flawless Mac PDC to Win XP client environment.

September 3, 2005
Michael Cutter

I have the same problem here. It's not a big deal as we only have 3 PCs but it annoys me that I don't know how to fix it! 10.3.9 Xserve G5 (happened prior to 10.3.9) NOT running as a PDC just a standalone file server, authentication done via normal 'log in as a different user' procedure on Windows. The server is running a shared LDAP directory with a second G5 slave server.

Would love to know if you come across a solution.

Also Matt made mention of "netbind seperator = +" fix to smb.conf - any idea of where I can find an explanation of why this is a good thing?

Suggested fix

November 7, 2005
Louis Gephardt

I ran into this same issue, the issue was bad DNS resolution. Make sure you server has a DNS entry and that it will resolve the hostname and IP address BEFORE promoting your server to an Open Directory Master. If DNS is not working correctly, you will have ALL sorts of problems and will likely have to rebuild the LDAP. Once I got DNS running correctly and rebuilt the LDAP, the login time dropped to less than a second.

Authentication of Win 95/98 clients to Tiger Server 10.4.6

May 8, 2006 -- Paul Rauschelbach reports an authentication problem with old Windows clients and the most recent Tiger Server upgrade. He fixed it by editing Mac OS X’s smb.conf file (in the invisible /etc/ directory):

I had a problem where Windows 95/98 clients could not authenticate to Mac OS X Server 10.4.6. According to AppleCare Support, this is apparently a known issue, reported by several people, and Apple has an "engineer working on it."

I found an answer myself. Changing the "lanman auth = no" line (line 13 in mine) in the /etc/smb.conf file to "lanman auth = yes", then restarting the Windows service allowed my Windows 95/98 clients to connect as guests. The Server Admin application seems to have checkboxes for this setting, but checking or unchecking LANMAN in the Windows authentication options doesn't seem to affect it in 10.4.6.

Readers don’t have success with Win authentication problem with Tiger Sever

A pair of readers told us that the fix we posted earlier this week did not work for them. The problem was one of authentication of Win 95/98 clients to Tiger Server 10.4.6

 May 11, 2006

I tried this tip and it didn't help.

May 11, 2006
Fred Tsui provided some details of his situation:

So I ran into the same problem when I upgraded to 10.4.6. I tried Paul Rauschelbach idea. I looked at my server's smb.conf and found that lanman already had a yes by it. But "client ntlmv2 auth" had a no even though the checkbox was marked in the Settings page. Either way my Win 98 boot floppy was not able to connect to the Mac OS X Server with a local account.

What I mean by that is that I have a local account on the server that the boot floppy is using and the boot floppy returns an access denied message when trying to log in.

I didn't try guest as I don't allow guests to login.

If you’ve tried this

Changing admin password disables domain login

May 19, 2006
Adam Konner reports a problem where changing the administrator’s password on Mac OS X server prevents Windows clients from connecting:

I'm having a repeated problem where changing the directory administrator's password to anything other than what it is makes it so that Windows clients cannot connect to the domain for login. Mac clients can still log on just fine. Changing the password back to the old value fixes it. (Mac OS Server 10.3.2 AND 10.3.9, Windows XP SP2.)


May 22, 2006
Brian McCall

Here's my guess: If you change the admin password, it longer matches the (admin) password you (likely) used to join the client machines to the domain in Directory Access. You may be able to push the Directory Access.plist out to clients to solve it, but I doubt this is an Apple recommended solution.

An Explanation

May 25, 2006
C.J. Zinngrabe

The username/password you use to join the domain is only used to join the domain, but the username/password you use to set up samba is used to perform all kinds of operations in samba. If you change that password, windows clients can't log in. See this thread from the Apple discussion lists for more info.

If you’ve tried this

Tweaking SMB in Tiger Server

June 19, 2006
A reader named Mike believed that Mac OS X 10.4.x Tiger changed the way the Samba SMB file server worked. With previous versions of Mac OS X Server, he could do some standard tweaking of SAMBA by editing the smb.conf file. He found that with Tiger Server, the changes caused SMB to stop working. He also found a solution. Here is Mike's report:

We have a Mac that we use as the company file server. We have run previously Jaguar Server, and presently, Panther Server. Now we are testing Tiger Server.

On the Jaguar and Panther servers, I tweaked the smb.conf file for each, to include shares: one “smb share” for each of our office computer users who operate Windows PCs. With Tiger Server, the same tweak caused serious problems.

For example, our smb.conf file on the Panther based Mac, includes lines like these:

> dns proxy = no
> hosts allow = 192.168.1., 192.168.2., 192.168.3., 127.
> [BobPCFiles]
> comment = Bob’s backup share on the Mac server
> path = /Volumes/Partition_04/BobPCFiles
> valid users = @OUROFFICE
> write list = @OUROFFICE
> read only = no

I always add the first two lines to a Mac’s smb.conf file, to solve a few issues. The remaining lines are an example of a share on our Mac server. The server has a few external SCSI hard drives that are partitioned, one partition per company user (15 partitions total).

The setup has always worked reliably, and the Mac server has been running straight for three years without a hitch.

With Tiger Server, there were problems. Users could not connect via SMB, from other Macs or any PCs. Their password would not “take,” so to speak.

Tiger’s new feature in System Preferences > Sharing > Services window, requires that you must permit SMB users’ accounts for gaining access to SMB shares on the Mac. This apparently is woven in with some kind of barricade that Apple set up between the smb.conf file and Samba, preventing Samba from acting as it should with a “good” smb.conf file.

What I finally realized is that I had to remove (“comment out”) these two lines:

> valid users = @OUROFFICE
> write list = @OUROFFICE

These lines had worked as they should with Samba on Jaguar and on Panther, but not so with Tiger.

As long as these two lines were enabled in the smb.conf file, users across our LAN could see the Tiger-running Mac, but their username and password “could not seem to gain SMB access.”

After “commenting out” these two lines, and then I had to disable all the (approved) user accounts in the Tiger’s System Preferences > Sharing > Services window. Then re-enable the (approved) user accounts. Enable Windows (SMB) file sharing again, and restart all the machines. The setup now works.

I would prefer that Apple not mess with Samba. I noted that some users with enough skill have installed Samba updates that “fixed” Samba so that Samba responds as it should to the smb.conf file setup.

Yet, our test Tiger Mac office server now works.

Problem with Vista authenticating to OS X Server

Thursday, September 6, 2007

Christian Jacob has a problem with a Windows Vista client and Mac OS X Server:

Our Macs and PCs up to Windows XP work just fine with Xserve G5 running Mac OS X Server 10.3.9. Now, a new laptop with Windows Vista installed won't authenticate. I can ping the server but I cannot login. The same userprofile on a different Windows client with XP can login successfully. The individual workgroup is set, username+password is correct, and IP configurations are set correctly as well. Defender, Firewall and everything is deactivated in Vista.

If you've seen this issue

TIP: fixing Vista's problems connecting to OS X by changing NTLM settings

Monday, September 10, 2007

A change in the way Windows Vista does authentication may be the cause of Vista's problems connecting to Mac OS X Servers. Readers sent us a number of different procedures (or links to procedures) to fix the problem. One reader said that the problem is caused by the "NTLMv2-based authentication Vista uses when Kerberos fails."

First, here are two suggestions not having to do with NTLM authentication. Hayward Kong said:

I've seen this problem with one of my clients who started adapting Vista Business machines to their network. Currently, they have an OS X 10.4.10 Server which servers files to a cross platform network. To get around this problem make sure you just use the IP address of the server and not the computer name on workgroup/domain. They have been doing this for the past 5-6 months and have no problems now. Hopefully this issue will be addressed in Mac OS 10.5 Server.

Rich White offered another simple method:

I can log in to our OS X Server from Vista only if I use "WORKGROUP/username" instead of just the username. This is true even though I'm in the same workgroup.

Aaron Hawkins and Victor Wise both found a solution described at that has to do with alterning NTLM authentication on Vista. Wise said " We had to make a change on the Vista client under the NTLM security settings to allow authentication. After this we were able to mount the shares on our Mac OS X Server."

However, Hawkins said the fix was temporary: "Strange, though, as the afflicted computer will work after you do the steps, but if restarted, will not authenticate until the steps are performed again."

An anonymous admin sent us an explaination and procedure that he has used successfully:

The problem has to do with Kerberos and the form of NTLMv2-based authentication Vista uses when Kerberos fails. Basically Vista clients fail to get Kerberos tickets when connecting to OS X server because when they make the request for a service ticket to the Active Directory (AD) server, they use the OS X Server's short name (or basename, depending on your background), instead of the Fully Qualified Domain Name (FQDN). This is a problem because the Active Directory plug-in only creates Service Principal Names (SPNs) using the FQDN when it binds to Active Directory. The reason XP works is because it uses the Fully Qualified Domain Name in its service ticket requests.

For example, when a computer record is created there is a cifs service principal named cifs/ Now XP uses that in the service ticket request when attempting to authenticate to the OS X server. AD finds that, and grants the request, and XP gets a ticket. Vista, however, uses the short name, so it's looking for something like cifs/yourserver in the computer record; however, that doesn't exist, so no ticket is granted.

Normally if Kerberos can't be negotiated, the XP or Vista clients fall back to some form of NTLM-based authentication. Now another Vista change is the local security policy for LANMAN-based authentication was changed to NLMv2-only. This means that Vista clients will attempt to negotiate NTLMv2 over NTLMSSP authentication. Unfortunately the version of Samba in Tiger doesn't support NTLMv2 over NTLMSSP. It can do NTLMv2 OUTSIDE of NTLMSSP, but to get that you have to disable SPNEGO in the /etc/smb.conf (along with the other negotiation protocols, such as Lanman and NTLM). If you do that Samba can negotiate NTLMv2 fine. Unfortunately, that means you have to choose because once you disable SPNEGO you can no longer use Kerberos.

The fix is to try to get Kerberos going - which you can do by adding a cifs service principal with the short name to the servicePrincipalName attribute in the server's record in AD. Here is an example using the 'setspn' command to manipulate the servicePrincipalName attribute (done on a domain controller with the appropriate administrator privs):

C:\ setpn -L yourserver

This gets you a list of the service principals assigned to that computer record:

  • xgrid/
  • vpn/
  • ipp/
  • xmpp/
  • cifs/
  • host/
  • smtp/
  • HTTP/
  • pop/
  • imap/
  • ftp/
  • afpserver/

To add the appropriate record:

C:\setpn -A cifs/yourserver yourserver

This gets you:

  • cifs/yourserver
  • xgrid/
  • vpn/
  • ipp/
  • xmpp/
  • cifs/
  • host/
  • smtp/
  • HTTP/
  • pop/
  • imap/
  • ftp/
  • afpserver/

You'll need to let this replicate out, but your Vista clients should now be able to get their Kerberos tickets and authenticate as expected.

Michael Kennard forwarded another NTLM-based solution:

Here is a link to a solution that worked for me. The solution is towards the bottom.

Mikael Fredriksson has another suggestion regarding NTLM::

We had the same trouble to connect Vista computers to our XServe with OS X 10.4.10 but got it to work by changing settings on the Vista computer. (See this link.)

Note that, in some cases, I've seen Windows Vista refuse to process the username/password properly between the Windows and Mac. While I haven't encountered the problem in Vista Business, I've seen it occur when using Vista Ultimate. To enable access to shared Macintosh resources within Vista Ultimate:

  1. Click Start.
  2. Type secpol.msc in the search box and press Enter.
  3. Windows Vista will display a warning message; click Continue.
  4. Windows Vista's Local Security Policy console will appear. Highlight Local Policies.
  5. Double-click Security Options.
  6. Scroll down to the Network Security: LAN Manager Authentication Level policy entry and double-click it.
  7. Change the value from the default setting of Send NTLMv2 Response Only to Send LM & NTLM -- Use NTLMv2 Session Security If Negotiated, then click OK. (Figure J).
  8. Close the Local Security Policy console.

Gary Minato:

Vista uses a later version of SMB than does Mac OS X Server. The issue here is that the authentication in Vista's version of SMB has been upgraded and only accepts authentication from requests from clients that meet this newer version of SMB authentication. There are workarounds this for this issue for some versions of Vista ABOVE Home Premium and not so simple workarounds for other versions.

if any of these solutions worked for you.

Vista can connect to Macs running ADmitMac, DAVE

Thursday, September 13, 2007

A spokesperson for Thursby Software reported that problems with Windows Vista connecting to Mac OS X Server don't occur with the ADmitMac 3.2.2 and DAVE 6.2.2 updates from last June:

We had to update both DAVE and ADmitMac to properly work with the Vista client. I assume that the current Apple [Mac OS X Server] release is probably having similar problems to what we experienced. All of our products now support Vista.

DAVE is Thursby’s enhanced SMB file transfer and print server/client for Mac OS X. ADmitMac is Active Directory integration software for Mac OS X that also includes the file and printer sharing features of DAVE.

Our Mac OS X Server Cross-Platform Issues page contains suggested workarounds for connecting Vista to Mac OS X Server.

More suggestions for Vista authenticating to OS X Server

Wednesday, September 19, 2007

We have two more reports from readers about problems with Windows Vista connecting to Mac OS X Server.

Peter Fletcher altered his logon:

I saw the Vista authentication issue posted by Christian Jacob on September 6th 2007. I too had this problem, but was able to solve it by adding the IP address of the OS X Server before my Vista Users login.


Password: ********

Not sure why you have to do it that way, but it has worked for me. By the way, I am running Mac OS X Server 10.4.10.

Gary Minato had an explanation about NTLM in Vista, some advice from Microsoft, and some more links:

Vista uses a later version of SMB than does Mac OS X Server. The issue here is that the authentication in Vista's version of SMB has been upgraded and only accepts authentication from requests from clients that meet this newer version of SMB authentication. There are workarounds this for this issue for some versions of Vista ABOVE Home Premium and not so simple workarounds for other versions.

I've got some links to info on the web on this topic:

  • At, from Michael Bishop (MS) - "Basically, the issue with Samba and Vista is that Vista no longer permits LM or NTLM authentication by default; only NTLMv2. Samba versions 1.x and 2.x only support LM and NTLM, so there's an issue there.

"[MS] Recommended solution: upgrade to Samba 3.x and enable NTLMv2 by adding "client ntlmv2 auth = yes" to your smb.conf file. Because of another issues with previous versions, I strongly recommend upgrading to 3.0.22 or later regardless of your choice for this particular instance."

Fix verified for Vista authentication to Mac OS X Server

Monday, September 24, 2007
Mark Caban verified two suggestions for fixing the problem of Windows Vista authenticating to OS X Server:

I used Hayward Kong's and Rich White's suggestions and they worked for me. I have a wired home network with two iMacs running OS X 10.4.10 and one PC running Vista Basic. Vista would not recognize the username or password until I tried the above mentioned suggestions that I found on your site.

Tiger Server problem with Win clients user profile

Wednesday, December 19, 2007
Bill Earlywine reported a problem with Tiger Server and Windows clients' user profiles:

I have an OS 10.4.10 Server acting as a Windows PDC. I cannot create a local Windows user profile - roaming profile is set by default.

Existing Windows XP users can bind, login and authenticate to the domain. These users all have a LOCAL User Profiles.

When I setup a NEW Win XP user, I can bind them to the Domain, log them in and authenticate to the domain, but I CAN'T change their USER PROFILE type from "Roaming Profile" to "Local Profile". Local profile is greyed out.

Since I don't have the storage needed to store Roaming Profiles I need all users to have a Local Profile.

If you've seen this problem

Current news at MacWindows home

| Top of This Page |

Other MacWindows Departments

| Solutions | Reader Reports | News Archives | Site Map |
MacWindows Home |

Serving the cross-platform community since November 15, 1997.
This site created and maintained by
Copyright 2006-2007 John Rizzo. All rights reserved.