I might have a bit of a messed Docker installation on my Mac..
At first I installed Docker desktop but then running it I learned that as I'm on an older Mac I had to install VirtualBox so I did following these steps:
enable writing on the /usr/local/bin folder for user
sudo chown -R $(whoami) /usr/local/bin
install Docker-Machine
base=https://github.com/docker/machine/releases/download/v0.16.0 &&
curl -L $base/docker-machine-$(uname -s)-$(uname -m) >/usr/local/bin/docker-machine &&
chmod +x /usr/local/bin/docker-machine
install Xcode CLI..manually from dev account
Install Home Brew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
Install Docker + wget ( Using Brew)
brew install docker
brew install wget
Install bash completion scripts
base=https://raw.githubusercontent.com/docker/machine/v0.16.0
for i in docker-machine-prompt.bash docker-machine-wrapper.bash docker-machine.bash
do
sudo wget "$base/contrib/completion/bash/${i}" -P /etc/bash_completion.d
done
enable the docker-machine shell prompt
echo 'PS1='[\u#\h \W$(__docker_machine_ps1)]\$ '' >> ~/.bashrc
Install VirtualBox, ExtensionPack and SDK: https://www.virtualbox.org/wiki/Downloads
I now installed docker-compose (docker-compose version 1.29.2, build unknown) with home-brew but when running docker-compose up I get the following error:
docker.credentials.errors.InitializationError: docker-credential-desktop not installed or not available in PATH
which docker prints /usr/local/bin/docker.
Brew installations are in /usr/local/Cellar/docker/20.10.6 and /usr/local/Cellar/docker-compose/1.29.2.
As I see there is also a home-brew for docker-machine should I install docker-machine via home-brew instead?
What can I check to make sure that I use the docker installations from home-brew and wipe/correct the installations made from steps above?
Check your ~/.docker/config.json and replace "credsStore" by "credStore"
{
"stackOrchestrator" : "swarm",
"experimental" : "disabled",
"credStore" : "desktop"
}
just in ~/.docker/config.json change credsStore to credStore
After a long googling I found out that the problem is with the config.json file.
The "credsStore" : "docker-credential-desktop" is wrong one in :
{
"credsStore" : "docker-credential-desktop",
"stackOrchestrator" : "swarm",
"experimental" : "disabled"
}
changed the "credsStore" key value to "desktop" and compose now works as expected. Some pointed out that credsDstore typo was the problem and fixed it with credDstore, but in my case the value was the problem, it works both with "credsStore" : "desktop" and "credStore" : "desktop".
Hope it'll help others starting out with Docker.
Cheers.
Since you're on a Mac, you could use docker-credential-osxkeychain instead.
Install docker-credential-helper.
brew install docker-credential-helper
Verify docker-credential-osxkeychain is available.
$ docker-credential-osxkeychain version
0.6.4
Set credsStore to osxkeychain in ~/.docker/config.json
{
"auths": {
"https://index.docker.io/v1/": {}
},
"credsStore": "osxkeychain",
"experimental": "enabled",
"stackOrchestrator": "swarm"
}
Login to Docker Hub.
$ docker login -u $USER
Password:
Login Succeeded
I ran into a similar issue using wsl2 on windows 10 while trying to locally invoke an aws lambda function. I was getting docker.credentials.errors.InitializationError: docker-credential-desktop not installed or not available in PATH when running sam build --use-container. Running which docker-credential-desktop showed no results
Upon further inspection I found that docker-credential-desktop.exe was in PATH however. After a quick google, it seems like enabling the wsl2 backend in Docker Desktop for Windows 10 symlinks wsl/docker-desktop/cli-tools/usr/bin/docker-credentials-desktop.exe to /usr/bin/docker-credential-desktop.exe. To fix this I simply removed the symlink and created a new one without .exe
To check the link and remove it:
user#device:~$ ls -l /usr/bin/docker-credential-desktop.exe
lrwxrwxrwx 1 root root 67 Jan 5 23:15 /usr/bin/docker-credential-desktop.exe -> /wsl/docker-desktop/cli-tools/usr/bin/docker-credential-desktop.exe
user#device:~$ sudo rm /usr/bin/docker-credential-desktop.exe
To create a new one without .exe and check it worked:
user#device:~$ sudo ln -s /wsl/docker-desktop/cli-tools/usr/bin/docker-credential-desktop.exe /usr/bin/docker-credential-desktop
user#device:~$ ls -l /usr/bin/docker-credential-desktop
lrwxrwxrwx 1 root root 67 Jan 12 14:22 /usr/bin/docker-credential-desktop -> /wsl/docker-desktop/cli-tools/usr/bin/docker-credential-desktop.exe
After that I sourced .bashrc to update PATH and the problem was resolved. I verified this with which docker-credential-desktop and it now shows the location specified in the symlink above.
If your are on WSL, try desktop.exe, instead of desktop. Because you will find that the program in /usr/bin/ is docker-credential-desktop.exe.
{
"credsStore": "desktop.exe"
}
I have uninstalled and installed Homebrew 3 times now because it seems to never allow me to install anything as it denies me permissions at the end of most installations.
As an example I will post this libjpeg download scenario that I'm currently facing.
I try to install libjpeg and get:
$ brew install libjpeg
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/jpeg-8d.mountain_lion.bottle.1.tar.gz
Already downloaded: /Library/Caches/Homebrew/jpeg-8d.mountain_lion.bottle.1.tar.gz
==> Pouring jpeg-8d.mountain_lion.bottle.1.tar.gz
Warning: Could not link jpeg. Unlinking...
Error: The brew link step did not complete successfully
The formula built, but is not symlinked into /usr/local
You can try again using `brew link jpeg'
Error: Permission denied - /usr/local/opt/jpeg
'brew link jpeg' results in
Error: Permission denied - /usr/local/opt/jpeg
Here is what my brew doctor reads
$ brew doctor
Warning: "config" scripts exist outside your system or Homebrew directories.
./configure scripts often look for *-config scripts to determine if
software packages are installed, and what additional flags to use when
compiling and linking.
Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew provided
script of the same name. We found the following "config" scripts:
/Library/Frameworks/Python.framework/Versions/2.7/bin/python-config
/Library/Frameworks/Python.framework/Versions/2.7/bin/python2-config
/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-config
Warning: You have unlinked kegs in your Cellar
Leaving kegs unlinked can lead to build-trouble and cause brews that depend on
those kegs to fail to run properly once built. Run brew link on these:
jpeg
This permission issue has been making it impossible to use brew on anything and I would really appreciate any suggestions.
I was able to solve the problem by using chown on the folder:
sudo chown -R "$USER":admin /usr/local
Also you'll (most probably) have to do the same on /Library/Caches/Homebrew:
sudo chown -R "$USER":admin /Library/Caches/Homebrew
Apparently I had used sudo before in a way that altered my folder permission on /usr/local,
from here on forward all installations with brew have proven to be successful.
This answer comes courtesy of gitHub's homebrew issue tracker
New command for users on macOS High Sierra as it is not possible to chown on /usr/local:
bash/zsh:
sudo chown -R $(whoami) $(brew --prefix)/*
fish:
sudo chown -R (whoami) (brew --prefix)/*
Reference: Can't chown /usr/local in High Sierra
As a first option to whomever lands here like I did, follow whatever this suggests you to do:
brew doctor
It's the safest path, and amongst other things, it suggested me to:
sudo chown -R $(whoami) /usr/local
which solved that permissions issue.
The OP did just that but apparently didn't get the above suggestion; you might, and it's always better to start there, and only then look for non trivial solutions if it didn't help.
If you're on OSX High Sierra, /usr/local can no longer be chown'd. You can use:
sudo chown -R $(whoami) $(brew --prefix)/*
I didn't want to muck around with folder permissions yet so I did the following:
brew doctor
brew upgrade
brew cleanup
I was then able to continue installing my other brew formula successfully.
I did not have the /usr/local/Frameworks folder, so this fixed it for me
sudo mkdir -p /usr/local/Frameworks
sudo chown -R $(whoami) /usr/local/Frameworks
The first line creates a new Frameworks folder for homebrew (brew) to use.
The second line gives that folder your current user permissions, which are sufficient.
Used commands are as follows:
mkdir - make directories [-p no error if existing, make parent directories as needed]
chown - change file owner and group [-R operate on files and directories recursively]
whoami - print effective userid
I have OSX High Sierra
I had this issue ..
A working solution is to change ownership of /usr/local
to current user instead of root by:
sudo chown -R $(whoami):admin /usr/local
But really this is not a proper way. Mainly if your machine is a server or multiple-user.
My suggestion is to change the ownership as above and do whatever you want to implement with Brew .. ( update, install ... etc ) then reset ownership back to root as:
sudo chown -R root:admin /usr/local
Thats would solve the issue and keep ownership set in proper set.
This worked for me in 2022 on an M1 Mac with Monterey
sudo chown -R $(whoami) $(brew --prefix)/*
Command from top-voted answer not work for me.
It got output:
chown: /usr/{my_username}dmin: illegal user name
This command works fine (group for /usr/local was admin already):
sudo chown -R $USER /usr/local
This worked for me:
sudo chown -R "$USER":admin /usr/local/Cellar/*
brew cleanup
If you would like a slightly more targeted approach than the blanket chown -R, you may find this fix-homebrew script useful:
#!/bin/sh
[ -e `which brew` ] || {
echo Homebrew doesn\'t appear to be installed.
exit -1
}
BREW_ROOT="`dirname $(dirname $(which brew))`"
BREW_GROUP=admin
BREW_DIRS=".git bin sbin Library Cellar share etc lib opt CONTRIBUTING.md README.md SUPPORTERS.md"
echo "This script will recursively update the group on the following paths"
echo "to the '${BREW_GROUP}' group and make them group writable:"
echo ""
for dir in $BREW_DIRS ; do {
[ -e "$BREW_ROOT/$dir" ] && echo " $BREW_ROOT/$dir "
} ; done
echo ""
echo "It will also stash (and clean) any changes that are currently in the homebrew repo, so that you have a fresh blank-slate."
echo ""
read -p 'Press any key to continue or CTRL-C to abort.'
echo "You may be asked below for your login password."
echo ""
# Non-recursively update the root brew path.
echo Updating "$BREW_ROOT" . . .
sudo chgrp "$BREW_GROUP" "$BREW_ROOT"
sudo chmod g+w "$BREW_ROOT"
# Recursively update the other paths.
for dir in $BREW_DIRS ; do {
[ -e "$BREW_ROOT/$dir" ] && (
echo Recursively updating "$BREW_ROOT/$dir" . . .
sudo chmod -R g+w "$BREW_ROOT/$dir"
sudo chgrp -R "$BREW_GROUP" "$BREW_ROOT/$dir"
)
} ; done
# Non-distructively move any git crud out of the way
echo Stashing changes in "$BREW_ROOT" . . .
cd $BREW_ROOT
git add .
git stash
git clean -d -f Library
echo Finished.
Instead of doing a chmod to your user, it gives the admin group (to which you presumably belong) write access to the specific directories in /usr/local that homebrew uses. It also tells you exactly what it intends to do before doing it.
I resolved my issue with these commands:
sudo mkdir /usr/local/Cellar
sudo mkdir /usr/local/opt
sudo chown -R $(whoami) /usr/local/Cellar
sudo chown -R $(whoami) /usr/local/opt
In my case the /usr/local/Frameworks didn't even exist, so I did:
sudo mkdir /usr/local/Frameworks
sudo chown -R $(whoami) /usr/local/Frameworks
And then everything worked as expected.
Firstly, with MacOS Catalina, the basic ways to change the ownership of /usr/local are no longer allowed. For example:
$ sudo chown -R "$USER":wheel /usr/local
Password:
chown: /usr/local: Operation not permitted
$ sudo chown -R "$USER" /usr/local
chown: /usr/local: Operation not permitted
$ sudo chown -R $(whoami) /usr/local
chown: /usr/local: Operation not permitted
Hence, the popular answers above cannot be used. Secondly, however, taking a step back, if the main concern is to install or upgrade Homebrew, rather than wanting to change the permissions for /usr/local per se, then it may be overkill (like taking a sledgehammer to hammer a nail) to change the permissions for /usr/local. It affects your whole machine and other software may also be using /usr/local. For example, I have files related to maven and mySQL in /usr/local.
A more precise solution is to follow the instructions to install Homebrew, given at the Homebrew GitHub site, namely
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
which installs Homebrew inside /usr/local without changing ownership of /usr/local itself. Instead, Cellar, Caskroom, Frameworks, Homebrew, etc. are installed inside /usr/local. This seems to be a more elegant, precise solution in my opinion.
This solved the issue fore me.
sudo chown -R "$USER":admin /Users/$USER/Library/Caches/Homebrew
sudo chown -R "$USER":admin /usr/local
For a multiuser Mac, this worked for me:
sudo chown -R $(whoami):admin $(brew --prefix)/*
For me, it worked after
brew doctor
Change permission commands resulted in another error
chown: /usr/local: Operation not permitted
All of these suggestions may work. In the latest version of brew doctor, better suggestions were made though.
Firstly - fix the mess you have probably already made of /usr/local by running this in the command line:
sudo chown -R root:wheel /usr/local
Then take ownership of the paths that should be specifically for this user:
sudo chown -R $(whoami) /usr/local/lib /usr/local/sbin /usr/local/var /usr/local/Frameworks /usr/local/lib/pkgconfig /usr/local/share/locale
All of this information is available if you run sudo brew update and then read all of the warnings and errors you will run into...
On MacOS Mojave, I did not have permission to chown the /usr/local folder either (sudo chown -R "$USER":admin /usr/local).
sudo chown -R "$USER":admin /usr/local/* did work for me however, altering the permissions of everything within the local folder.
Hopefully this will help others with the same issue.
There's a killer script on github that fixes perms on /usr/local and brew directories to be accessible by anyone who is a member of the 'admin' group.
https://gist.github.com/jaibeee/9a4ea6aa9d428bc77925
This is a better solution than the chosen answer, since if you chown the /usr/local/___ directories to $USER, then you break any other admin users of homebrew on that machine.
Here are the guts of the script at the time I posted this:
chgrp -R admin /usr/local
chmod -R g+w /usr/local
chgrp -R admin /Library/Caches/Homebrew
chmod -R g+w /Library/Caches/Homebrew
chgrp -R admin /opt/homebrew-cask
chmod -R g+w /opt/homebrew-cask
Actually it's really simple, execute this command:
brew doctor
And it will tell you what to do, to fix permission issues, for example in my case:
This was the problem:
Warning: The following directories are not writable by your user:
/usr/local/share/man/man5
/usr/local/share/man/man7
And this was the solution:
You should change the ownership of these directories to your user.
sudo chown -R $(whoami) /usr/local/share/man/man5 /usr/local/share/man/man7
I'm on Catalina and I got this error:
touch: /usr/local/Homebrew/.git/FETCH_HEAD: Permission denied
touch: /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask/.git/FETCH_HEAD: Permission denied
fatal: Unable to create '/usr/local/Homebrew/.git/index.lock': Permission denied
fatal: Unable to create '/usr/local/Homebrew/.git/index.lock': Permission denied
I only needed to chown the Homebrew directory
sudo chown -R "$USER":admin /usr/local/Homebrew
uninstall brew & re-install with the below command to ensure the linking to the brew github and associated permissions to the local folder work correctly:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
This worked perfectly. No mucking around with permissions myself, just reinstalled Homebrew and it works!
source: https://gist.github.com/irazasyed/7732946#gistcomment-2298740
cd /usr/local && sudo chown -R $(whoami) bin etc include lib sbin share var opt Cellar Frameworks
If you happen to have multiple accounts on your mac, chances are, your current account belongs to different user group as the primary account that originally owned /usr/local meaning that none of the solutions above will work.
You can check that by trying to ls -la /usr/local and see what user and group that have permissions to write on the directory.
In my case it was root wheel. It may be root admin.
I solved it by adding the current user to the group that primary account has by using the following command.
sudo dseditgroup -o edit -a $(whoami) -t user admin
sudo dseditgroup -o edit -a $(whoami) -t user wheel
There after it worked like a charm. Hopefully it helps someone out there.
If you don't have the latest Homebrew: I "fixed" this in the past by forcing Homebrew to run as root, which could only be done by changing the ownership of the Homebrew executables to root. At some point, they removed this feature.
And I know they'll give lots of warnings saying it shouldn't run as root, but c'mon, it doesn't work properly otherwise.
I tried everything on this page, I ended up using this solution:
brew uninstall --force brew-cask; brew untap $tap_name; brew update; brew cleanup; brew cask cleanup;
My situation was similar to the OP, however my issue was specifically caused by running sudo with brew cask, and then getting my password incorrect. After this, I was stuck with permissions preventing the installation.
To resolve errors for Brew permissions on folder run
brew prune
This will resolve the issues & we don't have to chown any directories.
In my case, I has having problems removing and reinstalling SaltStack.
After running:
ls -lah /usr/local/Cellar/salt/
I noticed that the group owner was "staff". (BTW, I'm running macOS Mojave version 10.14.3.) The staff group could be related to my workplace configuration, but I don't really know. Regardless, I preserved the group to prevent myself from breaking anything further.
I then ran:
sudo chown -R "$USER":staff /usr/local/Cellar/salt/
After that, I was successfully able to remove it with this command (not as root):
brew uninstall --force salt
I used these two commands and saved my problem
sudo chown -R $(whoami) /usr/local
sudo chown -R $(whoami) /usr/local/etc/bash_completion.d /usr/local/lib/python3.7/site-packages /usr/local/share/aclocal /usr/local/share/locale /usr/local/share/man/man7 /usr/local/share/man/man8 /usr/local/share/zsh /usr/local/share/zsh/site-functions /usr/local/var/homebrew/locks
I am testing how to install a sample network for Hyperledger Fabric. when I was running 'byfn.sh' inside the 'first-network' project, the console will prompt such error:
/bin/bash: scripts/script.sh: Permission denied
it looks like this line produces above error:
docker exec cli scripts/script.sh $CHANNEL_NAME $CLI_DELAY $LANGUAGE $CLI_TIMEOUT $VERBOSE
I used root user, and have used chmod +x or u+x to change all *.sh files permission. but doesn't work, so any ideas? many thanks!!
Finally, I solved this problem by myself.
use Set SELinux mode as permissive:
$ setenforce 0
$ docker exec -it cli bash
the detailed solution is below:
https://nanxiao.me/en/selinux-cause-permission-denied-issue-in-using-docker/
I have no idea why it happens, but I hope if it can help someone.
Use sudo when running the command, will solve the issue.
I have an Ubuntu Hardy slice with Passenger Phusion serving up a rails app.
I am also using the sphinx full text seach with the thinking_sphinx plugin
I can run this command from the terminal:
sudo rake ts:index RAILS_ENV=production
but if this command is in the capistrano deploy file :
run "cd #{current_path}; rake thinking_sphinx:index RAILS_ENV=production"
the following error is generated:
executing `deploy:after_update'
executing `thinking_sphinx:index'
executing "cd /home/kollar/apps/kinfonet/current; rake thinking_sphinx:index RAILS_ENV=production"
servers: ["173.45.226.102"]
[173.45.226.102] executing command
* [err :: 173.45.226.102] rake aborted!
* [err :: 173.45.226.102] Permission denied - /home/kollar/apps/kinfonet/shared/db/sphinx
Assuming this was a permissions problem with apache, I followed an article on slicehost docs and did the following:
sudo chgrp -R www-data /home/kollar/apps/kinfonet/current
sudo chmod -R 2750 /home/kollar/apps/kinfonet/current
sudo chmod -R 2770 /home/kollar/apps/kinfonet/current/log
sudo chmod -R 2770 /home/kollar/apps/kinfonet/shared
sudo chmod -R 2770 /home/kollar/apps/kinfonet/shared/db
sudo chmod -R 2770 /home/kollar/apps/kinfonet/shared/db/sphinx
sudo chmod -R 2770 /home/kollar/apps/kinfonet/shared/pids
THe error is still there and now visitors to the site cannot access their profile pictures which are located in /home/kollar/apps/kinfonet/shared/system/avatars
There is an apache/passenger forbidden error if I call up the path to the image on the browser :
You don't have permission to access /system/avatars/48/thumb_BR.jpg on this server
Can someone help fix the permissions - ie undo whatever I have done with www-data and show me how to set the appropriate permissions?
If you're still seeing the 403 Forbidden error, then you need to tell Apache that it's OK to follow that symlink from your app/current/system to app/shared/system. Ensure you have this in your virtual host definition:
Options FollowSymLinks
Thanks for trying to help.
"What user is running the deploy commands on the remote server? " -- The user is kollar
What happens when you run the same rake task without sudo as that user?
got this to work. Ran a ls-l on shared/db and saw that it was set to root as user and root as group. changed both to my user "kollar" and now rake can run from the cap deploy.rb file without sudo.
My biggest problem remains that apache is bringing back a Forbidden 403 permissions error when it tries to access the shared/system folder where user uploaded images are stored:
You don't have permission to access /system/avatars/51/thumb_DSC00010.JPG on this server.
Apache/2.2.8 (Ubuntu) Phusion_Passenger/2.2.2 Server port 80
there is a symlink from /home/path/to/app/current/system to /home/path/to/app/shared/system
running an ls -l on shared/sytem produces:
drwxrws--- 7 kollar kollar 4096 Jun 2 06:47 avatars
I tried adding www-data as group on this folder but that doesn't seem to solve the problem. Any help on this would be greatly appreciated.