I woke up this morning and couldn’t get onto my CIFS share. A quick look at /var/adm/messages and I saw this problem:
Jun 15 23:10:10 zed idmap: [ID 702911 auth.notice] GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Clock skew too great)
Ok so this is because the clock on this machine is not close enough to the clock on my domain controller. I’ll just do a ‘crontab -e’ and plug this in:
# Sync date/time with my domain controller
15 * * * * /usr/sbin/ntpdate your.domain.controller.com
Now it should stay synchronized. But wait, I still can’t access my shares.
# svcadm disable idmap
# svcadm disable smb/server
# svcadm enable -r idmap
# svcadm enable -r smb/server
That didn’t do it.
# smbadm list
…and proceeds to hang.
# smbadm join -w WORKGROUP
# smbadm join -u domainuser mydomain
/var/adm/messages shows: svc.startd: [ID 122153 daemon.warning] svc:/network/smb/server:default: Method or service exit timed out. Killing contract 70.
Also noticed despite disabling the smb/server, the process still appears to be running. Kill -9 does nothing.
I had experienced a similar issue earlier during setup and I had written it off. It’s looking like the stability of CIFS isn’t so rocksolid. This post on the cifs-discuss list definitely shows I’m not the only one having issues.
I’m tempted to use VirtualBox and run virtual Win2k3 server on top of OpenSolaris. I would create an iSCSI target in my zpool and point the Win2k3 box at that. Let windows seamlessly share files which it is good at and OpenSolaris manage the storage which it is good at. It’s an interesting thought, but I’m going to see if the latest SXCE fixes my CIFS woes first.