Package manager non admin installs failing

Question

Level 1

0 points

Package manager non admin installs failing

Hi, hoping someone could help.

I'm attempting to make a .pkg installer; the installer basically installs my program (configurable by the user, but typically will be to a subfolder of their home directory), and then runs a postflight script. Neither of these actions (I believe) should require root access; the script simply makes some changes (via sed) to some of the files installed, and then launches another .pkg file (via open) which was installed along with everything else in the directory the user chose.

When creating the pkg I selected "No authorization required", as I would like users without root access to be able to install my software, if possible.

Attached is the error log produced when my .pkg was run. It seems to be an error deleting the package's scratch temp folder. Any illumination provided would be greatly appreciated. Many thanks.

Aug 23 16:29:31 macbook installd[4727]: PackageKit: ----- Begin install -----
Aug 23 16:29:31 macbook installd[4727]: PackageKit: Install Failed: (null)\nError Domain=NSCocoaErrorDomain Code=513 UserInfo=0x10ec40 "PKInstallSandbox-tmp couldn’t be removed because you don’t have permission to access it." {\n NSFilePath = "/var/folders/aG/aGKQOtmVG6uGFEox-dSF-E +TI/-Tmp-/PKInstallSandbox-tmp";\n NSUserStringVariant = Remove;\n}
Aug 23 16:29:32 macbook Installer[4714]: Install failed: The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.
Aug 23 16:29:33 macbook Installer[4714]: Displaying 'Install Failed' UI.
Aug 23 16:29:33 macbook Installer[4714]: 'Install Failed' UI displayed message:'The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.'.

Mac OS X (10.6.3)

Posted on Aug 22, 2010 10:05 PM

Reply

Answer 1

etresoft

Level 8

46,312 points

Aug 23, 2010 8:07 AM in response to James_Raynor

PackageMaker can't do that. If you have an install package that installs only and exclusively to a user's home directory, then you can have "No authorization required". Otherwise, you need Admin privileges.

Reply

Answer 2

James_Raynor Author

Level 1

0 points

Aug 24, 2010 10:39 PM in response to etresoft

Thanks for the reply. My package does indeed install only and exclusively to the user's home directory - unless I have overlooked something. It does run a postflight script, and this script does copy a file to the temp directory that gets created for the install - I thought such an action was allowed, but perhaps that is the cause of the failure.

Reply

Answer 3

James_Raynor Author

Level 1

0 points

Aug 24, 2010 10:52 PM in response to James_Raynor

Nope, even with blank scripts it fails in the same way:

"PKInstallSandbox-tmp couldn’t be removed because you don’t have permission to access it."

My guess here is that packagemanager is attempting to perform some sort of clean up after the install is complete, which includes deleting this temp directory, but does this clean up whilst running as the user that executed the package (as opposed to root), and the clean up fails.

If anyone can shed more light on this it would be welcome.

Reply

Answer 4

James_Raynor Author

Level 1

0 points

Aug 25, 2010 10:06 PM in response to James_Raynor

Ok, a colleague with more unix understanding than I helped me work through this.

When the installer is run, the entire contents of the pkg are copied to PKInstallSandbox-tmp, into a structure mimicking the one they're going to be installed into.

My project file was set up to preserve the permissions for each file and folder within an app bundle that was a component in the pkg. the problem was, some of those files were not even owner writable - they looked like -r-xr-xr-x. When the installer was run without root authorization, it was then unable to delete these files which were in subdirectories below PKInstallSandbox-tmp, hence it was unable to delete PKInstallSandbox-tmp. Since successfully doing this cleanup was (apparently) a make-or-break step in the installation procedure, the entire install failed. After discussion, the files in question didn't need to be unwritable by anyone, so I just chmod u+w'd them before putting them into the pkg and all was well.

Not sure why this issue only reared its ugly head when I had scripts activated, but it didn't appear when I had them disabled. Hence it seemed to me to be script-related, but it wasn't.

At any rate, solved.

Reply