yonaskolb/Mint

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
aonez commented

@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