rancher-desktop: rancher-desktop fails to start on macOS with `sudo: a password is required` while running lima

Actual Behavior

Rancher desktop is failing to start due to lima error

Steps to Reproduce

  1. Open Rancher desktop
  2. Make mac laptop sleep
  3. Open again, quit Rancher desktop and start it again
  4. Encountering this error

Some times restarting the laptop (instead of sleep) makes it work again, but it’s not consistent. Most of the times it keeps having lima errors.

Result

Screen Shot 2022-03-15 at 10 25 30

Expected Behavior

Rancher desktop starting without issues

Additional Information

lima.log

2022-03-15T01:31:17.852Z: Running command limactl list --json...
2022-03-15T01:31:20.721Z: Running command limactl list --json...
2022-03-15T01:31:21.449Z: Running command limactl sudoers --check...
"/private/etc/sudoers.d/zzzzz-rancher-desktop-lima" is up-to-date (or sudo doesn't require a password)
2022-03-15T01:31:21.710Z: Running command limactl list --json...
2022-03-15T01:31:21.968Z: Running command limactl start --tty=false 0...
time="2022-03-15T10:31:22+09:00" level=info msg="Using the existing instance \"0\""
time="2022-03-15T10:31:22+09:00" level=info msg="Starting switch daemon for \"shared\" network"
time="2022-03-15T10:31:22+09:00" level=fatal msg="failed to run [sudo --user root --group wheel --non-interactive /bin/mkdir -m 775 -p /private/var/run/rancher-desktop-lima]: stdout=\"\", stderr=\"sudo: a password is required\\n\": exit status 1"
2022-03-15T01:31:22.260Z: + limactl start --tty=false 0
2022-03-15T01:31:22.261Z: Error: /Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/lima/bin/limactl exited with code 1
2022-03-15T01:31:22.261Z: Error starting lima: Error: /Applications/Rancher Desktop.app/Contents/Resources/resources/darwin/lima/bin/limactl exited with code 1
    at ChildProcess.<anonymous> (/Applications/Rancher Desktop.app/Contents/Resources/app.asar/dist/app/background.js:1:8692)
    at ChildProcess.emit (node:events:394:28)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12)

Seems like it’s the same as this #1615

Rancher Desktop Version

1.1.1

Rancher Desktop K8s Version

1.22.7

Which container runtime are you using?

moby (docker cli)

What operating system are you using?

macOS

Operating System / Build Version

Big Sur 11.6.4

What CPU architecture are you using?

x64

Linux only: what package format did you use to install Rancher Desktop?

No response

Windows User Only

No response

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Reactions: 11
  • Comments: 23 (5 by maintainers)

Most upvoted comments

Hi, do:

sudo vi /private/etc/sudoers.d/sudoers

On this file add/modify replacing it by your username:

your_user_name ALL=(ALL) NOPASSWD: ALL

Save and restart Rancher Desktop

It seem like recent versions of macOS is missing the /private/etc/sudoers.d/directory. And the install script fails when it doesn’t exist.

Create the directory and then restart Rancher Desktop worked for me!

sudo mkdir /private/etc/sudoers.d

This workaround did the trick:

chmod 775 /private/var/run/rancher-desktop-lima

FYI I noticed that it fails when I’m not connected to the company VPN. After connecting to the VPN it can start successfully.

That is what my team noticed too. We don’t have any extra corporate configuration for sudoers.

I believe this is a bug (or a really annoying feature?) of domain-bound Macs. sudo checks with the directory service, which seems to ignore local group information after a reboot if it can’t resolve from the domain. In this case, Rancher Desktop startup fails because the %everyone ... NOPASSWD: sudo rules in zzzzz-rancher-desktop-lima aren’t matched for my user, even though id shows I am a member of the everyone group.


~On this file add/modify replacing it by your username:~ ~your_user_name ALL=(ALL) NOPASSWD: ALL~

Please don’t do that. It allows any program running as your user to escalate privileges and run any command without your password.

I’ve added the following to my personal rules in sudoers.d to work around the annoyance. (The first two rules could be combined, but I’ve left them separate to match zzzzz-rancher-desktop-lima.)

# Overrides to support starting rancher-desktop after reboot without VPN.
my_user ALL=(root:wheel) NOPASSWD:NOSETENV: /bin/mkdir -m 775 -p /private/var/run
my_user ALL=(root:wheel) NOPASSWD:NOSETENV: /opt/rancher-desktop/bin/vde_vmne, /usr/bin/pkill -F /private/var/run/*.pid
my_user ALL=(daemon:everyone) NOPASSWD:NOSETENV: /opt/rancher-desktop/bin/vde_switch, /usr/bin/pkill -F /private/var/run/*.pid

FYI I noticed that it fails when I’m not connected to the company VPN. After connecting to the VPN it can start successfully.

There’s other issues we are facing when using Rancher Desktop that we did not have before when using Docker Desktop, but it’s not related to this.

Again, thanks for your support!

FYI I noticed that it fails when I’m not connected to the company VPN. After connecting to the VPN it can start successfully.

That is what my team noticed too. We don’t have any extra corporate configuration for sudoers.

I believe this is a bug (or a really annoying feature?) of domain-bound Macs. sudo checks with the directory service, which seems to ignore local group information after a reboot if it can’t resolve from the domain. In this case, Rancher Desktop startup fails because the %everyone ... NOPASSWD: sudo rules in zzzzz-rancher-desktop-lima aren’t matched for my user, even though id shows I am a member of the everyone group.

~On this file add/modify replacing it by your username:~ ~your_user_name ALL=(ALL) NOPASSWD: ALL~

Please don’t do that. It allows any program running as your user to escalate privileges and run any command without your password.

I’ve added the following to my personal rules in sudoers.d to work around the annoyance. (The first two rules could be combined, but I’ve left them separate to match zzzzz-rancher-desktop-lima.)

# Overrides to support starting rancher-desktop after reboot without VPN.
my_user ALL=(root:wheel) NOPASSWD:NOSETENV: /bin/mkdir -m 775 -p /private/var/run
my_user ALL=(root:wheel) NOPASSWD:NOSETENV: /opt/rancher-desktop/bin/vde_vmne, /usr/bin/pkill -F /private/var/run/*.pid
my_user ALL=(daemon:everyone) NOPASSWD:NOSETENV: /opt/rancher-desktop/bin/vde_switch, /usr/bin/pkill -F /private/var/run/*.pid

This perfectly worked for me. I just replaced my_user, restarted the rancher desktop and the magic is done. Thanks a lot.

FYI I noticed that it fails when I’m not connected to the company VPN. After connecting to the VPN it can start successfully.

There’s other issues we are facing when using Rancher Desktop that we did not have before when using Docker Desktop, but it’s not related to this.

Again, thanks for your support!

That did the trick for mine to work !!!

My apologies, I misread. It is not a duplicate of #1812 and #1815.

It does seem to be a duplicate of #1615, meaning your system cannot be configured to allow password-less sudo for specific commands (e.g. your company has added a rule that prevents this).

Unfortunately we don’t have a workaround for this. #1224 summarizes all the tasks we need to do to make Rancher Desktop more flexible regarding root/admin requirements, but those will take a while to implement.