Can't install Adobe products on Mac OS 10.7 Lion
August 1, 2011 11:51 AM   Subscribe

After installing OS 10.7 Lion I am unable to install any Adobe products, including Flash, Photoshop and Illustrator - can anyone help?

Okay so I foolishly updated to Lion without realizing PowerPC wouldn't be compatible (my mistake, didn't think about it). So now I've had to repurchase Photoshop/Illustrator and reinstall.

The Photoshop CS5 installer states that "The installer failed to initialize." I followed all the previous instructions and wiped my computer clean of anything Adobe (including Library and ~/Library) but I still get the error. When I look at the logs it says that the fatal error was that it was "Unable to create PIM object." The Google says nothing about this error.

After doing tons of research people suggested reinstalling Adobe AIR and Flash. Air installed no problem, but Flash refuses to install. It will begin the installation but get anywhere from 4-12% (varies every time) before failing. That log states "Error trying to locate volume at /" which again, Google says nothing about.

I'm running as an administrator and have checked all the permissions. I've also installed and verified the JRE is working properly.

TIA
posted by trevs44 to Technology (8 answers total)
 
Try the Cleaner Tool?
posted by holgate at 11:56 AM on August 1, 2011


Response by poster: Yes, tried the Cleaner Tool - it found no issues.
posted by trevs44 at 11:57 AM on August 1, 2011


Best answer: Okay, I figured it out.

First, Flash - I repaired Disk Permissions and it installed after a reboot.

Photoshop - once I had installed Flash I attempted to install Photoshop again. It failed, but this time the log stated that it couldn't create the folder Applications in my User folder - for some reason, there was a UNIX executable named Applications in my User folder that wasn't allowing it to create that folder. I renamed the executable and voila - everything works.

Definitely not a fun experience, but all is well now.
posted by trevs44 at 1:11 PM on August 1, 2011


Came here t say that the Apple fix permissions thingee only works on the System folder. To do it on the user folder go to terminal and

sudo chmod -R 770 ~

There is also a way to do this in the GUI, on one of the control panels. IIRC it had something to do with changing passwords...anyway someone at AppleCare showed me where the button is, and it wasn't anywhere where I thought it should be, so I've since forgotten.
posted by Gungho at 1:52 PM on August 1, 2011


Just a heads up, please don't run chmod -R 770 on your home directory. It will indiscriminately mark every file therein as executable and will bar all other users from accessing anything in there, including the Public and Sites folders. This is almost certainly not what you want, and has a high likelihood of breaking stuff.
posted by SemiSophos at 3:49 PM on August 1, 2011 [2 favorites]


Ohhh. Did I miss something? I was basing it on the following. I am not anything close to a UNIX power user.

"UNIX permissions require a folder to be executable in order to cd to it. 777 means rwx for all owners, groups and users. 776 means rwx for owners and groups but any user not owning or in a group can only read the directory, thus not being able to modify anything in there. That might be fine, but 770 is best. That means owners and group members can read and write to the directory and no one else can even read. We'll use 770."

I hope I didn't steer anyone wrong.
posted by Gungho at 7:22 AM on August 2, 2011


Changing a directory's permissions to 7 makes it navigable; changing a file's permissions to 7 makes it executable. That's not great. Running chmod indiscriminately on a Mac isn't great, either, because it rides roughshod over how OS X uses ACLs.
posted by holgate at 11:16 AM on August 2, 2011


No worries, Gungho, it's unlikely that anyone would actually lose data as a result, but it's definitely not a good practice. :)

There's a pretty key difference in what the executable bit means for files and for directories. For directories, it means "you can see what files are inside this." For files, it means "this is a program that can be run directly."

A blanket run of chmod -R with a numeric mode is a chainsaw in a place where you generally need a scalpel. For instance, with "chmod -R 770 ~" you're saying:
  1. I want to be able to read, modify, delete, and look inside every single folder in my home directory.
  2. I want to be able to read, modify, and delete every single file in my home directory.
  3. Every single file in my home directory is a program unto itself, and I can run it on its own.
  4. I want everyone in my primary group to be able to do the same with my files, which on Mac OS X 10.5+ means all other users on my computer.
  5. Anyone who is not me, and is not in my primary group, should not be able to have any access whatsoever to any file in my home directory.
No matter what mode you come up with, there will almost always be mutually incompatible corner cases for something like your home directory. The Public folder is a good example of this, since it can be read (but not written to) by anyone on your Mac, while the Drop Box subfolder can be written to by anyone on your Mac, but can only be read by you.

Similarly, if you turn on Web Sharing in System Preferences, the local web server (which runs as user "_www") needs to be able to read the Sites folder in your home directory, so that folder has mode 755 (rwxr-xr-x), allowing anyone to read or explore it, but only allowing you to modify it.

Lastly, some particularly cautious unix programs will only run if certain files aren't readable or writable by anyone else. If memory serves, the GPG encryption suite requires that your private keychain have mode 600 (rw-------) before it will start up. Similarly, someone who can read your private ssh key at ~/.ssh/id_rsa may be able impersonate you when trying to log into other *nix servers.

General rule of thumb: Most developers these days understand Unix permissions well enough to not inadvertently muck up system files. Running "Repair Permissions" in Disk Utility can't hurt, but if that doesn't fix it, it's generally not a permission issue.
posted by SemiSophos at 11:21 AM on August 2, 2011


« Older Toronto gigs?   |   The earworm, it burns! It burns like ponies! Newer »
This thread is closed to new comments.