The file "ShipItState.plist" couldn’t be opened because there is no such file

[thughes]

In an Electron-based app, I encountered an issue where one user was unable to update. The logs in ShipIt_stderr.log showed this message over and over:

Installation error: Error Domain=SQRLShipItRequestErrorDomain Code=2 "Could not read update request" UserInfo=0x7fe4cae09930 {NSLocalizedDescription=Could not read update request, NSUnderlyingError=0x7fe4cae07d50 "The file “ShipItState.plist” couldn’t be opened because there is no such file."}

However, ShipItState.plist did exist, but the two log files had different permissions than the plist file and the update directory:

drwxr-xr-x   7 foo  staff   238B Sep  9 17:16 .
drwx------+ 41 foo  staff   1.4K Sep  9 17:16 ..
-rw-r--r--@  1 foo  staff   6.0K Sep  9 17:24 .DS_Store
-rw-r--r--   1 foo  staff   262B Sep  9 17:16 ShipItState.plis
-rw-r--r--   1 root     staff   195K Sep  9 16:55 ShipIt_stderr.log
-rw-r--r--   1 root     staff     0B Sep  9 16:38 ShipIt_stdout.log
drwx------   4 foo  staff   136B Sep  9 17:24 update.c3etqCW

Doing a chown fixed the issue:

sudo chown foo:staff ShipIt_stderr.log ShipIt_stdout.log

It looks like others are hitting this same issue: atom/atom#2860 (comment)

It looks like SQRLUpdater.m has some logic around running as root/non-root, but if the log files are owned by root and being updated then I would assume it's running as root and should be able to read the ShipItState.plist file that's owned by a non-privileged user:

    NSError *targetWritableError = nil;
            BOOL gotWritable = [targetURL getResourceValue:&targetWritable forKey:NSURLIsWritableKey error:&targetWritableError];

            // If we can't determine whether it can be written, assume nonprivileged and
            // wait for another, more canonical error.
            return [SQRLShipItLauncher launchPrivileged:(gotWritable && !targetWritable.boolValue)];

[thughes]

Another example of the same issue: https://discuss.atom.io/t/update-not-working-com-github-atom-shipit-respawns-all-the-time/9819/15

[keithduncan]

Good debugging, does creating these log files ahead of time as the non-priviledged user fix this? Can we get an improved error message in this failure case given that it’s the log file permissions at fault and not the non existence of the install request file?

[thughes]

I'll see if I can reproduce it on the machine that had the issue and try pre-creating the log files.

[thughes]

Unfortunately, I haven't been able to reproduce the issue, so it seems like it must be a race. Perhaps the best thing is to intentionally chown the files as shown above and see if squirrel can be made to be defensive about the situation?

[eject-it]

Reproducing this error is rather easy. Just chmod the ~/Library/ with 700 as it is supposed to be. At least that is what it used to be way back. [Edit: the folder!, not everything contained within and definitely not all files]

Why?
Because your actual User/Name folder is 755, so in a multiuser Account people can come in and see your folders. From there, /Users/myName/ , they then can access your public folder where you can share stuff with other users of that computer. It also contains the dropbox were they can pop files in (not the one from the application, the one that every OSX users has).

Anyway, all this works because /Users/myName/ is 775 and if you want to stop people looking in your folders below you have to set them to non executable for "group" and "everyone", typically that is 700.

This means that you need to be either the owner or someone who can overwrite the owners privileges to go there. Most applications ask for a password when they install themselves for the first time. Then they create a folder inside which can have less restrictive i.e. 775 permissions. In this folder they can than write without asking every bloody time*. Because permissions are not inherited. They are local. So you can have them nested. Which is sort of the concept of the ~/ folder anyway since it is also nested inside root.

Needless to say I found this topic by wondering how I can stop this raging menace. I need the syslog and rebooting would obviously be pointless.

*and not actually saying what that "helper application" is. I update atom only manually anymore. It just won't say what it is going todo but it wants to be potentially root.

[btelintelo]

Was there ever a permanent fix to this issue? What can I do with the computer novice out in the wild that cannot update and gets this prompt all the time?

[perlun]

Getting this error now, with Atom. ~/Library is mode 700 for me (using El Capitan).

[emorikawa]

This issue appears to happen when people open the app directly from the DMG instead of copying to their Applications folder first.

The app will open fine, but once the download finishes updating the following prompt appears:

When the password is entered, Squirrel is now run as root, the log files are created as root, and the update process no longer works.

Squirrel will now dump the Installation error log mentioned above into the Mac Console, as well as continue to try every second and keep dumping it in the ShipIt_stderr.log file. Over time, that file grows without bound. By the time I had discovered it, the log file was 500MB!

To make matters worse, this is not fixed by "reinstalling" the app. If a user deletes the app from their Applications folder and puts a new one in its place, the ~/Application Support/com.your.name.ShipIt folder is not deleted. The root state is not fixed.

This seems to be related to #163

Any ideas on how to fix this? (Other than telling our users to rm their Application Support folder and remove the launch agents!)

Unfortunately, this means some percentage of our users (those that launched the app via the DMG) are likely permanently stuck on old versions!

[emorikawa]

Based on our update logs. I estimate this is affecting about 3-6% of our entire user base.

[btelintelo]

We stopped distributing the dmg and instead distribute the .app file which seems to work fine, but doesn't give the user a nice interface to install to the apps directory.

[dknutsen]

Our hacky but seemingly effective solution to this is to (ASAP) check the app.getPath('exe') path to see if it's mounted in "/Volumes" and if it is, exit immediately. This at least prevents it from being run out of the DMG.

Something like this:

if(app.getPath('exe').slice(0,8) === "/Volumes") {
  dialog.showErrorBox("App cannot be run directly from DMG", "This app cannot be run directly from the DMG. Please install it to 'Applications' before trying to run it.");
  app.exit(0);
}