Could not mount distribution point

Usually when there is a "1" at the end, it means if you look on the machine in /Volumes, there already is a phantom share of the same name mounted.

Remove the old phantom share.
Disconnect from the Casper share in the machine that has the 1.

Go to terminal. Cd /Volumes/
ls -a

If you see a volume there called CasperShare and you aren't connected then it has a phantom. Remove it.

rm -rf /Volumes/casper_share

I have a phantom share when Casper Admin crashes, and I run this to unmount it.

umount /Volumes/casper_share

I have seen what you are seeing before, when we used a policy to call a different policy. We would get a false failure as the drive would be mounted already and it would run, but since it had the error in the logs it was reported as an error. Ended up not calling a policy in a policy and it resolved 99% of those errors.

I recall other JAMF Nation threads on this topic. If you do a search query of "could not mount distribution point", there is about 4-5 other threads that may help you.

Is moving to HTTP an option? It gets around this issue, gives you resumable downloads & stops the share appearing on the desktop.

try "refreshing" all of your distribution points in the JSS by clicking "edit" then "Save" for each DP. this reduced the number of "Error: Could not mount distribution point" error for me. I was also seeing an oddity where doing a ```
ls -la /Volumes/
``` while CasperShare was mounted caused terminal to take several minute to return a response. After the "refresh" this issue seemed to go away as well.

Changing from AFP to SMB in JSS server distribution point protocol solved this problem for us.

We had to switch to HTTPs sharing and abandon AFP/SMB all together... the trick I mentioned above did not last long-term. :(

How do you switch from AFP/SMB to HTTP? My distribution server is a 2008 Xserve running 10.7.5 and Server 1.4.x.

Apparently this is a known bug (D-008898) which is fixed in v9.73, released yesterday.

I can reproduce it in v9.72 and am planning to move to v9.73 shortly.

Unfortunately we seem to still be having this issue in 9.73. Our Mac Deployment Technician is currently in discussions with our technical manager contact at JAMF but I wondered if anyone else is still experiencing this?

Hi all! hi @josh-the-tech

I still have the problem "could not mount distribution point" with JSS 9.73. We are imaging ~300 machines and about 80% of them failed with that error.
I can manually force it by 1) flushing policy errors for a machine, 2) login on it and command umount /Volumes/CasperShare*, 3) sudo jamf policy

I cannot make it for hundreds of macs.
I tried to do that with Casper Remote and sometimes it works but most of the time it doesn't work.
Even a reboot of the machine doesn't solve the error.
I have a call opened at JAMF support. We tried to delete kerberos ticket for the read account of the distribution point without success. We also tried to add a command umount /Volumes/CasperShare* to a policy without success.

Hi all,

We could fix the "could not mount..." problem by renaming the share point of the distribution point and re-enabling the share on windows server.
Hope it helps!

Hi All,

Mostly a Windows SysAdmin here...

A workaround we're using to get around this is by naming the share names to match the DP its connecting to.

So instead of creating a share on the server called caspershare like below to mount
smb://jss-dp-pro-1.f.q.d.n/Caspershare

We setup the sharename to be the below
smb://jss-dp-pro-1.f.q.d.n/JSS-DP1-Share

Likewise for other DP's
smb://jss-dp-pro-2.f.q.d.n/JSS-DP2-Share

This way when clients are connecting to a DP, its always mapping to a unique sharename that matches the DP its connecting to...This also helps identify which DP your connecting to if your experience issues.

This also helps anyone using Casper Admin to sync DP's. As each mount point in /Volumes is unique....

Regards
Blake

Hi,

I am having this exact same issue. I ran the command that @pblake mentioned. Unfortunately I am a newbie to Mac and its scripting, I tested it on my Mac first and deleted the ENTIRE contents of our CasperShare! Oops. Is it worth mentioning something about the possibility of this using that command in the post @pblake ?

@HelpDeskWarrior Essentially, run every script in a test VM & really be careful with rm scripts.. we all learn the hardway but as long as it's only once you'll be fine.

The CasperShare should really be mounted client side with read only permissions with would have helped.

That's a bit of a problem. Did you have multiple distribution points? you can probably copy everything back from one of those. Or if you have a backup on that DP do a restore....

It's a shame that the post where you got that information from can't be edited because that's really just bad advice.

We had some backup issues but pretty much had the entire contents of the Casper Share across a few different shares...phew!

You should not run that when you connected to the share. You run it when you have verified there is one showing up in /Volumes/ in your machine when you haven't even connected.

I should have been more clear. I'll update my note.

Any updates on this?

We are having the same issue using Casper 9.91,

EL Capitan Version 10.11.4 (15E65)
Casper 9.91
JSS/Single distribution point - A Mac server which is dedicated to running Casper.

Self Service functions fail with an the error ‘Could not mount distribution point “XXXXX”’. I run Terminal and list mounted /Volumes, ‘caspershare’ is not mounted, before I run the self service function so it doesn’t appear to be a ‘ghost’ or hidden mounted caspershare.

The self service policy, should run a script to remove installed printers and delete/reset CUPS.
Then install a new driver for a Canon Fiery RIP
Then add 3 printers

I can push each of the steps through Casper Remote
Push Script through Casper Remote
then
install Canon Fiery driver through Casper Remote
and finally Install 3 printers through Casper Remote

Inevitably this does not fail on all Mac, and I can see no

[STEP 1 of 9]
Executing Policy Add XXX printers
[STEP 2 of 9]
Mounting xxxx to /Volumes/CasperShare...
Could not mount distribution point “xxxxx”
[STEP 3 of 9]
Mounting xxxxx to /Volumes/CasperShare...
Could not mount distribution point “xxxxx”
[STEP 4 of 9]
Deleting xxxXXXXX…
Stopping CUPS...
Deleting PPD...
Starting CUPS...
Stopping CUPS...
Mapping Printer xxxXXXXX...
Starting CUPS...
[STEP 5 of 9]
Deleting xxxYYYYY…
Stopping CUPS...
Deleting PPD...
Starting CUPS...
Stopping CUPS...
Mapping Printer xxxYYYYY...
Starting CUPS...
[STEP 6 of 9]
Deleting _XX_XXX_X_XXX…
Stopping CUPS...
Deleting PPD...
Starting CUPS...
Stopping CUPS...
Mapping Printer _XX_XXX_X_XXX...
Starting CUPS...
[STEP 7 of 9]
[STEP 8 of 9]
Inventory will be updated when all queued actions in Self Service are complete.
Flushing System Caches...
Flushing User Caches...
[STEP 9 of 9]

Cheers
Phil

@Phil same thing here using 9.91 and an on-prem JSS. Going to try renaming my Share, tried enabling smb over afp with no luck.

Having this same problem in 9.92. We had our JumpStart for OS X (we already were using Mobile Mgmt) and it worked fine during the setup process, however the day after our JumpStart we started getting this error.

We are using AFP. I tried moving the DP to a whole different NAS, different RW & R user accounts. No luck. Have an open support case right now for it, just waiting to hear back.

Everything else seems to be working such as Imaging and Self Services.

From my JAMF Buddy:

"There was an issue starting with version 9.9 where having a workgroup entered for the file share settings could cause issues if the file share server belongs to that same workgroup. Can we try going to the File Share Distribution Point settings in the JSS and clear out what's entered for the Workgroup field."

This worked for me.

Ran into the same problem, glad I found this thread, workaround fixed it.

https://jamfnation.jamfsoftware.com/discussion.html?id=20550

Server Name of server.domain.com and Workgroup of domain.com prevents SMB (Samba) shares from mounting. Clearing out Workgroup field fixes the issue.

PS, It would be great to have a Known Issues wiki, else this workaround might come back to bite is if and when the issue is resolved...I'd hate to run into more issues by having the Workgroup field cleared out.

Thanks,
Don

This might be helpful to anyone struggling with this issue, a summary from our ace JAMF Buddy:

What we ran into there was PI-002359 - Prior to 9.92, the "Workgroup or Domain" field when setting up an SMB distribution point was labeled "Workgroup or domain of the SMB server." Post 9.92, it's label has changed to "Workgroup or domain of the accounts that have read/write and read-only access to the share." If the Workgroup or Domain of the SMB server is not the same as the Workgroup or Domain of the read-write and read-only users, but we have that field populated, the binary won't be able to mount the drive due to some improvements to how the binary handles SMB shares.

Casper Suite Release Notes v9.82 Known Issues
Casper Suite Release Notes v9.9 Known Issues
Casper Suite Release Notes v9.91 Known Issues
Casper Suite Release Notes v9.92 Known Issues

(duplicate)