-
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
Failure to install updates that require administrator privileges #131
Comments
+1 on this really needs to be fixed. this has been a problem with squirrel and auto-updates on Mac OS X since Mac OS X 10.9.4 & atom 0.110.0, and we're now on Mac OS X 10.11.1 El Capitan and Atom 1.2.3. |
+1 Needs to be fixed. Running into this in Zurbs new Yeti Launch app. |
Please do not +1 issues. If you would like to see this fixed sooner, consider submitting a pull request instead. |
Temporary workaround for end-users: Install the app you are trying to use to `~/Applications' rather than '/Applications' and set the app to 'Keep-in-dock' so you can easily find it. It's not a great workaround since most other apps install to '/Applications', but it will at least enable a normal end-user to use the original app (such as Atom) and get access to auto-updates. |
Everyone - thankyou so much for the hard work on Squirrel - it's been effortless to setup and I love the simplicity of it. This issue is a big snag for us - we're shipping a cross platform electron app that mostly runs invisibly as a daemon, and unfortunately isn't a fit for the MAS. Given it's invisibility, autoupdates seemed like a no-brainer - but this is a hard stop for us. I've scoured the existing threads and I can't seem to find a solution as of yet, the For posterity, the issue is a crash during the "update" step of autoupdate from the logs:
I'm not an Obj C expert - but given no-one is championing this at the moment, I'd love to do what I can to help. If someone on Squirrel team could potentially point me in the right direction to fixing this, my team can take a stab at it! Thanks again for all the hard work everyone...! ❤️ |
@hhff Thanks for the very nice comment! Unfortunately, neither @keithduncan nor I really actively work on this anymore (and we don't really have the time to do so). @paulcbetts has suggested that this is because a root-privileged app will write a |
Gotcha - thanks @jspahrsummers ! Where in the codebase would you recommend starting out? |
@hhff I'd try to track down the place that is writing |
Thanks @paulcbetts - I'm operating in an Electron environment - any tips for tracking that down in Node world? |
@hhff oof, good question. Do you have the entire log? |
@paulcbetts yup - for me it's in That folder: That
|
Looks like these would be the places to adjust permissions for writing:
Unfortunately, I don't have time to dig much more than this. Hopefully this is helpful! |
How would ShipIt receive permissions issues if it's explicitly running as root 🤔 |
Thanks @jspahrsummers & @paulcbetts ! It appears the issue on my end is not "writing to ShipIt logs / cache directories" (the Update is downloaded and unzipped to the correct place no problem) but, (I suspect) the issue stems from actually "applying" the newly downloaded package to the existing app. This may be a red herring, but as an experiment, I did Now the log is:
I've since closed |
Having the same issue. Would love to participate in fixing it but I have no idea how to compile and test this code base. Anyone can help me get started? |
Even though we prompt for a password, it apparently still fails. See atom/atom#2860 (comment) and later comments for some example logs.
The text was updated successfully, but these errors were encountered: