Adobe Acrobat install “learning opportunity”

Warning: this post has a lot of technical detail, in the hopes that it can help anyone else who had this problem!

We had a huge “learning opportunity” at home this weekend. For the past month we’ve been trying to install Adobe Creative Suite onto one of our MacBook Pros. We picked up a copy of CS 5.5 right before CS6 was released, and Adobe had a deal that included a free upgrade to CS6. CS5.5 kept gakking during the installation of Acrobat Pro. The installer log file wasn’t particularly helpful:

Installer: The install failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)

[       1] Sat May  5 20:34:09 2012 ERROR
DW006: Apple Package failed to install successfully.

DW050: The following payload errors were found during install:
DW050:  – Acrobat Professional: Install failed

———– Payload: {AC76BA86-1033-F400-7760-000000000005} Acrobat Professional 10.0.0.0 ———–
ERROR: DW006: Apple Package failed to install successfully.

ERROR: DW050: The following payload errors were found during install:
ERROR: DW050:  – Acrobat Professional: Install failed

Web searches turned up nothing helpful. We tried uninstalling all Adobe products and deleting all traces of it using their “cleaner” program, and we tried enabling the root user (and creating a “root” account to install from). None of these worked, and we wondered if it was just a 5.5 bug so we waited for CS6 to ship. We finally got our serial number last week, but CS6 had the same installation error!!

While running yet another installation attempt yesterday, we noticed the installer had a live log file that got updated during the installation, so we had a peek in there and voila! We found the source of the problem!! The live log had dozens of sudo errors during pre-install scripts, which suggested there was some kind of permissions problem lurking.

We tried a couple of sudo commands at the terminal window and got a sudoers permission error. Google led us to this discussion forum which implicated the group permissions on the root (/), private (/private), and etc (/private/etc) directories. When we checked (use these commands)

  • cd /
  • ls -al

private and etc had the correct permissions (group could read and execute), but the root folder (the one at the top called . ) did not. A call to

chmod g+rx

failed, but then we noticed that the root folder had an @ symbol at the end of the permissions list:

drwxr–r–@   38 root   wheel      1360 Jun 18 21:35 .

I’d never heard of that, so a bit more googling turned up some invention of “extended attributes“.

ls -ale

informed us that the root folder had an extended attribute of

com.apple.quarantine: blahblahblah safari blah blah

(this attribute is related to that OSX warning message that pops up when you click on a program you’ve downloaded from the web. It says “this program was downloaded from the internet on xxxx, are you sure you want to continue?”)

We tried to delete the attribute (they can interfere with chmod commands) using

xattr -d com.apple.quarantine .

but THIS failed with

Errno 13 permissions error

At some point we had disabled the root user (reasoning that 95% of Apple users had never heard of root and never enabled it to begin with and Adobe installs fine for them). So we re-enabled root:

  • go the Finder
  • type command-shift-G
  • type in System/Library/CoreServices
  • open up directory utilities
  • Under the File menu, choose “enable root”

Then we logged into a terminal as root (open a terminal window, type login root), and re-ran the xattr command. It worked, and we re-ran the chmod command. This also worked! We tried a couple of sudo commands and they worked fine! We rebooted the sytem and tried the Adobe installer and it ran without a hitch!!!!!

I didn’t bother tracking down how that extended attribute got attached to the root folder–by now we’d sunk dozens of people-hours over the last 6 weeks into this problem, and I was just glad we’d solved it. The moral of the story: if Adobe install fails, check whether you can run commands with sudo. If not, go debug that problem!!

We were curious about why all the other Adobe CS components installed fine–it was only Acrobat that gakked. My suspicion is that Acrobat is more deeply embedded in the system and linked to other programs (because it integrates with other programs to act like a printer….well, at least it does on Windows….Mac already has print to pdf even without Acrobat).

We were also irritated (there’s an understatement) that the post-fail log file is so worthless. It’s hundreds of lines long (see it here), and yet just has those few lines about a mysterious failure without any detail that would let us solve it!

Advertisements
Leave a comment

4 Comments

  1. Jeff

     /  October 11, 2012

    Thanks for posting this, but I have a question for you. You stated:
    “ls -ale
    informed us that the root folder had an extended attribute of
    com.apple.quarantine: blahblahblah safari blah blah”

    I’m trying to help someone else out with a very similar install issue (nothing to do with Adobe, though) and I believe what you posted could help. I’m not afraid of using Terminal, but I am far from fluent in command-line speak. 😉 I guess my question would be how did you make the jump to discovering a Safari item was the problem? I’m not seeing where the jump from the root folder to the attribute occurred. (I realize ls will list stuff, but ale does…?)

    Hope my question makes sense, thanks!

    Reply
    • The ls command lists the files. By adding the “flag” of -ale, it lists the files with the attributes. I just looked at the list for one that had the @ symbol, meaning it had an extended attribute.

      Reply
  2. beth bartlett

     /  March 12, 2013

    Thank you very much for posting this! I have been battling with the same problem for months and had given up on ever being able to use Acrobat again. I couldn’t follow all the instructions, but managed switch the root user off then on again, which prompted resetting and reverifying the root user password. After rebooting ACROBAT WORKED FINE!!!!
    Thanks again for taking the trouble to post your experience.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: