Many thanks - you saved me from the madhouse.
Before stopping and starting SMB the messages in /private/var/log/krb5kdc/kdc.log invariably had been:
2011-10-10T16:57:56 digest-request: init request
2011-10-10T16:57:56 digest-request: init return domain: BUILTIN server: G-DATOR-S
2011-10-10T16:57:56 digest-request: uid=0
2011-10-10T16:57:56 digest-request: user=G-DATOR-S\\thomas
2011-10-10T16:57:56 NTLM domain not configured
2011-10-10T16:57:56 digest-request: kdc failed with 36150275 proto=unknown
2011-10-10T16:57:56 digest-request: guest failed with 22 proto=ntlmv1-with-v2-session
Then I tried it your way:
sudo serveradmin stop smb
wait a few seconds
sudo serveradmin start smb
Now I can connect, and the message is:
2011-10-10T17:15:59 digest-request: init request
2011-10-10T17:15:59 digest-request: init return domain: G-DATOR-S server: G-DATOR-S
2011-10-10T17:15:59 digest-request: uid=0
2011-10-10T17:15:59 digest-request: user=G-DATOR-S\\thomas
2011-10-10T17:15:59 digest-request kdc: ok user=G-DATOR-S\\thomas proto=ntlmv1 flags: NEG_KEYEX, ENC_128, NEG_VERSION, NEG_TARGET_INFO, NEG_NTLM2, NEG_ALWAYS_SIGN, NEG_NTLM, NEG_SIGN, NEG_TARGET, NEG_UNICODE
I'm running the Lion server in a VMware machine inside my MacBook Pro (SSD). I always thought that that's a slow combination, but from your words it follows that it's not sooo bad :-)
Following your advice, I created a launchd script:
sudo su -
cat > com.gutzmann.restart_smb.plist <<@@EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<string>sleep 60;serveradmin stop smb;sleep 5;serveradmin start smb</string>
launchctl load com.gutzmann.restart_smb.plist
Thank you very much again,
Same issue here. I was able to reboot my 10.7.1 server without issue (SMB connections would work fine).
However after applying the 10.7.2 delta server update via Software Update, SMB was open, but nobody could authenticate to the server (Mac or Windows using SMB).
Having to stop/start smb has temporarily resolved it.
I haven't rebooted the server again (yet), so I don't know if this is/was a one-time issue related to the upgrade process or if it's now a every-time-you-restart issue.
I would agree it may be a hardware-specific issue. The older core2duo Mac Mini I use for testing server does not show this problem. My production server (a current-gen MacPro) showed this today.
THAT SAID: 10.7.2 fixes the need to prefix the user name (on Windows) with the server's netbios name!
I can now log into my server from windows with "maser" instead of "<netbios>\maser" again! (Though the prefix still works, too...)
Yes i can confirm that after 10.7.2 Server Upgrade there's no need to prefix the user name with server name.
But 10.7.2 didn't fix Windows Vista strange behavior creating new folder. As explained by Jeroen in another post (https://discussions.apple.com/message/16065677#16065677) there is a problem whith Vista client and SMB shares on Lion. I can confirm what Jeroen wrote: "When I add for example a new folder, in explorer the folder shows up as "ew Folder" instead of "New Folder". When I try to change the name of the created folder, Windows report it can't find the folder. When I refresh the explorer, the foldername is correct".
This problem doesn't affect mine XP and Vindows 7 clients that are working very well.
Could someone confirm to have the same problem?
Any ideas or solutions?
This is probably the attribute bug in 10.7.2's implemenation of SMB causing this.
If you remove the attributes/metadata from the file (from the server end), then you should be able to copy it.
If you want to remove all metadata on all the files, you can do:
sudo xattr -r -c * (the -r is recursive, the -c is to "clear all")
Otherwise, you could just try removing specific attributes directly like:
sudo xattr -d com.apple.metadata:kMDItemWhereFroms (as an example).
The key (I think) is to not put files that you download from the internet on a Mac on a share where Windows users would access them -- at least until Apple releases a fix for this.
From what I've seen, the "bad" attributes/metadata gets put on files downloaded by Safari and (IIRC) e-mailed documents from Mail.app. If you put those files on the share, they'll have problems for Windows users (though, what I've seen is just trying to copy the files from the share to the Windows desktop -- not any problems actually *opening* the files, though. YMMV...)
I still don't think anyone has found a reliable fix / workaround to allow a windows client to connect to an SMB share on a mac mini server using an OD (network) account.
If someone with this exact setup has found a way please enlighten us. We have tried everything in these posts to date with no resolution. We can only login to the share using local accounts.
In my testing with Win 7, my descirbed method worked reliably.
I didn't test with XP but don't recall having this issue with XP, but it would be good to try the method I outlined
You'd need to add the tools,
I'm unsure how to reply to mattcampbell.
I run a 10.7.2 server that is an OD Master (admittedly started as a 10.5 server and updated throughout all the point updates and 10.6 and *those* point updates, etc...) My DNS is controlled by a central authority, but both server and clients (Mac and Windows) have valid DNS (forward and reverse).
But I have no problems at all having any of my Windows clients (XP or Windows 7) connect to my share points on the server using their OD Master account credentials. The only "problem" -- which can be resolved on the Windows end -- would be if the user logs into Windows using the same account name as their OD account -- but with a different password. Windows will try to "pass-through" the *Windows* credentials and if those don't match, the you get the error box about how you can't connect to the server -- this is resolved (in Windows 7) by putting the OD credentials in the "Credentials Manager" control panel.
(I have other SMB-related bugs reported to Apple, but *connecting* is not a problem once SMB is up and running...)
Are you having a problem with *Mac* SMB connections? Or just Windows connections?
It's not a matterof Apple not liking the license, it is the matter of the SAMBA license being changed for from GPLv2 to GPLv3 as of SAMB 3.2.0. Apple had a choice, keep using SAMBA 3.0.x version, or write their own. GPLv3 makes it impossible to provide signed binaries without also providing the signing keys. A few seconds of thought will reveal why Apple is unwilling to provide copies of the keys they use to sign system software. Part of locking down OS X security profile required removing anythign that used GPLv3.
Short version: GPLv3 is specifially desinged to be anti-company, and you are going to see a ever widening schism in the FSS/OSS community between GPL and all the other licenses, and you will be seeing less and less GPL code in commercial OSes and more BSD/Apache/&c code.
This is exactly what GPL wants, and exactly what GPLv3 is intended to do. I am not confident that it will really work out for them in the long run, but only time will tell.