"Please verify the permissions." error during Imaging

emily
Valued Contributor III
Valued Contributor III

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!

24 REPLIES 24

lynnp
New Contributor

We've been having this same problem as well. We only have a single JDS and it happens intermittently with entirely different packages. Seems pretty strange...

were_wulff
Valued Contributor II

@emilykausalik @lynnp

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.

Thanks!
Amanda Wulff
JAMF Software Support

lynnp
New Contributor

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.

AlanSmith
Contributor

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!!

GabeShack
Valued Contributor III

Just had this issue using 10.10.4 netboot and Casper Imaging 9.73 with random packages/dmg's.

Apparently this is not resolved. Also we are not using a JDS.

Anyone else still seeing this?

Gabe Shackney
Princeton Public Schools

Gabe Shackney
Princeton Public Schools

bentoms
Honored Contributor III
Honored Contributor III

@gshackney I've not seen it. But can you verify the permissions on your CasperShare?

apizz
Valued Contributor

@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.

GabeShack
Valued Contributor III

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.

Gabe Shackney
Princeton Public Schools

Gabe Shackney
Princeton Public Schools

floatingorchard
New Contributor II

@emilykausalik @amanda.wulff

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.

apizz
Valued Contributor

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?

apizz
Valued Contributor

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.

GabeShack
Valued Contributor III

My way of avoiding this was to just compile the image so as not to see any permission errors with individual packages. Has been working every time. (I'm sure I just jinxed myself though).

Gabe Shackney
Princeton Public Schools

Gabe Shackney
Princeton Public Schools

apizz
Valued Contributor

@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.

krusea
New Contributor II

We just updated to 9.82. With a 10.10.5 netboot and Casper Imaging 9.82 we're getting the "Please verify the permissions." error on some dmg's. With a 10.9.5 netboot and Casper Imaging 9.65 we're not getting errors.

dferrara
Contributor II

Hi @emily,

Did you ever get any resolution on this? I'm running 9.93 with 10.11.6 NetBoot and packages are failing to install at random. Permissions on the share seem fine.

apizz
Valued Contributor

@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
Contributor II

Thanks for the tip @aporlebeke! I just have a normal config with 30 or so packages. It's also super random, out of 19 computers I had 5 fail I think, different packages each time. I get that some failures are inevitable, but if this happened before I never noticed it.

bentoms
Honored Contributor III
Honored Contributor III

@dferrara Multiple Casper DP's?

dferrara
Contributor II

Hey @bentoms, just a single DP. We recently virtualized but so far it seems unrelated. Working with JAMF support as we speak.

TJ_Edgerly
New Contributor III

Any one else have an update. I'm using a 10.12.1 NBI with JSS 9.96. Only DMG's are failing. If i go back to a previous NBI (10.11.5)...then things install fine.

dferrara
Contributor II

Hi @TJ.Edgerly,

Do you mind sharing the details of your DP? Are you virtualized, how many clients, what VM platform, etc.?

TJ_Edgerly
New Contributor III

@dferrara We are completely virtualized.

We are hosting on a Nutanix box on prem:
[https://www.nutanix.com/products/hardware-platforms/
](link URL)

OS: Linux

version .................... 5.5.52-0ubuntu0.12.04.1 version_comment (Ubuntu) version_compile_machine .... x86_64 version_compile_os debian-linux-gnu

Clients: <1300

VM Platform: VMware vCenter

DP: File share (SMB) hosted on same instance of JSS

40Gbps backbone to Core, Imaging from 10Gbps Switch

russeller
Contributor III

10Gpbs switches you say? You don't work in education. 01b33929657c448eb4a23728c5e96035

EDIT: I work in education, we have some 10Gpbs switches, just not out in the schools and classrooms.

dferrara
Contributor II

Our problem has been resolved! We switched the DP to a Windows host.