If you get the error below while you are trying to launch an application under Wine (or even while you just work on Linux without knowing what is or using the Wine):
No protocol specified
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
err:systray:initialize_systray Could not create tray window
then you should know that it has nothing to do with the Wine but with your Linux box. The message is thrown by Linux so Wine just catch it and throw it further. It's not its fault, though.
So what's wrong?
Well, it has something to do with the xhost and the configuration of your Linux profile.
In Linux you can easily connect to other computers and run graphical user interfaces over the network. This is done by xhost which is the X server access control program. The xhost program is used to add and delete host names or user names to the list of machines and users that are allowed to make connections to the X server. This provides a rudimentary form of privacy control and security. This program uses one of five mechanisms that control whether a client application can connect to an X display server. One of them is cookie-based access.
The cookie-based authorization methods are based on choosing an arbitrary piece of data (cookie) and passing it to the server when it is started. If a client application wants to be authenticated to connect the X server it must prove that it has knowledge of this cookie. Note that these cookies are created and stored in the file .Xauthority in the user's home directory. It looks like this one (where eugen-gentoo is the name of my local host):
You can check if this file exists and then if its know by your system. For instance, if you run the command below it should show you the path to your current .Xauthority file:
echo $XAUTHORITY /home/eugen/.Xauthority
If it the command above doesn't show anything in spite of the file being there it could mean that your system is using a different method of authentication or it just doesn't know what/where is your .Xauthority file.
You should also check if the file is owned by you or at least that you have read/write access. If you are not the owner of this file you can't login since you can't read/store your credentials there.
So, how to fix this?
In my case, where I have a x86 chroot-ed installation on top of a Linux x86_64 installation, I chroot-ed in the x86 environment and tried to run some application written for Windows 32-bit. I've got the message above and I've discovered that I have no .Xauthority file on the home directory of the x86 environment. What I did was to copy my existent .Xauthority file that exists on the x86_64 (production) environment to that x86 environment. Yes, I admit, I have a very particular setup but what's important it's the point that I've emphasized. So you should get somehow this file and copy it on your home directory.
Who is creating that .Xauthority file?
It is the X Display Manager (aka xdm) that generates such cookies automatically when this form of access control is used. In my case there was no way that such file exists on the x86 environment since the xdm runs on the x86_64 environment and xdm had no clue about my x86 parallel chroot-ed environment. So it makes sense it existed only on one profile and not on both/all.
Now, if you think that this article was interesting don't forget to rate it. It shows me that you care and thus I will continue write about these things.
Latest posts by Eugen Mihailescu (see all)
- Dual monitor setup in Xfce - January 9, 2019
- Gentoo AMD Ryzen stabilizator - April 29, 2018
- Symfony Compile Error Failed opening required Proxies - January 22, 2018