Sure enough, the technician confirmed that the date was December 31, 1969. I needed to verify the clock on one of the affected machines. The clock! Well, That Was Obvious In Hindsight
#Set up a deploystudio server mac os x
Linux cifs mount with ntlmssp against an Mac OS X (Yosemiteġ0.10.5) share fails in case the clocks differ more than +/-2h: Googling got me to one specific hint, which is what gave the solution away: Kdc: ok user=F5KP60PFF9VN\username proto=ntlmv2 This seems to be the key indicator of success:
#Set up a deploystudio server code
a failure.įeb 1 14:50:58 digest-service: digest-request: init requestįeb 1 14:50:59 digest-service: digest-request: init return domain: FACEBOOK server: F5KP60PFF9VN indomain was: įeb 1 14:50:59 digest-service: digest-request: uid=0įeb 1 14:50:59 digest-service: digest-request netr: failed user=FACEBOOK\username DC status code c000006dįeb 1 14:50:59 digest-service: digest-request: netr failed with -1073741715 proto=ntlmv2įeb 1 14:50:59 digest-service: digest-request: od failed with 2 proto=ntlmv2įeb 1 14:50:59 digest-service: digest-request: user=FACEBOOK\usernameįeb 1 14:50:59 digest-service: digest-request kdc: ok user=F5KP60PFF9VN\username 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 Once we’ve got logging enabled, let’s look very carefully at a success vs. On 10.11, it’s a bit more work – your best bet would be to disable Apple’s launchd for SMB, make a copy of it with a different identifier, and load that (hat tip to in MacAdmins Slack for this). On 10.10, the above link is an easy solution – just unload the SMB launchd, edit the plist to add in the -debug and -stdout options, reload on the launchd, and watch the system log. Hat tip to Rich Trouton for helpfully pointing me to this link: We need more data to determine what’s happening, and part of that is figuring out the difference between successful SMB authentications and failed ones. Why are 60% of these clients failing to mount the share, but 40% still working? Spanning tree set up between ports to carefully monitor traffic. No firewall, no network ACLs, no change in VLAN, no weird stuff. Telnet test from broken client to server on SMB port. Okay, just in case, let’s try rebuilding the NBI using DS Assistant. We approach Hour 3 of All Aboard The Fail Boat. So at this point, we know the SMB share works on some clients, fails on other clients, but is otherwise configured correctly on the server.
Well, gee, that’s both good news and disconcerting news, because if the share works fine on other clients, why are these DS clients not mounting it? Let’s try mounting the share directly on another client: Just for kicks, let’s try restarting the DS service.ĭid that work? Nope. That’s simple enough to do in the System Preferences’ DeployStudio pane, which will show the status of the service and the address of the DS repository it’s offering. Simplest thing: check the server to make sure SMB is running and that DS knows about it. What we know at this point: DS Runtime can’t mount the SMB repo share. I’m doing all this relayed through messages to the local field technicians. I’m troubleshooting this remotely, so I don’t have physical access to these machines. There’s nothing really useful in the log about why it failed, or how, either. 0 or 1 seconds, this will result in an instant reboot without you being able to troubleshoot the environment at all. If your trigger is an unforgiving number, i.e. It also doesn’t give you very useful information about what happens, because the repository access error triggers the “timeout until restart” countdown. The story starts with a simple premise: my NetBoot clients would start up DeployStudio Runtime, but then would throw a repository access error when trying to mount the DS repository (which I have configured to be served via SMB):ĭeployStudio doesn’t like when this happens. For those of you who haven’t moved on to Imagr yet, this sad story about troubleshooting DeployStudio may encourage you to hop onto the gravy train and off the failboat. DeployStudio is an old hat classic ’round these parts, and many Mac admins are familiar with its foibles and idiosyncrasies.
0 kommentar(er)
