Casper Admin cant mount share for replication

[rmaldon]

Hey guys,

Ive been wrestling with this one for awhile. We just moved from 9.63 to 9.72, and ever since then have been unable to replicate to our other share via Casper Admin. It just cant mount the share. Its been working(for the most part) since we stood up everything but now fails consistently.

The error I get is this, and when I check the logs in the location specified, you can see there really isn't anything helpful to troubleshoot the problem.

The strange part is that, it IS actually mounting the share! I verified this by running a "df" command from terminal I can see the share is indeed actually mounted. Ive tried unmounting, restarting, re-adding it, checking the read/write accounts, resetting passwords, and a host of other recommendations on different forums here on JAMF nation but none have been successful.

The other odd thing is this will even happen with the master distribution point time to time for no reason I can plainly see. I usually will have to close and reopen Admin a few times, and unmount the share manually before it will work again.

This has happened in the past intermittently, but now, it seems to have become a constant and Im running out of ideas. Figured I'd see if anyone else is having issues like this or maybe some recommendations?

Thanks all

[alexjdale · Accepted solution]

We started seeing this issue with our new 9.72 server. Turned out that populating the "workgroup or domain" field was what caused it. We blanked that out and it works fine so far.

We are in fact using AD accounts to mount the SMB shares, but I don't know what that field is even for.

Edit: Well, this fixed it for Casper Admin, but now Self Service fails to detect that the DP mounted correctly. I can see it mount for a split second in /Volumes but then it unmounts.

[bentoms]

@rmaldon i've fun when mounting a CasperShare which is on a host bound to the domain & has limited access for domain accounts.

Could something like that be an issue?

[rmaldon]

@bentoms I dont think so... I lost you a little bit with that comment, but I think I understood what you were asking.

After testing some more, I switched our Master over to the share I was having trouble replicating to, and it mounted just fine. So it looks like there is some issue specifically with the replication piece of Casper Admin to the secondary share.

Just more confused now :(

[rmaldon]

actually just found a forum thread with the same issue... https://jamfnation.jamfsoftware.com/discussion.html?id=14189.

Looks like there is a possibility of an application issue?

I will probably just look into replication with a power shell script for the future, but would be nice to figure out if this is an issue with Casper Admin 9.7 + for peace of mind.

[cbrewer]

Talk to your account rep. There's a known defect in 9.72 involving Casper admin replication and smb. In our case we are also using ad accounts for the read and write privs.

[Look]

It's a bug in how Casper Admin determines if the share is mounted.
If you open /Volumes you will see the share successfully mount and then see it attempt to mount a second time and fail (the logs show it thinks it failed the first time).
Work around is pretty simple as long as you don't have too many points.

Open /Volumes
Attempt to replicate a single DP
Wait till it fails
Unmount that DP again 
Immediately try again and it will succeed
Repeat for all DP's

Paintful but it works. I have no idea why it successfully works the second time round, but it does...
We have a suport ticket open with JAMF for it but considering it looks like something in the Admin package itself I think it will need a new version to fix.
I have no idea if the DP makes a difference to the scenario but we are AD bound and on Windows.

[scottb]

@rmaldon,

Some things we did in 9.65 to help fix this. Not sure which have been addressed in 9.72, but here they are:

What @Look said is true, you would see many "CasperShare" volumes under /Volumes when this happens.

1. We took out all special characters in our Admin and Install passwords.
2. We changed our DP's to IP addresses in lieu of DNS names.
3. Others have had issues with the CasperShare not being on the root of the server.
4. Others have had spaces in the path of the share and removed those.

Have a shot at those things and it might help you until/if JAMF fixes them.

[sprattp]

Hi, also have the same problem, with a DP that uses Domain authentication, but not on others that have local accounts. I also find that if i replicate the DP seperately it will work after the second attempt, i also have found that i get better results if i don't use Yosemite.

[Chris_Hafner]

A bit more I'll add to the mix here. I've seen various issues in replicating to varied versions of SMB when the package comparison is based on file size. Mostly because of block size or SMB version differences on different servers. I moved to checksum based comparisons a long time ago to solve this even though I tend to still use AFP. Regardless, just food for thought.

[alexjdale · Accepted solution]

We started seeing this issue with our new 9.72 server. Turned out that populating the "workgroup or domain" field was what caused it. We blanked that out and it works fine so far.

We are in fact using AD accounts to mount the SMB shares, but I don't know what that field is even for.

Edit: Well, this fixed it for Casper Admin, but now Self Service fails to detect that the DP mounted correctly. I can see it mount for a split second in /Volumes but then it unmounts.

[jreinstedler · Accepted solution]

@alexjdale Removing workgroup/domain fixed it for me. Self-Service is still working normally from what I can see. We're still on 9.70 though... will probably hold off on .71 or .72

[rmaldon]

@alexjdale This fixed it for me... wow. I've been working with my JAMF rep and will communicate this back to him. We have been going through a bunch of troubleshooting and the next step was to try changing the password to not include special characters.

---

Just to clarify:

- Using Casper 9.72
- We use AD accounts for our Casper shares
- they DO contain special characters

These are some of the attempted troubleshooting steps I took:

Option1: - Open /Volumes - Attempt to replicate a single DP - Wait till it fails - Unmount that DP again - Immediately try again

Option 2: - Use this script before Opening Casper Admin 1) Script to remove Kerberos ticket (replace "SMHS-CasperReadOnly" with whatever the Read Only account for the share is. Example: "CasperRead")

#!/bin/bash

user="SMHS-CasperReadOnly"  
userKRBticket=`klist | grep $user | awk -F" " '{print $2}’`  

if [ ! -z $userKRBticket ]; then 
kdestroy -p $userKRBticket 

fi

Option 3: - Change to checksum based comparisons for packages

---

The option that did fix my issue is marked here in the thread. I just wanted to post what I tried here along with other peoples answers to help build a central thread with troubleshooting ideas for anyone trying to work the same issue. :)

Thanks for all the ideas guys

[scottb]

You guys that are removing the "workgroup or domain" - what kind of servers are your JSS running on?
Seems like an odd fix, but then many of them are...

[rmaldon]

@scottb ours is on* Windows 2008 r2

[scottb]

@rmaldon - Thank you, same here. But I still have mine populated and working OK.

I honestly think at this point I would as a matter of course, remove special characters from the JSS passwords. That and the IP vs DNS changed fixed most of our issues, but we're still riding out 9.65.

[jescala]

I just ran into this problem this week. Is there any reason why we can't use rsync to sync the distribution points until JAMF releases a fix to Casper Admin? Some folks reported success with this here:

https://jamfnation.jamfsoftware.com/featureRequest.html?id=824

[nessts]

being a unix guy at heart I have only ever used rsync to synchronize shares, when on linux and os x servers. windows servers offer a different set of headaches, that I still struggle with, but I have seen people getting around it I just have not had time to figure it out myself.

[scottb]

@jescala I use rsync to do the syncs to my Windows DP's instead of using Admin as it copies from Master to Mac, then to the other DP, which at least doubles the time it takes as opposed to using rsync - @nessts made me do it to better learn the CL. :)
The reason I do it is that we have global DP's on often slow connections and the double-load of Admin makes xferring large files ridiculously slow.

If I have something small, I go into Admin and select all the DP's, then replicate as it seems to work OK.
If I had just one or two local DP's, I'd probably be lazy and just use Admin - assuming it's working at the time...

[jescala]

@nessts and @scottb, thanks for your responses! All our servers are Linux so that's not a problem for us, but I believe robocopy should do the trick with Windows. I'm not sure what works best when you're in a mixed environment. I think I would just mount an SMB share on a Linux server and use rsync all the same. I'm testing rsync now with ssh keys using with this syntax:

rsync -av --delete [source_path] [username]@[server]:[destination_path]

[scottb]

@jescala - We were told Robocopy was flaky by some Wintel server guys. I know little about Windows, so I defer to them, but I'm open to finding something more automated down the road for sure.

We use something like this:

rsync -av --progress --inplace /Volumes/CasperShare/  /Volumes/CasperShare-1

[cshepp11]

For what it's worth...I have also had the same issue with 9.72. Removing workgroup/domain fixed it for me in the File Share Distribution Points settings. Self-Service is still working normally from what I can see too.

[scottb]

A few guys have fixed things by removing workgroup/domain. I'm hesitant to even try it, but it is odd that learning the field has worked.
We have AD accounts for both CasperAdmin & CasperInstall... might have to just try it and see what happens next upgrade.

[NightFlight]

Casper admin 9.80/9.81 has the same issue with my replicas on 10.11. It mounts the master fine, but will never mount a replica. Throws the error there was an SMB mount failure, which is stated again with the same amount of detail in the log.

rsync really is the way to go. I don't know why they don't use it.

[scottb]

@NightFlight - wonder if there is a feature request for such a thing? Have to search as that would seem to be a really good idea..

Edit: This sorta covers that...

[coreythomas]

Thanks @scottb !

We had a similar issue and changing from FQDN to IP solved the mount issue. I'm assuming because we are on a .local domain.

Like others, we are also seeing the double mount and failure from time to time. If we open up /volumes, drop the mount, and relaunch Admin, it works.