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

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: https://github.com/atom/atom/issues/2860#issuecomment-121111312

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)];

About this issue

Original URL
State: open
Created 9 years ago
Comments: 29 (5 by maintainers)

Most upvoted comments

@etyp - I removed the caches the same way you did, but that was the only cleanup effort I attempted between testing Electron 1.7.6 and 1.7.8. However; a major difference in my environment… I’m not using electron-builder. I don’t know if there is anything in electron-builder that could be causing this, and I didn’t check since my initial issue manifested via squirrel.mac.

If it’s any help, my build process (a gulp task) for macOS is:

Package via electron-packager.
Make minor modifications to resulting file resources/permissions (specifically to correct https://github.com/electron/electron/issues/10634).
Code sign the app via electron-osx-sign.
pkgbuild via child process to build a .pkg installer.
productsign/productbuild via child process to sign the installer.
Compress the .app via 7zip-bin (same module used internally by electron-builder) - the resulting zip file is what I ultimately serve to Electron autoUpdater (again, not using electron-builder’s custom autoUpdate).

Steps 4 & 5 are specific to my installer (not updates), so it shouldn’t have any impact on this issue. I’m using Electron 1.7.8 now and don’t enforce any kind of build caching in the aforementioned process. It’s a painfully slow build, but works flawlessly every single time.

coreybutler on Oct 13, 2017

Yes, it’s in Electron though I’m not sure which versions include the fix.

joshaber on Oct 6, 2017

@btelintelo - thanks for the suggestion. Even if an .app file is given instead of dmg, if the admin user installs it in /Applications, then other standard users will still run into the same issue I think. I wish I knew enough objective-c and Cocoa 😛

fancyydk on Mar 13, 2017