There’s a new guy at work who insists that the use of “to whom” is archaic. His incorrect opinion, therefore, earns him the traditional MMH pseudonym of “The Unlettered Python Expert”, or TUPE for short.
So, TUPE comes into my office yesterday with a problem: He cannot connect to our shared file server (which runs Mac OS X Server 10.4.x) from his Linux box using SMB. He experienced the same problem a couple of weeks ago, but during my troubleshooting efforts the Server Admin utility stopped responding altogether. I had to reboot the whole thing anyway, and dismissed his inability to connect as some fux0r’d daemons and whatnot.
That wasn’t the case yesterday (and probably wasn’t the first time).
To make sure the SMB server was handling shit properly, I connected to it from my Mac using the traditional Apple+k keystroke, standard “smb://” server address, and my username & password. Success.
Next, I tried it from the Terminal application (command line) using smbclient, as he had tried from his box, again using my login credentials:
~ $ smbclient -U myname //1.1.1.1/SHARENAME
Password: (entered the right one)
Domain=[XSERVE] OS=[Unix] Server=[Samba 3.0.10]
smb: />
Success.
Aside: The above command will implicitly attempt to connect to the remote server (1.1.1.1) on port 445, which is the canonical SMB Domain Server port. If you wish to connect directly to port 139 (the “pure” SMB port), you must specify “-p 139″ somewhere in the command (as I’ve done below). Add “-d 3″ to the command to turn on debugging level 3, which will display IPs, ports, etc. if you want to see stuff like that.
Then, I tried it again from my box, but this time using TUPE’s username and password:
~ $ smbclient -U username -p 139 //1.1.1.1/SHARENAME
Password: (entered one)
session setup failed: NT_STATUS_LOGON_FAILURE
Failure? Agony!
This pointed to something wrong with his user account on the server. Naturally, I assumed that I’d supplied an incorrect password, and exhausted that possibility.
By this time, the Workgroup Manager app had been launched, and I was fucking around with his user account in an unholy manner. Going through it all, I noticed that my (working) user account was using a “Shadow” password, whereas his (b0rk’d) account was using a “Crypto” password.
Conclusion #1: The SMB server on OS X Server 10.4.x requires an account use shadow passwords.
Aha! Time to fix it. Go in, change his account to use shadow, re-enter his password a couple of times, and save it. Refresh the page…
“Crypto” Goddamnit!
Attempt the same procedure 4 to 23 more times. Utter “goddamnit!” 4 to 23 more times. The stupid GUI won’t let me change it!
Time to read up on some Apple Support docs, eh? I finally found one that says:
Only users whose accounts reside in the local directory domain can have a shadow password.
Huh? WTF is a “local directory domain”? As the “administrator”, am I supposed to know? Cuz fuck if I do! Further down:
Click the small globe icon above the list of users and choose from the pop-up menu to open the local directory domain where the user’s account resides.
“Small globe icon”? WTF? I can’t see any small globe…
Yeah, so there it is. Note also that the line of text next to that elusive little prick of an icon reads, “Authenticated as xxxxxxxx to directory: /NetInfo/root”. Could this be the problem? Click the little bastard…
Oh, shit… I can change that! I still don’t know WTF a “local directory domain” is, but that fuckin’ pulldown has a “Local” option! Select that.
Now the line of text reads, “Authenticated as xxxxxxxx to local directory: /NetInfo/DefaultLocalNode”.
Go back to his user account, change it to use shadow, do the password dance, and save it. Refresh the page…
“Shadow” w00t!
Conclusion #2: Make sure that you have “Local” selected in that crappy little pulldown menu if you experience problems doing shit to the user accounts on the server.
Try the connection again:
~ $ smbclient -U username -p 139 //1.1.1.1/SHARENAME
Password: (entered the right one)
smb: />
Success.
