Creative Cloud Packaged packages Failing

New Contributor II

Hey All,
I'v started packaging the new Adobe CC apps using the Adobe Creative Cloud Packager. I'v tested each package locally and as a .pkg, they install fine. However, they seem to fail when trying to deploy via Casper Imaging, Self Service, or Remote. For various reasons I'm running SMB for the CasperShare and also for other various reasons I'm running JSS 8.7.3.
All my CS6 and previous packages created with AAMEE run just fine without a hitch.
I'v seen the solutions with wrapping the package in a DMG and deployed via script. Although this may work, its a bit convoluted for our environment- we have several teams that do deployments, and this method would inevitably cause more problems than it solves.
The real odd part is that is that a couple of the CCP packages do work; Acrobat 11, Photoshop, LightRoom, and Premiere will install fine. The others will not.
This behavior is the same on both Mavericks and Mountain Lion.
Any ideas?


New Contributor III

I had the same problem when our district just got Creative Cloud. One thing I had to do when I created my Adobe CC installers with the Creative Cloud Packager was change permissions on the contents in the package. I had to right click and show package contents. Once that was opened I right clicked on Contents and Get Info. I changed the permission for Everyone to Read and Write and I applied it to the enclosed items. Once I did that I was able to install packages that failed before. I tried to change permissions on the package to see if that would make a difference but it didn't work and I had to change it on the contents of the package.

Contributor II

FWIW - I have noticed that the .pkg created by CC packager DOES NOT take kindly to being zipped. Sice we store our non-casper deployed packages on non-HFS+ media I need to compress them somehow first. zipping has been that method up until recently. I had to store it in a .dmg before putting it on one of our servers.

Once I compressed as a dmg and not a .zip, it installed fine.

Esteemed Contributor II

+1 on DMG over ZIP


New Contributor II

OK, I may not know what the fix is, but I found the root cause..

Turns out that CCP PKGs, when copied to the CASPER SHARE via SMB, does not
copy fully.

The setup and payloads folders inside the PKG are either missing or
incomplete. Inside the PKG contents, there is a folder with an install app, packages folder, and payloads folder. In a PkKG copied via SMB, there is only an incomplete version of the

If I try to manually copy the package to the SMB share, I get an error:
'The finder can't complete the operation because some data in "<pkg name>"
can't be read or written" (Error code -36)

So something is funky with copying the file structure of the PKG to the
share via SMB.

I took a look at the original pkg created by CCP and one that was copied
via AFP, and both have all the files.

So that's the reason, why this happens I couldn't begin to say.

Release Candidate Programs Tester


I've seen that issue with SMB and Adobe packages before (in my case, it was CS packages built by AAMEE.) The packages don't want to completely copy over SMB due to the size of the installer. My repo communicates with clients via HTTP, so delivery to clients worked fine, but getting them up to the repo didn't work via Casper Admin and the SMB share provided by my Linux JSS.

What I wound up doing was connecting to the directory on my Linux server where my repo was hosted from, and copying the Adobe installers to the directory via SFTP.

After the copy process completed, the next time I launched Casper Admin, it gave me a message that the new AAMEE-built packages had been discovered and asked to build a bill of materials for them. Once Casper Admin completed that process, the installers were ready to go and could be deployed from the repo via HTTP.

New Contributor II

I'v actually never had a problem with previous CS packages made by AAMEE, but then again I wasn't using SMB at the time I created them. Since I moved to Mavericks Server, AFP has been less than reliable, so I switched to SMB.

In fact that's exactly what I'm doing now. Connect directly to the CasperShare independently from Casper Admin via AFP and uploading the PKGs that way. Once there, the SMB share doesn't seem to cause a problem for installation on clients.
Then updating the BOMs when Admin launches.

Its not a perfect solution but its getting the job done.


we were all mac servers converting to windows (JSS) and linux (JDS)
I tried to finder copy all my packages, DMG and .pkg's to the windows JSS as the main distribution point.
it was a HUGE struggle, I ended up zipping all of my .pkg's because I knew they would all fail if I didn't. It was time consuming but the olympics were on….right click compress….repeat. It probably could have been scripted. Once that was done I mounted my New windows Distribution point on my mac with all the packages…. From the mac I did a [rsync -avz source of packages windows share destination](rsync -avz source of packages windows share destination)

The package copy was more reliable and I didn't have to babysit the transfer.

Valued Contributor II

AAMEE-created packages will be broken when copied to an SMB share. Best to put it on a DMG and use the script here on JAMF Nation.

New Contributor

Very old thread I know, but I just caught the same issue trying to save up a created CC installer to my usual Installers SMB share.

I did a little digging and I see that there are some links within the packages. I don't believe SMB shares support links - or at least not those that are formatted NTFS behind the scenes.

$ pwd
~/Desktop/CC/Exceptions/AdobeHelp/Adobe AIR AIR.framework
$ ls -al
total 24
drwxr-xr-x@ 6 classtech  staff  204 Apr  6  2012 .
drwxr-xr-x@ 3 classtech  staff  102 Apr  6  2012 ..
lrwxr-xr-x@ 1 classtech  staff   26 Apr  6  2012 Adobe AIR -> Versions/Current/Adobe AIR
lrwxr-xr-x@ 1 classtech  staff   26 Apr  6  2012 Resources -> Versions/Current/Resources
drwxr-xr-x@ 4 classtech  staff  136 Apr  6  2012 Versions
-rw-r--r--@ 1 classtech  staff   10 Apr  6  2012 sentinel