Permissions issue with mint installation with mint
jonasman opened this issue Β· 12 comments
% swift run mint install yonaskolb/mint
π± Finding latest version of mint
π± Cloning mint 0.14.2
π± Resolving package
π± Building package
Error: You donβt have permission to save the file β0.14.2β in the folder βbuildβ.
i solved by installing with:
% sudo swift run mint install yonaskolb/mint
Hi @jonasman,
Using sudo
to run mint can be a security risk, as it would execute tools with root permissions.
Probably there is at least one file or folder, which your current user cannot access.
Instead you can try to change the owner of your mint files using sudo chown -R $(whoami) /usr/local/lib/mint/*
.
Alternatively you could try to delete all data of mint located at /usr/local/lib/mint
.
Does it help you?
I have the same issue. However there is no /usr/local/lib/mint
folder on my new Mac. Therefore I resolved the issue by creating this folder.
I just had the same problem on a fresh install of macOS 11.1:
ratkins@girder ios-app % mint run swiftlint --config ".swiftlint.yml"
π± Cloning SwiftLint 0.41.0
π± Resolving package
π± Building package
Error: You donβt have permission to save the file β0.41.0β in the folder βbuildβ.
I had to sudo mkdir -p /usr/local/lib/mint
and sudo chown -R $(whoami):admin /usr/local/lib
to get it to work.
Is there a way to make this work out of the box?
This is an issue with newer versions of macOS.
Without using a sudo requiring installation script, we could move installations from /usr/local/lib/mint
to ~/.mint
, though this is a breaking change. But that could maybe be mitigated by reading from both directories.
How does Homebrew do it? I thought post-SIP /usr/local
on macOS was explicitly for the use of third party tools like brew and mint (I found a good reference for this once but my Google-fu is failing me.)
Same here.
It seems like for the versions of macOS before Big Sur, /usr/local/bin
was
rwxrwxr-x yourusername admin
and on Big Sur its
rwxr-xr-x root wheel
I'm not sure whether its a macOS change (which would make sense since /usr/local
is shared among users of the machine), or if Homebrew was setting a different ownership / permission on /usr/local/bin
)
Anyway, for the time being adding custom MINT_PATH
and MINT_LINK_PATH
variables in my shell environment solved the problem for me.
I used:
export MINT_PATH="$HOME/.mint"
export MINT_LINK_PATH="$MINT_PATH/bin"
and added $MINT_LINK_PATH
to my $PATH
.
Without using a sudo requiring installation script, we could move installations from /usr/local/lib/mint to ~/.mint, though this is a breaking change. But that could maybe be mitigated by reading from both directories
@yonaskolb wouldn't this be a breaking change anyway for the --link
option, since most user won't have ~/.mint
directory in their $PATH
?
@ratkins where you referring to this? https://support.apple.com/en-us/HT204899
Paths and apps that third-party apps and installers can continue to write to include:
- /Applications
- /Library
- /usr/local
@guillaumealgis Yes, that was what I was thinking of! Thanks.
I am also suspicious that the change in ownership of /usr/local/bin
being something Homebrew did (and btw itβs /opt/homebrew
on M1.)
@guillaumealgis Thank you very much, your suggestion worked like a charm! π
But I adjusted the commands so the new env vars are persisted:
echo 'export MINT_PATH="$HOME/.mint"' >> ~/.zshrc
echo 'export MINT_LINK_PATH="$MINT_PATH/bin"' >> ~/.zshrc
source ~/.zshrc
@yonaskolb mint
could probably check if it needs to use /opt/
(as @ratkins suggests) instead of /usr/local/
in Big Sur?
My specifics are M1 + Big Sur + installed via Brew.
@guillaumealgis & @Jeehut trick works, so clearly the build destination should be one with write permission (like in $HOME/.mint
).
I've updated the path defaults in this PR #216. Can people have a look and give any feedback. One result is that ~/.mint/bin
must now be manually added to $PATH
if packages need to be run outside of mint
Released in 0.17.0
The same issue is happening in Ventura with an M1, Fix is valid