For a long time, when using my computer (Arch linux), I would sometimes run into this problem. When trying to open an application in a new window, I’ll be met by:
Invalid MIT-MAGIC-COOKIE-1 key
cannot open display: :0
I’ve tried a lot of “solutions” without luck, but I’ve finally found a way to consistently reproduce the error. It happens everytime I connect to a new wifi.
I found this 9 year old post about the same problem, but it does not include a real solution or the cause of the problem.
I’ll try asking it here, to see if anybody knows why it happens and how to solve it, and perhaps to help others with the same problem find the cause of this error. It is such a relief for me, knowing that it is caused by changing wifi.
In advance, thanks for the help/feedback :)
Explanation: That comes up when you try to run an X11 application (like, pre-Wayland) that doesn’t have the proper credentials to authenticate to the X11 display server.
X11 was designed to have a display server (the software that slaps the window on a display) that might live on a machine other than the one running the graphical program. Historically, this was intended so that the display server could run on a very limited “thin client” computer.
Since you don’t want arbitrary software on other computers on the network to be able to display things on your display server (and see what’s on your screen, and see your keystrokes, which having access to your display server would also permit), some mechanism of saying which machines have access to your machismo was required. Originally, this was done by restricting the IP address, but because there are some potential ways to attack this, what was settled on was the display server and the machine running the application instead having a shared secret, a “cookie” (this particular approach was developed at MIT, hence the “MIT magic cookie” that you see). I’d expect that to show up if the application and display server don’t have the same cookie.
In practice, today, most people just display their windows on their local machine.
If, in a bash shell (if you’re not familiar with bash, it’s the piece of software probably running when you open a terminal window), you type
echo $DISPLAY, you’ll probably see “:0”. This means “display 0 on localhost”. Something likedisplayserver.foobar.com:1would be on display 1 on the X11 display served running ondisplayserver.foobar.com.Okay, enough explanation. How to fix it?
I’ve never seen this happen when switching WiFi networks, and I’m a little surprised that it shows up for you. The “localhost” hostname should map to 127.0.0.1, which should not be affected by you moving WiFi networks. And I wouldn’t expect you to be using something other than localhost – if you do that transport when not necessary, I think that it might even degrade performance, prevent use of the X11 SHM shared memory extension, which uses shared memory to do rapid data movement between the application and the display server).
The main time I have seen this in the past, it was when I was trying to run software as root after I had run
suto open a shell run by root on a display that I was running as a non-root user. Usually I could resolve that by running, the commandxauth merge ~/.Xauthorityas root. This merges the current user’s cookies (in~username/.Xauthority) into root’s cookies file (in~root/.Xauthority). If that’s what you’re seeing, the same command should also resolve the issue.If not…well, the software that you are trying to run is reaching an X11 server, or the message would be different. It’s either reaching yours or another one, but it lacks the cookie to authenticate itself. I think I’d run
echo $DISPLAYin the shell that I’m trying to run that program from, see what it’s trying to talk to.EDIT: Sorry, looked at your message again. The X11 software package that you’re trying to run is trying to reach “:0”, so it’s not a matter of that being mis-set. Is there any chance that you’re just coincidentally trying to run the program as another user, probably root, and that the WiFi is in fact not related?
Thanks for the answer :)
I’ll look at it tomorrow, when I’m at my computer :)
Typing
xauth merge ~/.Xauthoritydid not work :/However, I managed to reproduce the error by changing from my own phone hotspot to the hotspot of my boyfriend. When changing back from my boyfriend’s hotspot to my own, I could open applications again. I looked at
journalctland I found this. It seems, that when I connect to my boyfriend’s hotspot, my hostname is changed to ‘boyfriend.telephone-company.com’ (changed to preserve a bit of anonymity). When I change back to my own hotspot, the hostname is again changed back to ‘archlinux’. It seems weird. I’ll try to test again later today with other wifi-connections and see if it only happens with my boyfriend’s hotspot. I’ve had some issues with his hotspot before, so it might just be it.When connection to my boyfriend’s hotspot:
Jan 09 10:00:45 archlinux NetworkManager[521]: <info> [1736413245.1806] dhcp6 (wlp4s0): activation: beginning transaction (timeout in 45 seconds) Jan 09 10:00:45 archlinux NetworkManager[521]: <info> [1736413245.1821] policy: set 'Boyfriend - iPhone' (wlp4s0) as default for IPv6 routing and DNS Jan 09 10:00:45 archlinux NetworkManager[521]: <info> [1736413245.2177] dhcp6 (wlp4s0): state changed new lease Jan 09 10:00:47 archlinux systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully. Jan 09 10:00:49 archlinux NetworkManager[521]: <info> [1736413249.7206] policy: set-hostname: set hostname to 'boyfriend.telephone-company.com' (from address lookup) Jan 09 10:00:49 archlinux systemd[1]: Starting Hostname Service... Jan 09 10:00:49 archlinux systemd[1]: Started Hostname Service. Jan 09 10:00:49 boyfriend.telephone-company.com systemd-hostnamed[1812]: Hostname set to <boyfriend.telephone-company.com> (transient) Jan 09 10:00:49 boyfriend.telephone-company.com systemd[1]: Starting Network Manager Script Dispatcher Service... Jan 09 10:00:49 boyfriend.telephone-company.com systemd[1]: Started Network Manager Script Dispatcher Service. Jan 09 10:00:59 boyfriend.telephone-company.com systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully. Jan 09 10:01:19 boyfriend.telephone-company.com systemd[1]: systemd-hostnamed.service: Deactivated successfully.when connecting back to my own hotspot:
Jan 09 10:01:42 boyfriend.telephone-company.com kernel: wlp4s0: authenticated Jan 09 10:01:42 boyfriend.telephone-company.com kernel: wlp4s0: associate with 72:23:ad:c5:e6:0c (try 1/3) Jan 09 10:01:42 boyfriend.telephone-company.com NetworkManager[521]: <info> [1736413302.2633] device (wlp4s0): supplicant interface state: authenticating -> associating Jan 09 10:01:42 boyfriend.telephone-company.com NetworkManager[521]: <info> [1736413302.2633] device (p2p-dev-wlp4s0): supplicant management interface state: authenticating -> associating Jan 09 10:01:42 boyfriend.telephone-company.com systemd[1]: Started Hostname Service. Jan 09 10:01:42 archlinux systemd-hostnamed[1911]: Hostname set to <archlinux> (transient) Jan 09 10:01:42 archlinux kernel: wlp4s0: RX AssocResp from 72:23:ad:c5:e6:0c (capab=0x1431 status=0 aid=1) Jan 09 10:01:42 archlinux wpa_supplicant[574]: wlp4s0: Associated with 72:23:ad:c5:e6:0c Jan 09 10:01:42 archlinux wpa_supplicant[574]: wlp4s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 Jan 09 10:01:42 archlinux kernel: wlp4s0: associated Jan 09 10:01:42 archlinux NetworkManager[521]: <info> [1736413302.2861] device (wlp4s0): supplicant interface state: associating -> associatedHmm.
My hostname doesn’t change on connecting to a WiFi network on my laptop.
But
xauth -n listdoes have entries that appear to reference my hostname and a unix domain socket. And I do see some people apparently having problems with this after modifying their hostname during an X11 session. Maybe the hostname is a factor here, even when not connecting to a remote machine. Huh.pokes around
It looks like the default behavior for NetworkManager is to set the hostname if you don’t have a configured hostname for your machine. I do:
$ cat /etc/hostname talmachine $I’m not sure whether yours is “archlinux” or just not specified and “archlinux” is some sort of default that Arch Linux uses on systems with no hostname set.
If it’s not set and acceptable to you to set a hostname there, that might be the most-reasonable way to address the issue, if you don’t have a hostname set for the machine – go ahead and edit that file as root, set a hostname in that file, boot the system, and see if your issue goes away. I just have a single word on my system (“talmachine”), not a fully-qualified domain name (“talmachine.domain.com”).
It looks like the modern, systemd-friendly way to update a hostname and simultaneously inform running software that the hostname has changed is to run
hostnamectl hostname <hostname>, sohostnamectl hostname talmachineor similar. Should have basically the same effect as editing that file, might cause some software to not need a reboot. I’d probably reboot anyway, cause X11 to produce a new magic cookie and such.Looking at
man NetworkManager.conf, it also looks like it’s possible to instruct NetworkManager to not modify the hostname on connection on hosts that don’t have a hostname set.hostname-mode Set the management mode of the hostname. This parameter will affect only the transient hostname. If a valid static hostname is set, NetworkManager will skip the update of the hostname despite the value of this option. An hostname empty or equal to 'localhost', 'localhost6', 'localhost.localdomain' or 'localhost6.localdomain' is considered invalid. default: NetworkManager will update the hostname with the one provided via DHCP or reverse DNS lookup of the IP address on the connection with the default route or on any connection with the property hostname.only-from-default set to 'false'. Connections are considered in order of increasing value of the hostname.priority property. In case multiple connections have the same priority, connections activated earlier are considered first. If no hostname can be determined in such way, the hostname will be updated to the last one set outside NetworkManager or to 'localhost.localdomain'. dhcp: this is similar to 'default', with the difference that after trying to get the DHCP hostname, reverse DNS lookup is not done. Note that selecting this option is equivalent to setting the property 'hostname.from-dns-lookup' to 'false' globally for all connections in NetworkManager.conf. none: NetworkManager will not manage the transient hostname and will never set it.So I guess, if you don’t want to set a hostname on your system, or one is already set and for some reason you’re still smacking into this, you might also try modifying
/etc/NetworkManager/NetworkManager.confto read something like:[main] hostname-mode=noneThanks so much <3
Turns out I didn’t have a file at
/etc/hostname. I created one and now the problem is gone :)Thanks so much for your help <3
No prob. Glad it worked!
