Access Mac file sharing from Windows: Logon failure
I have a new Mac Mini running OS X 10.8.2 that I have configured for File Sharing so that I can access its files from a Windows 7 machine and Windows Server 2008 R2 machine.
I have completed the steps to enable File Sharing in OS X, selected two shared folders, and added two users to the file sharing Users list on OS X. After adding the users, I retyped their passwords for SMB access. As far as I can tell, OS X is fully configured for SMB sharing. I can see the Mini on the network from my Windows machine.
When I go into Windows and try and access the Mac, I am immediately prompted to enter a network password. I enter either one of the usernames and passwords, but Windows responds:
"Login failure: unknown username or bad password"
The computer name is "mini", so I've tried "mini\username" for the user, and "192.168.25.215\username",
I've gone into OS X and reset the SMB passwords for the two accounts, but that didn't solve it.
I thought I had tested this successfully after I configured the mac file sharing, but I can't get it to work now.
Thoughts or suggestions?
I have completed the steps to enable File Sharing in OS X, selected two shared folders, and added two users to the file sharing Users list on OS X. After adding the users, I retyped their passwords for SMB access. As far as I can tell, OS X is fully configured for SMB sharing. I can see the Mini on the network from my Windows machine.
When I go into Windows and try and access the Mac, I am immediately prompted to enter a network password. I enter either one of the usernames and passwords, but Windows responds:
"Login failure: unknown username or bad password"
The computer name is "mini", so I've tried "mini\username" for the user, and "192.168.25.215\username",
I've gone into OS X and reset the SMB passwords for the two accounts, but that didn't solve it.
I thought I had tested this successfully after I configured the mac file sharing, but I can't get it to work now.
Thoughts or suggestions?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@wrwiii12: I am pretty sure that I tested it after I set it up, but it was a week ago and it was a brief test. At the time it seemed to work fine--it was so simple I didn't think twice about it.
I have checked the System Log, and as soon as I attempt to access \\mini from my Windows 7 machine, the system log shows the following auth error.
Windows 7 is always defaulting and sending a domain value. By default, that value is "I7", the name of my windows machine. I tried changing it to MINI, the name of the Mac machine, but that didn't seem to help.
If I only enter a username in the Windows auth dialog, it will send the default value of I7, the windows machine name.
After searching for the "guest failed with 22 proto=ntlmv2", there are a few posts discussing that. Some seem to indicate a potential issue on the Mac side, while some indicate an issue with Windows 7.
https://discussions.apple.com/thread/3206725?start=45&tstart=0
https://discussions.apple.com/thread/3950759?start=0&tstart=0
I'll poke around a little more based on these threads, but if you find something that seems relevant, I'm all ears.
I have checked the System Log, and as soon as I attempt to access \\mini from my Windows 7 machine, the system log shows the following auth error.
12/31/12 7:10:05.320 PM digest-service[355]: digest-request: uid=0
12/31/12 7:10:05.320 PM digest-service[355]: digest-request: init request
12/31/12 7:10:05.321 PM digest-service[355]: digest-request: init return domain: BUILTIN server: MINI
12/31/12 7:10:05.323 PM digest-service[355]: digest-request: uid=0
12/31/12 7:10:05.323 PM digest-service[355]: digest-request: user=MINI\steve endow
12/31/12 7:10:05.324 PM digest-service[355]: NTLM domain not configured
12/31/12 7:10:05.324 PM digest-service[355]: digest-request: kdc failed with 36150275 proto=unknown
12/31/12 7:10:05.324 PM digest-service[355]: digest-request: guest failed with 22 proto=ntlmv2Windows 7 is always defaulting and sending a domain value. By default, that value is "I7", the name of my windows machine. I tried changing it to MINI, the name of the Mac machine, but that didn't seem to help.
If I only enter a username in the Windows auth dialog, it will send the default value of I7, the windows machine name.
After searching for the "guest failed with 22 proto=ntlmv2", there are a few posts discussing that. Some seem to indicate a potential issue on the Mac side, while some indicate an issue with Windows 7.
https://discussions.apple.com/thread/3206725?start=45&tstart=0
https://discussions.apple.com/thread/3950759?start=0&tstart=0
I'll poke around a little more based on these threads, but if you find something that seems relevant, I'm all ears.
ASKER
Well, the theme in the second thread I posted above seems to be the cause. It seems that SMB stops working after a while and has to be stopped and restarted. To the Windows client, it appears as an authentication failure.
I unchecked the SMB Sharing option, saved the setting, then went back in and re-enabled SMB Sharing. All of a sudden, I was able to connect to the Mac from Windows. It asked for my username and password, which I typed without a domain prefix, and it worked fine. The Mac shares showed up right away.
Screen shot attached.
For reference, here is the Mac log after the successful authentication. This time it shows "od failed", which is discussed in the Apple forums thread, but it seems to have worked.
I unchecked the SMB Sharing option, saved the setting, then went back in and re-enabled SMB Sharing. All of a sudden, I was able to connect to the Mac from Windows. It asked for my username and password, which I typed without a domain prefix, and it worked fine. The Mac shares showed up right away.
Screen shot attached.
For reference, here is the Mac log after the successful authentication. This time it shows "od failed", which is discussed in the Apple forums thread, but it seems to have worked.
12/31/12 7:27:48.905 PM digest-service[499]: digest-request: uid=0
12/31/12 7:27:48.905 PM digest-service[499]: digest-request: init request
12/31/12 7:27:48.906 PM digest-service[499]: digest-request: init return domain: MINI server: MINI
12/31/12 7:27:48.909 PM digest-service[499]: digest-request: uid=0
12/31/12 7:27:48.911 PM digest-service[499]: digest-request: od failed with 2 proto=ntlmv2
12/31/12 7:27:48.911 PM digest-service[499]: digest-request: user=I7\Steve Endow
12/31/12 7:27:48.915 PM digest-service[499]: digest-request kdc: ok user=MINI\Steve Endow proto=ntlmv2 flags: NEG_KEYEX, ENC_128, NEG_VERSION, NEG_TARGET_INFO, NEG_NTLM2, NEG_ALWAYS_SIGN, NEG_NTLM, NEG_SIGN, NEG_TARGET, NEG_UNICODE
12/31/12 7:27:48.959 PM rpcsvchost[510]: sandbox_init: com.apple.msrpc.srvsvc.sb succeeded
12/31/12 7:27:48.985 PM smbd[507]: MINI\Steve Endow connected to path /var/rpc/ncacn_np
12/31/12 7:27:49.162 PM smbd[507]: MINI\Steve Endow connected to path /Users/steveendow
12/31/12 7:27:49.186 PM smbd[507]: MINI\Steve Endow connected to path /
12/31/12 7:27:49.206 PM smbd[507]: MINI\Steve Endow connected to path /Volumes/MAC BACKUP 1
12/31/12 7:27:49.227 PM smbd[507]: MINI\Steve Endow connected to path /Volumes/Mac Archive
12/31/12 7:27:49.250 PM smbd[507]: MINI\Steve Endow connected to path /Users/steveendow/Downloads
12/31/12 7:27:49.257 PM smbd[507]: MINI\Steve Endow connected to path /Users/steveendow/Documents
Man that is odd. Glad to hear you got it fixed.
ASKER
The tip to check the Mac logs led me to a detailed error that helped me solve the issue. The issue appears to be an issue with OS X 10.7 - 10.8.2, affecting both OS X Server and 'workstation' versions.
Have you done the same thing??