-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The file "ShipItState.plist" couldn’t be opened because there is no such file #151
Comments
ShipItState.plist
couldn’t be opened because there is no such file
Another example of the same issue: https://discuss.atom.io/t/update-not-working-com-github-atom-shipit-respawns-all-the-time/9819/15 |
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? |
I'll see if I can reproduce it on the machine that had the issue and try pre-creating the log files. |
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 |
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? 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. |
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? |
Getting this error now, with Atom. ~/Library is mode 700 for me (using El Capitan). |
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 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 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 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! |
Based on our update logs. I estimate this is affecting about 3-6% of our entire user base. |
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. |
Our hacky but seemingly effective solution to this is to (ASAP) check the Something like this:
|
Chiming in here to mention a possible situation that causes this: our IT team has software that runs to automatically "correct" permissions and apply updates, and somewhere in that it mixed up the permissions for the Visual Studio Code.app (which uses Squirrel via Electron). In my case I had sufficient permissions to manually chown'ing the .app file back to myself. |
I have a 100% repro of this. You don't need to modify permission, as most users wouldn't, I assume. Here's the scenario:
I was able to get more specific errors than the error OP saw. It looks like Squirrel.Mac looks for the ShipItState.plist in /var/root/Library/Caches/com.app.app1.ShipIt instead of /Users/user/Library/Caches/com.app.app1.ShipIt, perhaps due to the elevated privilege when the standard user entered the admin credentials? I think this could be a very common case as there are many users with admin access who use a standard user account on purpose. Do we have any fix or workaround? |
Only workaround is to distribute as a .app file instead of dmg. Other than that you might have to become a contributor? This is a major bug and has been around for 1.5 years. |
@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 :P |
I still see this today. Any updates? Any tips? What is the best way to distribute then? This is pretty critical flow, I can see a lot of people opening the app even if by mistake. |
Same here, I'm trying to get rid of ShipIt altogether, it's insane. On 10.12.6, running 1.19.4. I can't find what keeps launching ShipIt, it's not called *shpit*, nor *squirrel*, I have no idea how to find this thing! Nothing jumps at me in terms of launchctl, there's no LaunchAgents, no LaunchDaemons, this is some ghostbusters stuff. |
I'm running into a similar/related issue, with one difference being I have a pkg installer that dumps the
The main point of interest is in the first message, where it chokes on FWIW, I'm building on High Sierra. |
Major bug, project doesn't have any maintainers. |
@coreybutler That sounds like #131 which was fixed in #207. |
Yes, it’s in Electron though I’m not sure which versions include the fix. |
@coreybutler It's still happening to me in 1.7.8 --- did you clear out any specific directories before getting it to work? I've cleared the following:
And when I rebuild using electron-builder and
Anything I might be missing in clearing out old directories? |
@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:
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 thanks - followed your process all the way through (except I wasn't sure exactly what to do with step # 2, so if that's critical here please let me know specifics around what needs to be changed). Unfortunately, I was still prompted to install the helper with admin info and got the same issue once the helper was installed:
Confirmed that I'm definitely on Electron 1.7.8 - not quite sure what to try next and will keep trying. Let me know if step # 2 was critical to this working for you. |
@etyp - I don't think step 2 is critical, because that issue has been a part of Electron for a long time. However; if you want to try it, my code is basically a two-liner for that step: let electronPath = path.join(appPath, 'Contents', 'Frameworks', 'Electron Framework.framework')
exec(`chmod +x "${path.join(electronPath, 'Versions', 'A', 'Libraries', 'libffmpeg.dylib')}"`)
I honestly don't think this will change your results, but I'm out of ideas. |
It looks like the fix was released in Electron 1.7.9: https://github.com/electron/electron/releases/tag/v1.7.9 |
@joshaber hmm, yeah looks like it includes the bump to v1.2.1 PR from electron/electron#10071, but I now get the issue mentioned on #212 as a result with Electron 1.7.9 Any idea how I can best track when https://github.com/electron/electron/pull/10298/files will be added to an Electron build version? Thanks :) -- |
@etyp I downloaded the version tagged Electron 1.7.9 and verified it has the proper ShipIt version. I'm not sure if there could be caching at play. |
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:However,
ShipItState.plist
did exist, but the two log files had different permissions than theplist
file and the update directory:Doing a
chown
fixed the issue: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 theShipItState.plist
file that's owned by a non-privileged user:The text was updated successfully, but these errors were encountered: