More details for the curious, of the output of newproc.d when Dropbox is first launched, below. But it seems like one could push a Dropbox config like this and not bother needing to update it again with Munki for quite a while. Still not obvious to me what logic will trigger an update, but my account is configured to receive new updates quickly, and it doesn't seem like it's usually taken longer than a day or even a few hours. It has since updated to 2.0.8 and now to 2.0.10, all within its app bundle at /Applications, running as a non-admin. and re-installed on mine and a test machine. I added a line to the postinstall_script to recursively set permissions on /Applications/Dropbox.app to 777:įileUtils.chmod_R(0777, '/Applications/Dropbox.app') So when it decides to update, it would seem to transparently stash it in the user's home instead and use that in the future. Users/tsutton/Library/Application Support/Dropbox/Dropbox.app/Contents/MacOS/Dropbox /firstrunupdate 15133 However, the command was not running with the bundle at /Applications, it was running from a new copy in my user's library: I was away from my work machine yesterday, and today I arrived to it running 2.0.8. app bundle therefore has root:admin ownership.Ī couple weeks ago 2.0.8 was released. app Munki pkginfo, with the only addition being Riley's Ruby script. A few weeks ago I installed 2.0.5 using a standard copy_from_dmg.

Dropbox password on folder