Hey hive mind, I'm hoping someone out there has run into a similar issue as mine and might have some suggestions to offer.
I'd say about 1 in every 3 attempts to image a machine there will be at least one package that fails, citing a permissions issue. Something like this:
Installing OSX 140726 10.9.4 20140731... Error: The file osx_updated_140726-10.9.4-13E28.hfs.dmg could not be opened. Please verify the permissions.
It's never the same package; they seem to be totally random. We use a clustered JSS with two JDS instances (a parent and a child) and upload all packages through Casper Admin. Usually it's a random app, like our customized App Store/Self Service, which isn't a big deal to push out later. But when the OS dmg fails it wastes a bunch of my time and is pretty frustrating. In any event…
Has anyone else run into similar issues like this before? We just boot to a USB disk for Imaging, so nothing fancy here. I can't imagine that I need to go into the CasperShareDAV and adjust permissions manually, but if I have to, I will. But shouldn't that be taken care of when I upload? And why does it pick different apps each time to crap out? Maybe the permissions error is a generic one?
Any input is appreciated, thanks!
Apologies for poking an old thread back to the top again, but as I’ve seen several customers in recent weeks with this exact same behavior we’ve gone ahead and opened a defect for said behavior as there doesn’t seem to be an easy fix or common cause that’s doing it.
For reference, the defect ID is D-007690.
Some things I noticed while troubleshooting a couple of these recently:
- It was always a DMG file.
- The DMG files in question appeared to have correct permissions and ownership on the JDS; they also worked for multiple computers and failed for others with no outwardly apparent rhyme or reason to it.
- When it was a PKG file, it was a legitimate permissions issue, and re-propagating permissions fixed it.
- Re-creating the DMG file did not work long term, sometimes it had no effect at all.
- Re-packaging as a PKG did work, but that’s cumbersome, kind of a pain, and not really viable for most customers, especially if there are a lot of DMG files to go through.
- This happens with both Netboot imaging and TMI imaging.
- We’re not yet sure if the Python script for OS X JDSes ( https://jamfnation.jamfsoftware.com/article.html?id=369 ) has an affect on it; one customer I’m working with has been asked if he could please try it on one or two of his JDSes to see if it makes a difference. The script creates an AFP share with symlinks to the files on the actual JDS and essentially tricks imaging into thinking it’s hitting an AFP share instead of a WebDAV share.
- We do not see the same issues when using an AFP share, an SMB share, or an HTTP share for imaging, it appears specific to using a JDS.
If you hadn’t talked to your Technical Account Manager back in August about this, or are still experiencing it, please get in touch with them if you have time; the defect has some pretty lengthy notes of things to take a look at to help rule out known issues or environmental issues that could be causing it and the more information we have from varied environments, the more helpful it is both for troubleshooting in your own environment and helping our development and QA people narrow down what might be going on to cause the issues with seemingly random ‘permissions’ errors on DMG files when using a JDS to image.
JAMF Software Support
Whoa! Yes! We're still experiencing this problem, but it's so intermittent that we've developed some workarounds and just figured we would get to it later. Thank you for responding.
We are not using that Python script. We are only using a single JDS at this point.
I will contact our Technical Account Manager on Monday.
Have just started noticing this issue appearing as we are trying to image 100+ machines for the start of the new year. As above, various .dmgs are randomly error-ing (mostly printer drivers in our case), but not on every instance! Have been using only a single JDS to date.
UPDATE: Have just been contacted by JAMF Software Support and have been advised this bug was fixed in v9.62 (we've been running 9.61). Will update to v9.63 and hopefully will resolve the issue.
Thanks for the great support JAMF!!
@gshackney I'm seeing this occasionally as well, albeit not for at least a week now. It's only happened to a couple of our .dmg files thus far with 10.10.4 and Casper Suite 9.73. We are not using JDS either.
What's especially frustrating is because when only one item fails during imaging, the computer is not seen as completing enrollment successfully and as a result does not activate the enrollment trigger for our enrollment complete policies.
My Casper share has the correct permissions, however its completely random if something fails or not (albeit its almost always a package that was recently created). Sometimes the imaging completes normally, but other times like @aporlebeke is saying, if one item fails then it sometimes won't correctly enroll.
I really hate this time of year and making this system work again with work arounds for each problem update. I understand its part of the job, but all the time I just keep wishing this would "just work" on the 1st try.
Sorry to be so negative too, just frustrated.
Princeton Public Schools
We have also seen this behavior with several of our customers this summer, and we can confirm that it has nothing to do with permission on the CasperShare, in spite of what the error message claims. We've seen it across multiple JSS's and distribution point models, and the only consistent culprit is Casper Imaging itself.
In the past we've seen issues with the Casper Imaging app's own latency tolerance being, well, intolerant. My guess is that small delays in accessing these network resources are causing Casper Imaging to give up and move on to the next package, which would explain why the behavior is random/erratic.
Thanks for the info @floatingorchard. This is our first go around with Casper and knowing that it's not just us or our unique environment is comforting at least.
Our account rep is suggesting we try creating a Netboot set running 10.10.3 instead of our current 10.10.4, but I don't have a 10.10.3 or 10.10.0 (to combo update to 10.10.3) install image to use.
Anyone have access to either 10.10.0 or 10.10.3 digital install?
SO. I just finished creating a new Netboot set that has Casper Imaging 9.73. Apple JUST released 10.10.5, so I ended up using that for the Netboot OS. Our old Netboot set which we were experiencing the .dmg permission issues with was running Casper Imaging 9.72 and 10.10.4, so we wanted to rule out the older Imaging version as the culprit.
After imaging several machines last night and this morning with the new Netboot set, I can confirm I have yet to see the permission issue occur during imaging.
I sincerely hope I've just not been really lucky and that this has actually resolved the issue for us. I'll let everyone know in the event it does happen again. But given it was happening almost every other image, I'm optimistic.
@gshackney That was originally how we were going to do it. But for whatever reason, Composer was not building our Base OS image with our preinstalled software (Flash, Java, iWork, etc.) correctly, and consequently would fail to Block Copy and instead install like any other package, which took a lot longer.
I was in the process of troubleshooting the issue with an imaging specialist, but it got so late in August that I didn't have time to continue troubleshooting because we needed to start imaging. And then I started running into this permissions issue more and more because we were going fully modular with a whole laundry list of things to install.
Thankfully, Apple's 10.10.5 release with Casper Imaging 9.73 and our Netboot has working marvelously. I've imaged a bunch computers today and NONE of them have run into this .dmg permission issue at any point.
@dferrara Are you by chance using smart imaging configurations?
I discovered that in a couple cases I had duplicated packages in both the parent configuration and one of the smart configurations based on the parent. This duplication was what was causing the issue for us (after much head banging against the wall).
Hopefully this resolves this for you.
@dferrara We are completely virtualized.
We are hosting on a Nutanix box on prem:
version .................... 5.5.52-0ubuntu0.12.04.1 version_comment (Ubuntu) version_compile_machine .... x86_64 version_compile_os debian-linux-gnu
VM Platform: VMware vCenter
DP: File share (SMB) hosted on same instance of JSS
40Gbps backbone to Core, Imaging from 10Gbps Switch