Single client unable to mount SMB Distribution Point

[powellbc]

I have a single 10.10.2/Casper 9.63 client which can enroll without issue, but cannot mount the SMB DP. I realize there are many other threads about this but I did not see anything describing this particular scenario. Here is what I know:

• I tried removing any potential hidden share using rm -rf command to no avail.
• I cannot mount the share directly using any account on this computer. No issues on other clients tested.
• The logs say nothing more than "Could not mount distribution point."
• The client says other machines in the area have no issues. He plugged this machine into a data jack that was working and it still failed.
• I queried the DB directly to make sure there was not another machine with this name or any other weirdness but did not see any.
• Port scan shows 139 is open to the server.
• Regarding the setup, Client is 10.10.2, JSS/client is 9.63, JSS is hosted on Windows Server 2012 R2.

Any ideas? It seems like it would be network related but none of the evidence backs that up. The machine has been re-imaged 2 times now and still showing symptoms.

[elund]

In System Preferences/Network, do they have custom DNS servers entered?

[RobertHammen]

If you do a klist from Terminal (or use Ticket Viewer) before trying to mount the share, perhaps there is a Kerberos ticket, so when it attempts to mount the share, it's doing so as the user, not the read-only service account you may have created.

Could use kdestroy from the command line, then try to mount it, just to see if that's the issue.

[PeterClarke]

The simplest cause for this would be
-- if the machine was NOT enrolled with the server.. (to begin with…)
– or had otherwise become disconnected from the JSS…

eg: The machine CAN be: "In the JSS" AND "NOT in the JSS"…
For example: if the machine had been re-imaged - and Casper Client NOT re-installed
Then the JSS Record would refer to the "Old Machine"
- while the "New Machine" would not actually be connected…

Also how about the system clock ? - are you allowing non-time sync ?
is the clock time synched ( would normally cause login issues if not )

How about their network connection - is that OK ? / DNS / DHCP etc…

I would be inclined to try re-enrolling the computer - to make sure that was OK.

i.e.: "Validate the basics" first…

[powellbc]

@elund: Nothing configured out of the ordinary. I can pull up the JSS without issue and the name resolves correctly.

@RobertHammen: I will verify this when I get some more hands on time.

@PeterClarke: I have removed the framework and re-enrolled it from scratch (verified new ID in the JSS) and it has not helped.

The error when attempting to mount the share directly in Finder says something about the account nor being authorized. I suspected it was the computer account, not the user causing the issue. The machine is joined to the AD but when I unjoined it I am getting the same error. I need to dig into the system logs some more. This is definitely a weird one.

[powellbc]

In the JSS log I am seeing the errors described in this thread for the client in question ("Error Processing request tomcat errors in JSS"): https://jamfnation.jamfsoftware.com/discussion.html?id=12161.

I wonder if there is a duplicate object that is confusing the JSS in the database but I am unclear on how to track that down. UDID is now the primary identifier, correct?

[powellbc]

It definitely seems kerberos or kerberos related due to some of the errors I see in the SMB logs, but I am not seeing any response from klist. I ran kdestroy to be sure and still cannot connect. I'm at a complete loss. It's just this one machine.

This is what the SMBServer log says:

Status: The remote user session has been deleted. (0xC0000203) Guidance: You should expect this error when attempting to connect to shares using incorrect credentials. This error does not always indicate a problem with authorization, but mainly authentication. It is more common with non-Windows clients. This error can occur when using incorrect usernames and passwords with NTLM, mismatched LmCompatibility settings between client and server, duplicate Kerberos service principal names, incorrect Kerberos ticket-granting service tickets, or Guest accounts without Guest access enabled

The only workaround I have found is to force SMB1 connections, but it still begs the question of why this one specific client? A separate machine of the same vintage and OS does not do this.

[RobertHammen]

can you try deleting /var/db/dslocal/nodes/Default/computers/localhost.plist

then copy /System/Library/DirectoryServices/DefaultLocalDB/Default/computers/localhost.plist to /var/db/dslocal/nodes/Default/computers/

Restart, log in as a local admin user, then

sudo dscl . -create Computers/localhost kerberosServices host afpserver cifs vnc

Restart one more time for good measure.

Now are you able to log in? I've seen the localhost.plist being messed up causing all manner of Kerberos (and 802.1x) authentication issues...

--Robert