Open AlexeyRaga opened 2 years ago
It is not Rancher Desktop, but mDNSResponder that is taking over port 53. It is a macOS component that is automatically started when Rancher Desktop uses Apple's vmnet framework.
It is being used to get a routable IP address for the VM running the container engine. If you are fine with just using port forwarding to the host and don't require a separate IP address, then you can disable "administrative access" in the Rancher Desktop preferences. Using vmnet requires starting a daemon via sudo
, so that is no longer possible, and mDNSResponder will no longer be started either.
This means that Rancher Desktop will also no longer be able to create the Docker socket in the default location at /var/run/docker.sock
. It will create a docker context called rancher-desktop
and switch to it automatically, so things should still work automatically. But it is good to be aware of this, in case you are running legacy software that doesn't know about docker contexts and expects to find the socket in the default location.
@jandubois thank you very much for the explanation and for the workaround! This solution works and I close this issue.
Added benefit of the "workaround":
You no longer get prompted for your password the first time you start Rancher Desktop after rebooting your machine (because macOS deletes /var/run
on boot, so normally Rancher Desktop would have to recreate the /var/run/docker.sock
socket).
Hi @jandubois - I'm on macOS (Sonoma 14.3), on Apple Silicon (M3, incase that's important, so having to use VZ emulation), latest RD 1.12.2 (but same on 1.12.1) and I cannot get this workaround to work.
I've disabled admin access, tried with and without socket-vmnet
and starting Rancher Desktop always causes mDNSResponder
to be started on port 53, which then causes conflicts with Cloudflare WARP, as noted by @AlexeyRaga in the issue description.
My steps are to quit completely out of RD and verify that there are no RD processes running with psgrep -i rancher
and no mDNSResponder
processes with sudo lsof -P -i tcp:53
, then start RD with the correct settings (ie no admin, etc.) and it always starts mDNSResponder
:
❯ sudo lsof -P -i tcp:53
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mDNSRespo 657 _mdnsresponder 47u IPv4 0xfdf805139f33ed63 0t0 TCP *:53 (LISTEN)
mDNSRespo 657 _mdnsresponder 49u IPv6 0xfdf8051860f7a8d3 0t0 TCP *:53 (LISTEN)
Edits:
Should I open a new issue with these details, or are you able to assist with this information please?
@jandubois - I've been able to test the issue I reported above on an M1 laptop and have confirmed it's the VZ emulation settings (to work around #5943 on M3).
Using default QEMU virtual machine type, which obviously breaks on M3, it does not start the mDNSResponder
. Change it back to VZ and even without admin access it starts mDNSResponder
on port 53.
Any ideas?
Using default QEMU virtual machine type, which obviously breaks on M3, it does not start the
mDNSResponder
. Change it back to VZ and even without admin access it startsmDNSResponder
on port 53.
Yes, because under VZ emulation Rancher Desktop uses vzNAT
networking, which doesn't require admin access, but still uses VMNET, so will always start mDNSResponder
.
Sorry, I can't think of a workaround for VZ mode right now. I'll re-open this issue so we'll look at it again in the future.
Hi @jandubois - thanks for the quick response 👍.
As I mentioned above, the manual workaround I used was to quit Rancher Desktop, then run and connect Cloudflare WARP, so it can bind on port 53, before running RD again. This seems to work, but is it possible Rancher Desktop is broken in some way I haven't discovered yet by not being able to run mDNSResponder
? There don't appear to be any other mDNSResponder
processes created, or errors that I can see in the RD logs.
is it possible Rancher Desktop is broken in some way I haven't discovered yet by not being able to run
mDNSResponder
?
I don't think so; Rancher Desktop doesn't use mDNSResponder
itself at all. I'm also not sure why it binds to port 53
as the mDNS port is 5353
. So I think letting your VPN bind to the port before starting Rancher Desktop should work fine.
It is possible that not running mDNSResponder
will prevent you from resolving names in the *.local
domain.
Actual Behavior
I have
Rancher Desktop
running on MacOS indockerd (moby)
mode withKubernetes
andTraefik
being both disabled.I see that when Rancher is running, port 53 on my machine is taken:
but when I shut it down then port 53 is free again. Despite the fact that the process name and PID are different, Rancher is definitely causes the port to be taken.
Steps to Reproduce
Rancher Desktop
indockerd (moby)
mode and switch offKubernetes
andTraefik
.sudo lsof -PiTCP -sTCP:LISTEN
commandResult
Other services on the machine cannot use port 53. Noticing VPN clients (like Cloudflare WARP) and other DNS-related tools.
Expected Behavior
Port 53 is not taken over by
Rancher Desktop
(the same wayDocker Desktop
doesn't take over it)Additional Information
No response
Rancher Desktop Version
1.5.1
Rancher Desktop K8s Version
none
Which container engine are you using?
moby (docker cli)
What operating system are you using?
macOS
Operating System / Build Version
12.5.1 (21G83)
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