I seem to be having an issue where once i have opened and closed Casper Admin, then try to open it again i get this message everytime. The only way i have found to resolve thi
s issue is to restart and open after restart. This issue happen alway after closing/quiting the program and opening it again. Please any information or assistance in this matter would be greatly appreciated.
Usually when I run across this, Admin either crashed, or the Casper share didnt unmount. When this happens again, open a terminal window and run the "df" command. Check to see if the casper share is still mounted, and if it us, you can unmount it with a "diskutil unmount /path/to/CasperShare".
That has fixed it for me every time.
I have seen this before. Depending on what version of Mac OS, the time of day, the color of the sky, your mood or the Mac's ... there are times when Finder will dismount the drive but if you look in terminal, you might see that it's still mounted.
What version of OS X and what version of Casper Admin are you using?
Use Console to look over the logs to see if there are any warnings that Casper Admin is not quitting properly or failed to unmount the drive. Also check over the Casper Admin Sync Log.log which is located under ~/Library/Logs for any hints concerning the issue.
This is the word I have from JAMF support this morning -
In Terminal, we can use 'sudo diskutil unmount /Volumes/CasperShare' where CasperShare is the name of the mounted share. This will unmount the drive if it is currently mounted. I know we are making a change in 9.73 to move from using the umount command, which Apple is deprecating, to using the diskutil unmount command to properly unmount the drives that the jamf binary mounts.
We could stick the "diskutil unmount /Volumes/CasperShare" command in the File and Processes Payload under Execute Command. If we add this payload to the existing policy to deploy a package, this will ensure that the drive is unmounted when the policy is finished.
Going to test the 2nd option, really going to be a pain to add to all our policies though 😞
command+shift+G (go to folder)
Right click and eject the Casper share.
Casper Admin should now open.
Not a solution but at least it's fast and you don't need to restart.
We have Windows file shares and this is a fairly persistent problem, it's not actually always Casper Admin failing to unmount, but rather a bug in how Casper determines whether the share is mounted or not, it mounts the share, fails to see it, attempts to mount it again which of course fails because it is mounted already.
The same thing occurs during replication with exactly the same process fixing it for each replication point.
Started about 2 or 3 versions of Casper Admin ago.
Self Service also can't seem to detect if the CasperShare is already mounted. If you look at logs for failures, many of them show "can't mount CasperShare-1" volume. So it appears that if say a daily recon is taking place while a user tries to use Self Service, it will fail and they don't have a clue as to why. It would be nice if the whole suite were better at seeing the mounted share and utizing it.
We have been seeing this issue a lot with Self Service, Casper Admin, and with policies that need to mount the Casper Share to install packages. We started seeing it somewhat randomly with Casper 9.63 and after upgrading to 9.72 it appears to be more consistent especially with Self Service. In our case it only appears to be an issue with SMB distribution shares. Luckily I hadn't disabled our old AFP share after moving to an SMB share and have worked around the issue by setting our AFP share as a failover distribution point. I can see in many policy logs (including Self Service) where it tries anywhere from 5 to 10 times on the SMB share, then fails over to the AFP share and usually mounts the first time.
@spalmer - when you say:
...after upgrading to 9.72 it appears to be more consistent especially with Self Service.
Does that mean it's better, or more consistently not mounting? Just updated to 9.72 today with a Win 2008 R2 server and all SMB shares, so far, no issues...but we took every precaution that I've found in threads by users and JAMF. I must say, I enjoy nothing less than updating the JSS on our Wintel boxes - especially since we have NO rights to do anything but install the apps. Can't even reboot without a call/case to the hosting team. This might be the first time I've managed to finish an upgrade in one day. But I dare not jinx that...
I have this error, even after clearing all the mounted volumes!
This is happening after I upgrade macos Sierra for piloting. I feel that if we upgrade casper server to latest (9.96), in order to use the lated casper suite admin tool, that will overcome this error 😐
I also like to confirm whether 9.81 admin works with Macos Sierra? as long as inventory execute, i see like casper suite enrollment works, only the admin tool. Even casper image and Casper remote tool works.