Wondering if anyone has seen this behavior before. For context, we are on version 9.81, with our primary distribution server on a Windows 2008 R2 server, and a Mac Mini with OSX server on our local distribution point. We are using SMB shares on both and have validated the credentials by mapping a drive from another machine to be sure.
From self service, if we install an app it goes through OK, but then if one tries to install another app (still have the self service app open), we'll get an error... "Error: Could not mount distribution point" back to the primary. If I look in /Volumes I do see a mount there and I can browse it. It almost seems as though the mount isn't getting released after the previous install.
This is odd and I've sent hours trying to make heads or tails of it.
Anyone else had this problem? If so, did you find a solution? Thanks in advance!
email@example.com or firstname.lastname@example.org (both work)
I had constant issues with SMB mounts. I eventually created a policy which would unmount the volume (disktutil unmount /Volumes/share) on all computers a couple times a day. Fortunately, if the volume was in use, the unmount would fail. For others, it would fix self service. I've finally switched to http distribution points. Much better way of doing things....
@kbeattie - when you try to run subsequent installs, what does this show:
If multiple CasperShares, then we pretty much "fixed" this a while back by changing the DP's (all Windows, all SMB) to use IP addresses and we also got rid of any special characters in the two Casper accounts (casperadmin and casperinstall).
Thanks all. We've been tracking down an issue that may be the same, and this gives me something else to check. Only a few machines, but on those we can occasionally get a package to install from SS, but then all subsequent packages will fail for several days, and all the logs are showing is a failure to mount the share. Hoping this may point is in the right direction.
Unfortunately, we're stuck with SMB for at least the time being, and corporate policy dictates complex passwords including special chars, but worst-case scenario, I can add a diskutil unmount command to the policy itself to force the unmount - I'll give it a try.
It sounds like the defect we ran into with 9.65+, still not resolved. Details: https://jamfnation.jamfsoftware.com/discussion.html?id=14233#responseChild89283
I wound up setting up HTTP DPs to work around it.