rig
rig copied to clipboard
r-lib
Error on brew upgrade (probably the cleanup part)
Around a month ago, I encountered an issue while performing a brew upgrade. The specific error thrown was:
Error: Permission denied @ rb_readlink - /usr/local/bin/R-4.3-x86_64
To fix this, I used rig to:
- Uninstall all versions of R.
- Reinstall the latest version of R
I made very sure to not run any sudo before this, but rig still asked for my password, so it is probably doing that internally.
After these steps, brew upgrade seemed fine, and I did not report the bug immediately, in order to keep down the noise on the issue tracker in case this was just due to me running with the wrong permissions initially. But there was a bit of worry in the back of my mind about it happening again. And, as fate would have it, the issue popped up again today, pretty much a month and a day later. And I'm guessing it is because it now tried to run cleanup again.
My guess is that rig with it's sudo permissions installs some files that homebrew thinks should be cleaned up. The permissions then cause homebrew cleanup to fail, so it gets rerun immediately and fails again. Uninstalling R monthly to enable brew cleanup seems overkill. If there is not an easy fix to rig itself, I wonder if there are any potential manual file permission workarounds that could be used to allow the cleanup to proceed successfully.
Would appreciate any insights or help with this. Thanks!
I don't really understand why brew would try to clean up files that do not belong to it.
Also, I do have
❯ ls -l /usr/local/bin/R-* | grep root
lrwxr-xr-x 1 root admin 66 Oct 11 09:32 /usr/local/bin/R-devel@ -> /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/bin/R
but brew upgrade still works fine.
Do you have R installed from brew as well? What is the output of this for you?
ls -l /usr/local/bin/R-*
Thanks @gaborcsardi, your pointers led me to a solution of sorts. The problem was that for me these links were owned by root with permissions 700. I could run them, but the os would not tell me where the actual files were:
$ ls -la /usr/local/bin/R-release
ls: /usr/local/bin/R-release: Permission denied
lrwx------ 1 root admin ... /usr/local/bin/R-release
(Note the absence of the -> ... part)
And brew cleanup probably was not trying to remove them, it just wanted to be able to see where the symbolic links pointed to, in order to determine if they belonged to it or not.
More perplexingly, even after repeated attempts to change the permissions and ownership of the links using chown and chmod, these permissions would not budge. I cannot for the life of me understand why. In the end, I removed them and recreated them manually, and now brew cleanup works fine. And I can repeat this process if the problem reoccurs with a new R version.
There is no issue with with homebrew packages in general because the just do everything in the name of the user from the start, so it doesn't come up. But why MacOS would not let me change permissions in order to allow this, I do not understand.
So I'll close this for now.
Great! For the record,
rig system make-links
creates/removes the links as needed, although I am not sure if it fixes the permissions. But if you remove them and then call this command, they should have the correct permissions.
Thanks. That actually breaks it again for me, because it sudos and creates the links with permissions that don't allow me to ls -la them. Strange.
What's your umask setting? I suspect that your system is configured to create files that way.
❯ umask
022
❯ sudo umask
0022
$ umask
0077
And I can confirm that sudo umask on my mac always follows my regular umask. So setting umask as a regular user carries over to su. And this 077 is the result of configuration on my computer.
I can also confirm that setting umask 022 before running rig system make-links fixes the issue. No need to do sudo umask, it just works. I wonder what the best solution is then? Should rig set the umask itself? Should it warn if umask does not match what is expected and needed for correct functioning? Or should 077 be stated as a "wrong" setting that can cause issues?
And I am now wondering if this is the same root cause as for some issues I was having with pak (I contributed to the discussion on https://github.com/r-lib/pak/issues/351 - is it possibly the case that ownership inconsistencies surface sooner for people with this more restrictive umask)?
FWIW this is a pristine Sonoma VM:
admin@admins-Virtual-Machine ~ % umask
022
admin@admins-Virtual-Machine ~ % sudo umask
0022
But yeah, maybe rig could always make the symlinks readable. I was a little reluctant to do that, because if the user changed their umask, then I assumed they had a reason, but if they might change it inadvertently, that's different.
IDK if the umask by itself would cause issues with pak. That pak issue happens when people use the root user to install packages into some package library. Which they should not do. rig also runs pak as the regular user, as much as it can, but of course is somebody users sudo rig then the "regular" user might be root as far as rig is concerned.
I completely agree with the sentiment to do as much as possible as a regular user, and also to not override settings such as umask unless absolutely needed. But this might be a case where as rig proceeds to elevate for a narrow part of its operation, it would also be explicit about permissions for files created while elevated. Possibly with a warning? To me at least, that feels like a better solution than having to change the umask for everything to be group+all readable. Thanks again for helping me figure this out!
To me at least, that feels like a better solution than having to change the umask for everything to be group+all readable
Well, I think one could argue that the issue is with brew and brew should ignore the links that it cannot read.
But I think we can create the links with 755 permissions.
Just a minor update, I just updated to 4.3.2. Before running rig add release I ran umask 022. And after doing this I can still run both ls and homebrew without error:
ls -l /usr/local/bin/R-*
brew upgrade
brew cleanup
But yes, I agree that ideally, homebrew should just ignore unreadable links.