Insufficient permission to manipulate /usr/local/bin

[wilcosec]

Rancher Desktop Version

0.7.1

Rancher Desktop K8s Version

1.21.7 (stable)

What operating system are you using?

macOS

Operating System / Build Version

macOS Monterey 12.1

What CPU architecture are you using?

arm64 (Apple Silicon)

Windows User Only

No response

Actual Behavior

In Rancher Desktop, Supporting Utilities I have the error Insufficient permission to manipulate /usr/local/bin: Error: EACCES: permission denied, access '/usr/local/bin' and the box next to each supporting utility is greyed out.

This affects only installing supporting utilities from Rancher Desktop. All other functions of Rancher Desktop seem to be working as expected. The utilities work and can interact with the running Kubernetes instance when installed any other way.

Steps to Reproduce

This is a new laptop, first time configuration.

I downloaded Rancher.Desktop-0.7.1.aarch64.dmg from the releases page, opened it, dragged "Rancher Desktop.app" into Applications, and launched it.

It went through the first-time Kubernetes download without issue. Quitting and re-opening Rancher Desktop has not made any difference.

Result

Logs attached in case they're helpful.
background.log
images.log
k3s.log
k8s.log
lima.ha.stderr.log
lima.ha.stdout.log
lima.log
lima.serial.log

Expected Behavior

I expect the Supporting Utilities tab of Rancher Desktop to be able to install the supporting utilities it lists.

Additional Information

No response

[jasjisdo]

IHMO in this case Rancher Desktop should also ask for root access to install the Supporting Utilities.
After the initial installation, it also asked for root access to perform the internal network configuration.
When installing the Supporting Utilities, rancher Desktop should behave analogously and not inconsistently.

Rancher Desktop ask for root access to configure the the internal network

Rancher Desktop ask for root password input

In my view, a good solution would be to ask for root access in the same way when installing the Supporting Utilities.

[mattfarina]

@twillowman thanks for reporting the issue and suggesting a solution.

[spuder]

I'm also running into this on 0.7.0 on OSX Big Sur.

Where should the symlinks point to so we can manually work around it? I'd really like to have docker symlinked to my path.

rancher-desktop/src/k8s-engine/lima.ts

Lines 661 to 673 in 7c0ad62

	protected async showSudoReason(explanations: Array<string>): Promise<void> {
	const bullet = '* ';
	const suffix = explanations.length > 1 ? 's' : '';
	const options: Electron.MessageBoxOptions = {
	message: `Rancher Desktop needs root access to configure its internal network by populating the following location${ suffix }:`,
	type: 'info',
	buttons: ['OK'],
	title: "We'll be asking you to type in your password in the next dialog box.",
	detail: `${ bullet }${ explanations.join(`\n${ bullet }`) }`,
	};
	await Electron.dialog.showMessageBox(options);
	}

rancher-desktop/src/k8s-engine/unixlikeIntegrations.ts

Lines 100 to 124 in f8e59c9

	protected async testUsrLocalBin() {
	try {
	await fs.promises.access(PUBLIC_LINK_DIR, fs.constants.W_OK | fs.constants.X_OK);
	this.#results[PUBLIC_LINK_DIR] = '';
	if (!this.#binWatcher) {
	this.#binWatcher = fs.watch(PUBLIC_LINK_DIR, async(eventType, filename) => {
	if (INTEGRATIONS.includes(filename)) {
	window.send('k8s-integrations', await this.listIntegrations());
	}
	});
	}
	} catch (error) {
	switch (error.code) {
	case 'ENOENT':
	this.#results[PUBLIC_LINK_DIR] = `Directory ${ PUBLIC_LINK_DIR } doesn't exist`;
	break;
	case 'EACCES':
	this.#results[PUBLIC_LINK_DIR] = `Insufficient permission to manipulate ${ PUBLIC_LINK_DIR }: ${ error }`;
	break;
	default:
	this.#results[PUBLIC_LINK_DIR] = `Can't work with directory ${ PUBLIC_LINK_DIR }: ${ error }'`;
	}
	}
	}

[jandubois]

@spuder The problem is the /usr/local/bin no longer exists, or is not owned by yourself. You can fix that by running the following commands in a terminal:

sudo mkdir -p /usr/local/bin
sudo chown $USER /usr/local/bin

The first sudo command will prompt you for your password. Once the directory exists, and is writable by you, RD should be able to create the symlinks.

[spuder]

Thank you. I found that /usr/local/bin does exist on my new M1 mac running Big Sur, but it was owned by root

Running this worked around the issue for me:

sudo chown $USER /usr/local/bin

Once the boxes were clicked, the symlinks that were created for me are at:

ll /usr/local/bin| grep -i rancher
lrwxr-xr-x   1 spencer.owen  wheel         80 Dec 30 22:35 docker@ -> /Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/docker
lrwxr-xr-x   1 spencer.owen  wheel         78 Dec 30 22:35 helm@ -> /Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/helm
lrwxr-xr-x   1 spencer.owen  wheel         77 Dec 30 22:35 kim@ -> /Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/kim
lrwxr-xr-x   1 spencer.owen  wheel         81 Dec 30 22:35 kubectl@ -> /Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/kubectl
lrwxr-xr-x   1 spencer.owen  wheel         81 Dec 30 22:35 nerdctl@ -> /Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/nerdctl

[enceem]

had the same issue but
sudo chown $USER /usr/local/bin
resolved it

[mgudmund]

IMHO /usr/local/bin should be owned by root. So changing it to be owned by $USER is a workaround, not a fix. I would think the solution proposed by @jasjisdo is the right way to do it.

[fungiboletus]

I agree that usr/local/bin should be owned by root. My workaround is to run

sudo chown $USER /usr/local/bin

then I can check the checkboxes in rancher desktop,
and I restore the root owner:

sudo chown root /usr/local/bin

[weaversam8]

Just to add a data point, this issue is still present in 1.0.0-beta1.

[abs1010]

sudo chown $USER /usr/local/bin worked for me. Thanks

[istvandesign]

I confirm that this reproduces on Mac OS Monterey Version 12.1 on a MacBook Pro with M1 Pro. Chown seems a weird solution, I would rather open the entire app as sudo.

[boogi]

The same in version 1.0.0-beta1 on Monterey 12.1. Temporarily changing owner workaround worked for me also.

[selfisekai]

also to note: if installed from Homebrew, the symlinks are generated by Homebrew, but the app doesn't reflect that state.

==> Downloading https://github.com/rancher-sandbox/rancher-desktop/releases/download/v0.7.1/Rancher.Desktop-0.7.1.aarch64.dmg
Already downloaded: /Users/lauren.liberda/Library/Caches/Homebrew/downloads/962f40e4104948f7fc3fc8ba3fb2f4548a9a0257b5a86fc006d4ee0af31f75b2--Rancher.Desktop-0.7.1.aarch64.dmg
==> Installing Cask rancher
==> Moving App 'Rancher Desktop.app' to '/Applications/Rancher Desktop.app'
==> Linking Binary 'helm' to '/opt/homebrew/bin/helm'
==> Linking Binary 'kim' to '/opt/homebrew/bin/kim'
==> Linking Binary 'nerdctl' to '/opt/homebrew/bin/nerdctl'
==> Linking Binary 'kubectl' to '/opt/homebrew/bin/kubectl'
==> Linking Binary 'docker' to '/opt/homebrew/bin/docker'
🍺  rancher was successfully installed!

/opt/homebrew/bin/docker is a symlink to '/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/docker', and so on

[ssheraliev]

It seems that "mucked up" permissions issue on /usr/local/bin directory.
I am on M1 chip and with latest v.1.0.0 version:

Fix would be; adding your user-account into admin group:
sudo chown $(whoami):admin /usr/local/bin

[jt-nti]

I worked around the issue by creating the symlinks manually...

sudo ln -s "/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/docker" /usr/local/bin/docker
sudo ln -s "/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/helm" /usr/local/bin/helm
sudo ln -s "/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/kubectl" /usr/local/bin/kubectl
sudo ln -s "/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/nerdctl" /usr/local/bin/nerdctl

[ex-git]

For Homebrew user, this is the work around. Although you will still see the UI error, all commands will works.

sudo ln -s "/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/docker" /opt/homebrew/bin/docker
sudo ln -s "/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/helm" /opt/homebrew/bin/helm
sudo ln -s "/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/kubectl" /opt/homebrew/bin/kubectl
sudo ln -s "/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/nerdctl" /opt/homebrew/bin/nerdctl

[hcguersoy]

also to note: if installed from Homebrew, the symlinks are generated by Homebrew, but the app doesn't reflect that state.

==> Downloading https://github.com/rancher-sandbox/rancher-desktop/releases/download/v0.7.1/Rancher.Desktop-0.7.1.aarch64.dmg
Already downloaded: /Users/lauren.liberda/Library/Caches/Homebrew/downloads/962f40e4104948f7fc3fc8ba3fb2f4548a9a0257b5a86fc006d4ee0af31f75b2--Rancher.Desktop-0.7.1.aarch64.dmg
==> Installing Cask rancher
==> Moving App 'Rancher Desktop.app' to '/Applications/Rancher Desktop.app'
==> Linking Binary 'helm' to '/opt/homebrew/bin/helm'
==> Linking Binary 'kim' to '/opt/homebrew/bin/kim'
==> Linking Binary 'nerdctl' to '/opt/homebrew/bin/nerdctl'
==> Linking Binary 'kubectl' to '/opt/homebrew/bin/kubectl'
==> Linking Binary 'docker' to '/opt/homebrew/bin/docker'
🍺  rancher was successfully installed!

/opt/homebrew/bin/docker is a symlink to '/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/docker', and so on

This seems to be changed. Installing RD 1.0.1 with brew doesn't create these links:

> brew install rancher 
==> Downloading https://github.com/rancher-sandbox/rancher-desktop/releases/download/v1.0.1/Rancher.Desktop-1.0.1.aarch6
==> Downloading from https://objects.githubusercontent.com/github-production-release-asset-2e65be/306701996/d88f1bff-32e
######################################################################## 100.0%
==> Installing Cask rancher
==> Moving App 'Rancher Desktop.app' to '/Applications/Rancher Desktop.app'
🍺  rancher was successfully installed!

Checking /opt/homebrew/bin shows that these links doesn't exist.
I'm on Apple Silicon, too.

[ab-mohamed]

I did the following workaround steps:

1. After installing Rancher Desktop, I ran the following script:

#!/bin/bash
for BINARY in docker helm kubectl nerdctl
do
  sudo ln -s /Applications/Rancher\ Desktop.app/Contents/Resources/resources/darwin/bin/${BINARY} /usr/local/bin
  sudo chown -h $USER /usr/local/bin/${BINARY}
done

2. The new symbolic links look like the following:

$ ls -lh /usr/local/bin
total 0
lrwxr-xr-x  1 ab    wheel    80B Feb  6 17:24 docker -> /Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/docker
lrwxr-xr-x  1 ab    wheel    78B Feb  6 17:24 helm -> /Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/helm
lrwxr-xr-x  1 ab    wheel    81B Feb  6 17:24 kubectl -> /Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/kubectl
lrwxr-xr-x  1 ab    wheel    81B Feb  6 17:24 nerdctl -> /Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin/nerdctl

And all supporting utilities are checked even if you do not have proper permission for /usr/local/bin directory:

3. kubectl command, for example, works fine now:

$ kubectl get nodes
NAME                   STATUS   ROLES                  AGE     VERSION
lima-rancher-desktop   Ready    control-plane,master   2d18h   v1.22.6+k3s1

Note: You have to remove the symbolic links in the /usr/local/bin directory manually if you remove Rancher Desktop.

[priiiiit]

Lots of bad workaround recommended here. Please do not chown your /usr/local/bin to your $USER, but if you indeed decide this is the only way, then please change it back as soon as possible.

[hcguersoy]

In such cases I prefer to add the path in the .zshrc or, in this case, defining aliases in the same file pointing to the specific binaries.

[ssheraliev]

Lots of bad workaround recommended here. Please do not chown your /usr/local/bin to your $USER, but if you indeed decide this is the only way, then please change it back as soon as possible.

Could you explain why and how would you fix instead of workaround?

[jandubois]

Note that all the Rancher Desktop shortcuts go to the same directory, so you could put that directory in your PATH in the ~/.profile corresponding to your shell. This doesn't even require sudo.

This is what happens with the Windows version¹; the directory is added at the end of the PATH, so the user can override the bundled version by installing them into a directory earlier on the PATH.

You can also put the name of that directory into a /etc/pathd.d file, and for the supported shells, it will be put on the PATH automatically. Creating the file requires sudo though:

$ cat /etc/paths.d/rancher-desktop
/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin

Note that you will have to deal with shadowing on your PATH yourself then. E.g. if you also install Docker Desktop, it may put symlinks into /usr/local/bin any time you start it (via its privileged helper process), which may then hide the versions from Rancher Desktop.

It's kind of hard to find a one-size-fits-all solution for this issue.

Footnotes

1. On Windows we actually put both the Windows and the Linux versions of the utilities at the end of the PATH. Since the Windows versions have an extra .exe file extension, they don't shadow each other, and both Windows command prompts, and WSL shells will automatically invoke the right version. ↩

[priiiiit]

Lots of bad workaround recommended here. Please do not chown your /usr/local/bin to your $USER, but if you indeed decide this is the only way, then please change it back as soon as possible.

Could you explain why...

That's really Linux/Unix administration 101 and goes against basic security practices. The permissions of /usr/local/bin are set that way for a reason. Going into more detail would be offtopic in this thread, but you can read more from the links below.

• https://askubuntu.com/a/955528
• https://unix.stackexchange.com/a/37726
• https://apple.stackexchange.com/questions/1393/are-my-permissions-for-usr-local-correct

... and how would you fix instead of workaround?

I don't have a proper fix at the moment, but installing those tools manually, even with Homebrew, seems to be a more sane workaround. Unfortunately I just upgraded my MacOS to 12.3 Beta, which seems to have completely broken Rancher, so I'm unable to give a step-by-step instructions for this workaround.

[mateka]

As a workaround, I have run Rancher Desktop from a terminal as a root. Then, I have installed the missing tools, stopped Rancher Desktop and run it normally.

[jandubois]

but installing those tools manually, even with Homebrew, seems to be a more sane workaround.

How is this more sane? On Intel Macs this will change the ownership of /usr/local/bin to $USER so brew install works without sudo, which is just what you are arguing against.

But whatever you do, please do not run Rancher Desktop as root; this may let it create other files that will then be owned by root and not be modifiable by your regular user. It will just create more pain for you down the road. Add the directory to your PATH manually as I explained above.

[mateka]

I have started Rancher Desktop as a normal user and created lima VM. They I have started it as a root (starting VM failed), installed nerdctl and switched back to normal user. I could not used brew, because there is no nerdctl for Apple Silicon.

I am using brew for other tools, but /usr/local/bin is still owned by root. In FAQ (https://docs.brew.sh/FAQ) they say, that brew uses MacOS sandbox and do not chown /usr/local/bin to $USER.

[priiiiit]

Brew does not change the ownership of /usr/local/bin to $USER. Maybe it did at some point, but not currently.

[jandubois]

Brew does not change the ownership of /usr/local/bin to $USER. Maybe it did at some point, but not currently.

Did you actually try it? I just did (on a pristine VM running Big Sur), and you'll be surprised to see this:

jan@Jans-Mac ~ % ls -la /usr/local
total 0
drwxr-xr-x   2 root  wheel   64  1 Jan  2020 .
drwxr-xr-x@ 11 root  wheel  352  1 Jan  2020 ..
jan@Jans-Mac ~ % /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
==> Checking for `sudo` access (which may request your password)...
Password:

[...]

==> Next steps:
- Run brew help to get started
- Further documentation:
    https://docs.brew.sh

jan@Jans-Mac ~ % ls -la /usr/local                                                                              
total 0
drwxr-xr-x  14 root  wheel  448  8 Feb 10:48 .
drwxr-xr-x@ 11 root  wheel  352  1 Jan  2020 ..
drwxrwxr-x   2 jan   admin   64  8 Feb 10:48 Caskroom
drwxrwxr-x   2 jan   admin   64  8 Feb 10:48 Cellar
drwxrwxr-x   2 jan   admin   64  8 Feb 10:48 Frameworks
drwxr-xr-x  22 jan   admin  704  8 Feb 10:51 Homebrew
drwxrwxr-x   3 jan   admin   96  8 Feb 10:51 bin
drwxrwxr-x   3 jan   admin   96  8 Feb 10:54 etc
drwxrwxr-x   2 jan   admin   64  8 Feb 10:48 include
drwxrwxr-x   2 jan   admin   64  8 Feb 10:48 lib
drwxrwxr-x   2 jan   admin   64  8 Feb 10:48 opt
drwxrwxr-x   2 jan   admin   64  8 Feb 10:48 sbin
drwxrwxr-x   6 jan   admin  192  8 Feb 10:54 share
drwxrwxr-x   3 jan   admin   96  8 Feb 10:48 var

When you think about it, how could brew install ... install something into /usr/local/bin unless it is writable by the user? Brew is not using sudo to install anything.

Note that I said Intel Macs; the install location is different on M1 Macs, and on Linux, so obviously it won't change the ownership of /usr/local/bin if it doesn't write to it.

[priiiiit]

I stand corrected. Did not realise there is such difference between Apple Silicon vs Intel.

[pboushy]

NOTE - this issue exists across both M1 and Intel-based Macs running macOS Monterey.
It is not unique to M1.

Rather than setting the permissions to the current user, I'd recommend people use this command:
chown :admin /usr/local/admin
chmod 775 /usr/local/admin

It grants all admins on the computer write access to /usr/local/bin without changing the primary owner of the files.

That being said, this needs to be updated to not require changing permissions. Rancher Desktop needs to request permission to add items to the folder.

[chancez]

Simple one-liner for those who were looking for it based on the suggestion here: #1155 (comment)

echo '/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin' | sudo tee /etc/paths.d/rancher-desktop

[victor-v-rad]

My workaround for RD 1.0.1:

1. Factory reset
2. Delete files described here [macOS] Suggestion: "Factory Reset" button should remove /etc/sudoers.d/rancher-desktop-lima #1128
3. sudo chown $USER /usr/local/bin
4. Reinstall Rancher Desktop. Now it asks for permissions again and creates necessary links in /usr/local/bin
5. sudo chown root /usr/local/bin

[lazyfrosch]

I would suggest this permission change, or ask for sudo to manipulate these links.

sudo chgrp admin /usr/local/bin
sudo chmod g+w /usr/local/bin

[pboushy]

I would suggest this permission change, or ask for sudo to manipulate these links.

sudo chgrp staff /usr/local/bin
sudo chmod g+w /usr/local/bin

I highly recommend against that. That would grant ALL users on the Mac access to write to /usr/local/bin.
That’d allow any attacker/malware to write to a spot that users would run with fairly little protection.

Setting the group to admin provides similar protection as wheel without requiring sudo.

[lazyfrosch]

Setting the group to admin provides similar protection as wheel without requiring sudo.

I was under the assumption that staff is an admin group

[thumperward]

Changing the permissions on a MacOS system directory is categorically not the right approach here. Could people please stop spamming this issue with inane workarounds?

[jandubois]

@thumperward Please tone down your language a little. While some workarounds are less desirable than others, there is no need to insult people who are trying to help.

Please see #1155 (comment) for workarounds that don't involve running Rancher Desktop as root (you absolutely should not be doing that), or changing the ownership of /usr/local/bin, which could have security implications (that some users find acceptable).

[jandubois]

I was under the assumption that staff is an admin group

staff is the group of all locally defined users (there many non-user local accounts that are not in staff). It is a subset of everybody, which also includes accounts defined by directory services.

The admin group is assigned to all accounts that have admin rights.

[jarrellmark]

This could be fixed by linking to the binaries in /opt/rancher-desktop/bin and adding /opt/rancher-desktop/bin to the PATH. /opt/rancher-desktop/bin exists after installing Rancher Desktop.

1. Install Rancher Desktop
2. % cd /opt/rancher-desktop/bin
3. % sudo ln -s "/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin"/* .
4. printf "\n# Rancher Desktop\nexport PATH=\"/opt/rancher-desktop/bin:\$PATH\"\n\n" >> ~/.zshrc

This way /usr/local/bin doesn't need to be touched.

I'd recommend Rancher Desktop do something like this by default. It's similar to how mambaforge and homebrew work.

For example:

% ls -l /opt
                                                                                 
total 0
drwxr-xr-x  32 jarrellmark  admin  1024 Feb 22 19:23 homebrew
drwxr-xr-x   4 root      wheel   128 Mar 21 12:27 rancher-desktop

% cat ~/.zshrc

# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/Users/jarrellmark/mambaforge/bin/conda' 'shell.zsh' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
    eval "$__conda_setup"
else
    if [ -f "/Users/mjarrell/jarrellmark/etc/profile.d/conda.sh" ]; then
        . "/Users/mjarrell/jarrellmark/etc/profile.d/conda.sh"
    else
        export PATH="/Users/jarrellmark/mambaforge/bin:$PATH"
    fi
fi
unset __conda_setup
# <<< conda initialize <<<

[Mazorius]

They could also user ~/bin to symlink the executables instead of provide them system wide. But do not know the impact then :) So maybe this is not a good solution. I like the approach of @jarrellmark THANKS!

[jandubois]

This could be fixed by linking to the binaries in /opt/rancher-desktop/bin and adding /opt/rancher-desktop/bin to the PATH. /opt/rancher-desktop/bin exists after installing Rancher Desktop.

This is pretty close to what we will be doing in the next release: All binaries will be sym-linked into ~/.rd/bin, and the app will offer to add that directory to your PATH via your shell profile (should support at least bash, fish, zsh).

You can of course decline and do this yourself, if you want more control over where to place the directory relative to your other directories on the PATH.

[opensource21]

Simple one-liner for those who were looking for it based on the suggestion here: #1155 (comment)

echo '/Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/bin' | sudo tee /etc/paths.d/rancher-desktop

I think additional a sudo chmod o+r /etc/paths.d/rancher-desktop is necessary.

[adamkpickering]

This has been addressed. The fix will be included in the upcoming 1.3.0. For more information please see #1732.