Mastering the “xhost: unable to open display” Error on Ubuntu 20.04: A Comprehensive Guide from revWhiteShadow #

Encountering the frustrating “xhost: unable to open display” error on your local Ubuntu 20.04 system can be a significant roadblock, especially when you’re attempting to interact with graphical applications or manage your display environment. At revWhiteShadow, we understand the intricacies of the X Window System and are dedicated to providing in-depth solutions to help you navigate these challenges. This comprehensive guide will dissect the root causes of this common error and offer a robust, step-by-step approach to resolving it, ensuring you regain full control over your graphical sessions. We aim to provide a level of detail and clarity that will empower you to overcome this issue definitively.

Understanding the Foundation: X Window System, Display Managers, and Xauthority #

Before diving into the troubleshooting steps, it’s crucial to grasp the fundamental concepts at play. The X Window System, often referred to as X11 or X, is the underlying technology that enables graphical user interfaces on Unix-like operating systems, including Ubuntu. It operates on a client-server model, where the X server manages the display hardware and input devices, and X clients are the applications that want to draw on the screen.

A Display Manager (like GDM, LightDM, or SDDM) is responsible for starting the X server, handling user logins, and managing X sessions. When you log in graphically, the display manager initiates your desktop environment and sets up the necessary environment variables for graphical applications to function.

The Xauthority file is a crucial component for secure X11 connections. It contains authentication cookies that X clients use to prove their identity to the X server. Each X session typically has its own Xauthority file, usually located in a path like /run/user/<UID>/gdm/Xauthority or ~/.Xauthority. When you try to connect to an X display, the client checks this file for a valid cookie.

The xhost command is a utility used to control access to an X server. It maintains an access control list (ACL) that specifies which clients are allowed to connect to the server. Using xhost + or xhost +local: temporarily disables access control, allowing connections from any host or local connections, respectively. However, improper configuration or timing issues with this file can lead to the “unable to open display” error.

Deconstructing the “xhost: unable to open display” Error on Local Ubuntu 20.04 #

The error message “xhost: unable to open display “desktop:0"” or variations like “Error: Can’t open display: :0” or “:0.0” indicate that the X client (in this case, xhost itself, but the principle applies to any graphical application) cannot establish a connection to the X server. This inability stems from a failure to authenticate or locate the correct X display.

Based on the detailed information you’ve provided, particularly the observation that you are on a local machine and not using SSH, and the behavior of your Xauthority files, we can pinpoint several likely causes and corresponding solutions.

1. Understanding the DISPLAY Environment Variable #

The DISPLAY environment variable tells X clients which X server to connect to. It’s typically set to :0, :0.0, or localhost:0 for a local display. The format desktop:0 is unusual for a local session, as desktop is not a recognized hostname or network address in this context. Your attempts to use export DISPLAY=desktop:0 are likely contributing to the problem.

2. The Role of Xauthority and Authentication Cookies #

The Invalid MIT-MAGIC-COOKIE-1 key error, which you’ve observed in conjunction with the “Can’t open display” messages, directly points to an authentication issue. This means the X client successfully identified a potential X server but was unable to present a valid cookie from the Xauthority file to prove its identity.

Your observation that Xauthority files like /run/user/1000/gdm/Xauthority-c and /run/user/1000/gdm/Xauthority-l disappear after restarting the display manager, and that xauth can be called successfully after a reboot using /run/user/1000/gdm/Xauthority, is highly informative. This suggests a race condition or timing issue where applications or commands might be looking for the X server before it’s fully initialized or before the correct Xauthority file is definitively established and accessible.

The “weird characters” in your Xauthority file, such as gokuMIT-MAGIC-COOKIE-1R��9��s{�H��H�l��gokuMIT-MAGIC-COOKIE-1R��9��s{�H��H�l, strongly indicate that the file content is corrupted or malformed. This corruption prevents X clients from parsing it correctly to extract the authentication cookie.

Comprehensive Solutions to Resolve “xhost: unable to open display” #

We will now outline a series of methodical steps to address this error, starting with the most probable causes and progressing to more involved diagnostics.

## Ensuring Correct DISPLAY Environment Variable Configuration #

The first and most fundamental step is to ensure your DISPLAY environment variable is correctly set for your local session.

#### Verifying and Setting the DISPLAY Variable #

For local X sessions, the DISPLAY variable should typically be set to :0 or :0.0. The desktop:0 you are using is not standard for a local connection.

1. Check the current DISPLAY value:

   echo $DISPLAY
   

   If it shows desktop:0, desktop:0.0, or is unset, this needs to be corrected.

2. Set the DISPLAY variable correctly for the current session:

   export DISPLAY=:0
   

   or

   export DISPLAY=:0.0
   

   Try running your X client (e.g., xclock) after setting this.

#### Understanding Default Display Assignments #

The X server typically listens on display :0. When you are on a local machine and not using SSH with X forwarding, the DISPLAY variable usually defaults to :0. If you are explicitly setting it, ensure it matches the active X server’s display number.

## Resolving Xauthority Issues and Authentication Failures #

The presence of Invalid MIT-MAGIC-COOKIE-1 key and corrupted Xauthority files points to authentication problems.

#### Regenerating or Correcting the Xauthority File #

Corrupted Xauthority files are a primary culprit for Invalid MIT-MAGIC-COOKIE-1 key errors. Since you’ve observed that Xauthority files (-c, -l) disappear after restarting display-manager, and that xauth works after reboot using the primary Xauthority file, it suggests a re-initialization issue.

Method 1: Restarting and Re-initializing the X Server and Display Manager

A clean restart can often resolve transient issues with Xauthority file creation and access.

1. Log out of your graphical session. This is crucial to ensure a clean slate.

2. Switch to a TTY: Press Ctrl + Alt + F1 (or any other F key from F1 to F6). You will see a text-based login prompt.

3. Log in with your username and password.

4. Restart the display manager service:

   sudo systemctl restart display-manager
   

   This command restarts the service responsible for managing your graphical login and X server.

5. Verify Xauthority existence: After the display manager restarts, it should create or manage the Xauthority file correctly. Check for its presence:

   ls /run/user/1000/gdm/Xauthority*
   

   Ideally, you should see /run/user/1000/gdm/Xauthority. The -c and -l variants are often temporary or intermediate files, and their absence after a restart isn’t inherently problematic if the main Xauthority is present and functional.

6. Try running an X client from this TTY: First, ensure the DISPLAY is set correctly and the XAUTHORITY path is implicitly or explicitly used. Since you are logged into a TTY, you might need to set XAUTHORITY explicitly if the system doesn’t pick up the correct one for your user.

   export DISPLAY=:0
   export XAUTHORITY=/run/user/1000/gdm/Xauthority
   xclock
   

   If xclock displays correctly here, then the issue was likely with how your original session or application was picking up these variables.

7. Switch back to your graphical session: Press Ctrl + Alt + F7 (or the F key corresponding to your graphical session, often F7). Log in to your desktop as usual.

Method 2: Explicitly Setting XAUTHORITY

If the system isn’t correctly setting the XAUTHORITY path for your user’s graphical session, you can try setting it manually. You’ve already attempted this, but let’s ensure it’s done within a context where the X server is definitely running and has its Xauthority file available.

1. Identify the correct Xauthority file: After a successful reboot and login, confirm the path to the active Xauthority file for your user ID (1000). Based on your logs, /run/user/1000/gdm/Xauthority seems to be the intended file.
2. Set the XAUTHORITY environment variable:

   export XAUTHORITY=/run/user/1000/gdm/Xauthority
   

3. Ensure DISPLAY is also set:

   export DISPLAY=:0
   

4. Test an X application:

   xclock
   

   or

   xhost +local:
   

   If this works, you’ll need to ensure these environment variables are set correctly at the start of your graphical session. This might involve adding them to your ~/.bashrc, ~/.profile, or specific session startup scripts, though ideally, the display manager handles this.

Method 3: Regenerating Xauthority using xauth (with caution)

If the Xauthority file is severely corrupted and the above methods don’t resolve it, you might consider regenerating it. However, this should be a last resort.

1. Log out of your graphical session and switch to a TTY (Ctrl + Alt + F1).
2. Remove the potentially corrupted Xauthority file:

   rm /run/user/1000/gdm/Xauthority
   

   Also remove any related files like Xauthority-c and Xauthority-l if they exist at this point.
3. Restart the display manager:

   sudo systemctl restart display-manager
   

4. Log back into your graphical session (Ctrl + Alt + F7). The display manager should create a new, clean Xauthority file.
5. Test your X applications.

Important Note on Xauthority Corruption: The presence of seemingly random characters in your Xauthority file suggests potential issues with disk I/O, filesystem corruption, or a severe bug in the X server or display manager process that handles its creation. If this corruption reappears, it might indicate a deeper system instability.

## Correcting xhost Access Control #

The xhost command itself can cause access issues if not used correctly.

#### Understanding xhost +local: vs. xhost + #

• xhost +local:: This allows connections from any user on the local machine. This is generally safer than xhost +.
• xhost +: This allows connections from any host on any network. This is highly insecure and should almost never be used.

#### Resetting xhost Access Control #

If you’ve previously run xhost + and now want to revert to more restrictive settings, you can use:

1. To allow only trusted local connections:

   xhost +local:
   

   Then, try your graphical application.

2. To disable all xhost access control (and rely on Xauthority):

   xhost -
   

   This command resets the access control list to its default, which usually means only the client that started the X server can connect, and others need an Xauthority cookie. After running xhost -, you should rely on your XAUTHORITY and DISPLAY variables.

#### The Interplay of xhost and Xauthority #

It’s important to understand that xhost and Xauthority are two different, though sometimes overlapping, mechanisms for X11 access control.

• xhost controls network access based on host and user.
• Xauthority controls access on a per-connection basis using encrypted cookies.

When you get Invalid MIT-MAGIC-COOKIE-1 key, it means Xauthority is the primary issue. When you get xhost: unable to open display, it can mean either xhost access control is blocking it, or more commonly, the DISPLAY variable is incorrect, or the X server isn’t running or reachable at the specified DISPLAY.

Given your observation that xhost +mona also fails with Invalid MIT-MAGIC-COOKIE-1 key, it reinforces that the Xauthority file is the central problem. The xhost command itself needs to connect to the X server to update its ACL, and that connection is failing due to the Xauthority issue.

## Verifying the X Server Status #

Ensure that the X server is actually running and that your graphical session is active.

#### Checking for Running X Server Processes #

You can check for X server processes (usually Xorg or Xwayland) using ps:

ps aux | grep Xorg
ps aux | grep Xwayland

You should see at least one such process running if your graphical session is active.

## Advanced Troubleshooting and Potential System-Level Issues #

If the above steps do not resolve the issue, we need to consider more advanced possibilities.

#### User Permissions and Ownership #

Ensure that your user account (UID 1000, mona) has the correct permissions for the relevant directories and files. Your output shows you are mona with UID 1000, which is standard. However, if any permissions were inadvertently changed, it could cause problems.

• Check permissions on /run/user/1000/:

  ls -ld /run/user/1000/
  

  It should be owned by mona mona.

• Check permissions on /run/user/1000/gdm/:

  ls -ld /run/user/1000/gdm/
  

  This directory should also be owned by mona mona.

#### Systemd User Session and logind #

The logind service manages user sessions, and systemd --user is responsible for user-specific services and environments. The correct setup of user sessions is critical for managing X authority files.

• Check user session status:

  systemctl --user status graphical-session.target
  

  This should indicate that your graphical session is active.

#### Xorg Configuration Issues #

While less common for a standard Ubuntu desktop, misconfigurations in Xorg’s configuration files could potentially lead to startup issues or incorrect display handling. These files are typically located in /etc/X11/xorg.conf.d/. However, without any custom configurations, it’s unlikely to be the cause.

#### Wayland vs. X11 #

Ubuntu 20.04 defaults to X11, but newer versions might experiment with Wayland. If you are on a system that might have Wayland enabled, Wayland handles display security differently. The xhost and Xauthority mechanisms are primarily for X11. If you are running an X application under Wayland via XWayland, the integration might have its own quirks. Your usage of Xorg in ps aux suggests you are indeed on X11.

## Best Practices for Remote Access (Even if Not Currently Used) #

Although you’ve clarified this is a local issue, understanding secure remote access principles can shed light on X11 security.

• SSH with X11 Forwarding: The most secure way to run graphical applications remotely is via SSH with X11 forwarding (ssh -X or ssh -Y). This tunnel’s X11 traffic through the secure SSH connection and automatically handles DISPLAY and Xauthority setup.
• Avoid xhost +: Never use xhost + on a network-connected machine, as it opens your display to anyone.

## Final Steps and Verification #

After applying the relevant solutions, it’s essential to verify the fix.

1. Reboot your system: A full reboot ensures all services start in a clean state.

   sudo reboot
   

2. Log in graphically: Access your desktop environment.
3. Open a terminal.
4. Test xclock:

   export DISPLAY=:0
   xclock
   

   or

   xclock
   

   If xclock opens successfully, the issue is resolved.
5. Test xhost commands:

   xhost +local:
   

   If this command executes without error, then xhost can communicate with the X server.

Conclusion: Restoring Your Graphical Workflow #

The “xhost: unable to open display” error, particularly when accompanied by “Invalid MIT-MAGIC-COOKIE-1 key,” is almost always rooted in issues with the DISPLAY environment variable or, more commonly, the Xauthority file’s integrity and accessibility. Your detailed logs pointed towards potential corruption or timing problems with Xauthority during display manager restarts.

By meticulously ensuring the DISPLAY variable is set to a valid local display (e.g., :0), and by addressing any potential corruption or access issues with the Xauthority file, you can effectively restore proper graphical session functionality. The methods outlined above, focusing on restarting the display manager, correctly setting environment variables, and understanding the role of Xauthority, provide a comprehensive path to resolving this problem.

At revWhiteShadow, we believe in equipping you with the knowledge and practical steps to overcome technical hurdles. If you continue to experience difficulties, carefully review the state of your Xauthority file and the system’s user session management. Remember, consistency in how these variables are managed is key to a stable graphical environment. We trust this detailed guide will empower you to overcome this challenge and resume your work without graphical interruptions.