SDDM Not Creating .Xauthority File - Preventing Docker X11 Forwarding

[seeh]

Hi everyone,

I’m having a frustrating issue with SDDM on my Manjaro system. SDDM is not creating a .Xauthority file in my home directory, which is preventing me from using X11 forwarding with Docker. I’ve spent several days troubleshooting this, and I’m hoping someone in the community can offer some guidance.

Problem:

SDDM is not creating a .Xauthority file in my home directory (/home/<my_username>/.Xauthority) when I log in graphically. This is preventing applications (specifically, a GUI application running in a Docker container) from connecting to the X server.

Symptoms:

• The file /home/<my_username>/.Xauthority exists, but it has a size of 0.
• Applications that require X11 forwarding fail to connect to the X server, with errors related to .Xauthority not being found or being a directory.

My Setup:

• Manjaro Linux (latest version)
• KDE Plasma desktop environment
• SDDM display manager
• Using startx is not an option

Troubleshooting Steps Taken:

I’ve already tried the following troubleshooting steps:

1. Verified xauth is installed: The xorg-xauth package is installed and up to date.

2. Checked ~/.xinitrc and ~/.xprofile: These files do not exist in my home directory.

3. Verified SDDM is the active display manager: systemctl list-units --type=service | grep display-manager shows sddm.service as active.

4. Checked SDDM logs: The SDDM logs (journalctl -u sddm) show that SDDM is creating a .Xauthority file in /run/sddm/, but it’s not copying it to my home directory.

5. Modified /usr/share/sddm/scripts/Xsetup: I added the following lines to the end of the /usr/share/sddm/scripts/Xsetup script:

   export XAUTHORITY=$HOME/.Xauthority
   xauth add :0 . $(xxd -l 16 -p /dev/urandom)
   cp /run/sddm/* $HOME/.Xauthority
   exit 0
   

6. Verified Permissions: The permissions on my home directory and the /tmp directory are correct.

7. Checked AppArmor/SELinux: AppArmor is loaded, but the filesystem is not mounted. SELinux is not installed.

8. Simplified Xsetup Script: I tried simplifying the Xsetup script to just create an empty file in /tmp or my home directory, but it still didn’t work.

9. Verified SDDM Configuration: I’ve carefully reviewed the SDDM configuration files in /etc/sddm.conf and /etc/sddm.conf.d/.

   • I removed the [XDisplay] section from /etc/sddm.conf, as it was overriding the DisplayCommand.
   • The [X11] section in /etc/sddm.conf contains the correct DisplayCommand: DisplayCommand=/usr/share/sddm/scripts/Xsetup.

10. Verified Path to xauth: The path to xauth is /usr/bin/xauth, which is what’s being used in the Xsetup script.

11. Tried a Hardcoded Magic Cookie: I tried using a hardcoded magic cookie in the xauth add command, but it didn’t make a difference.

SDDM Configuration Files:

Here are the contents of my SDDM configuration files:

• /etc/sddm.conf.d/00_manjaro_settings.conf:

  [Autologin]
  Relogin=false
  Session=plasma
  User=<my_username>
  
  [General]
  HaltCommand=/usr/bin/systemctl poweroff
  InputMethod=
  Numlock=none
  RebootCommand=/usr/bin/systemctl reboot
  
  [Theme]
  Current=breath
  CursorTheme=breeze_cursors
  DisableAvatarsThreshold=7
  EnableAvatars=true
  FacesDir=/usr/share/sddm/faces
  ThemeDir=/usr/share/sddm/themes
  
  [Users]
  DefaultPath=/usr/local/sbin:/usr/local/bin:/usr/bin
  HideShells=
  HideUsers=
  MaximumUid=60000
  MinimumUid=1000
  RememberLastSession=true
  RememberLastUser=true
  ReuseSession=false
  
  [Wayland]
  EnableHiDPI=false
  SessionCommand=/usr/share/sddm/scripts/wayland-session
  SessionDir=/usr/share/wayland-sessions
  SessionLogFile=.local/share/sddm/wayland-session.log
  
  [X11]
  DisplayCommand=/usr/share/sddm/scripts/Xsetup
  DisplayStopCommand=/usr/share/sddm/scripts/Xstop
  EnableHiDPI=false
  MinimumVT=1
  ServerArguments=-nolisten tcp
  ServerPath=/usr/bin/X
  SessionCommand=/usr/share/sddm/scripts/Xsession
  SessionDir=/usr/share/xsessions
  SessionLogFile=.local/share/sddm/xorg-session.log
  UserAuthFile=.Xauthority
  XauthPath=/usr/bin/xauth
  XephyrPath=/usr/bin/Xephyr
  

• /etc/sddm.conf.d/virtualkeyboard.conf:

  [General]
  InputMethod=qtvirtualkeyboard
  

• /etc/sddm.conf:

  [Theme]
  Current=breath
  CursorTheme=breeze_cursors
  

My Docker Setup:

I’m using a Dockerfile to build an image that runs a GUI application. The Dockerfile creates a user with the same UID as my host user and mounts the /tmp/.X11-unix directory and the .Xauthority file into the container.

Will later uploaded to : GitHub - sl5net/docker-0ad-mod-testbed

Here’s the relevant part of my start_0ad.sh script:

#!/bin/bash

# Sicherheitshinweis: Besser eine restriktivere Regel verwenden
xhost +local:docker

export XDG_RUNTIME_DIR=/run/user/$(id -u)

# Standard 0 A.D. Startparameter
GAME_PARAMS=""

# Zusätzliche Parameter (falls angegeben)
if [ ! -z "$1" ]; then
  GAME_PARAMS="$@"
fi

docker run --rm -it \
    -e DISPLAY="$DISPLAY" \
    --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" \
    -v "$HOME/.Xauthority:/home/<my_docker_user>/.Xauthority" \
    -v "$(pwd)/0ad-extracted:/game" \
    0ad $GAME_PARAMS

Questions:

• Has anyone else encountered this issue with SDDM on Manjaro?
• Are there any other SDDM configuration settings that might be preventing the Xsetup script from running correctly?
• Is there a known bug in SDDM that might be causing this issue?
• Are there any alternative ways to configure SDDM to create the .Xauthority file in my home directory?
• Am I missing something obvious?

Any help or suggestions would be greatly appreciated!

Thanks,
Seeh

[scotty65]

My first thought was: are you running Plasma X11 or Plasma Wayland? Please provide the output of:

echo $XDG_SESSION_TYPE

and

inxi -zv8

[Nachlese]

@seeh

SDDM is not creating a .Xauthority file in my home directory

… why would it when the session is Wayland

[cscs]

For a long while the old ‘standard’ of ~/.Xauthority has not existed.

At least not on Plasma/Kwin.

This ‘magic cookie’ is not static and is different with each session.

You can find yours with something like

echo $XAUTHORITY

xauth info | awk '/xauth/ {print $3}'

etc.

If you try to force this to some other static file of your choosing you may encounter various problems.

The SDDM Xauthority path can be changed in its own configuration files as shown below. Unfortunately, it is relative to the home directory.

/etc/sddm.conf.d/xauth-path.conf

[X11] UserAuthFile=.Xauthority

On Wayland, overriding this may cause Xorg programs to fail to connect to the Xwayland server. For example, both kwin and mutter use a randomized name, so it cannot be set to a static value.

https://wiki.archlinux.org/title/Systemd/User#DISPLAY_and_XAUTHORITY

https://wiki.archlinux.org/title/XDG_Base_Directory

https://wiki.archlinux.org/title/Udev#Execute_on_VGA_cable_plug_in

I have a vague memory of a certain approach people would use when they wanted to be able to point to the dynamically generated xauth file … but its not popping up in my wiki searches.

PS

@seeh

The file /home/<my_username>/.Xauthority exists, but it has a size of 0.

Oh, if you do have this … it may be considered for deletion.

https://wiki.archlinux.org/title/SDDM#Hangs_after_login

[seeh]

@scotty65

echo $XDG_SESSION_TYPE

and

inxi -zv8

echo $XDG_SESSION_TYPE                   ✔ 
x11

 inxi -zv8                                ✔ 
System:
  Kernel: 6.12.17-1-MANJARO arch: x86_64 bits: 64
    compiler: gcc v: 14.2.1 clocksource: tsc
    avail: hpet,acpi_pm
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.12-x86_64
    root=UUID=facac5d6-e4b0-4883-9af6-04b0966b2399 rw
    quiet splash udev.log_priority=3
  Desktop: KDE Plasma v: 6.3.2 tk: Qt v: N/A
    info: frameworks v: 6.11.0 wm: kwin_x11 tools:
    avail: xfce4-screensaver vt: 2 dm: 1: LightDM
    v: 1.32.0 note: stopped 2: SDDM Distro: Manjaro
    base: Arch Linux
Machine:
  Type: Desktop Mobo: Micro-Star model: MPG X570
    GAMING PLUS (MS-7C37) v: 2.0
    serial: <superuser required>
    uuid: <superuser required>
    UEFI: American Megatrends v: A.40 date: 09/10/2019
Battery:
  Message: No system battery data found. Is one
    present?
Memory:
  System RAM: total: 32 GiB available: 31.29 GiB
    used: 10.04 GiB (32.1%)
  Message: For most reliable report, use superuser
    + dmidecode.
  Array-1: capacity: 128 GiB slots: 4 modules: 2
    EC: None max-module-size: 32 GiB note: est.
  Device-1: Channel-A DIMM 0
    type: no module installed
  Device-2: Channel-A DIMM 1 type: DDR4
    detail: synchronous unbuffered (unregistered)
    size: 16 GiB speed: spec: 2133 MT/s
    actual: 1067 MT/s volts: note: check curr: 1
    min: 1 max: 1 width (bits): data: 64 total: 64
    manufacturer: G.Skill part-no: F4-3200C16-16GVK
    serial: N/A
  Device-3: Channel-B DIMM 0
    type: no module installed
  Device-4: Channel-B DIMM 1 type: DDR4
    detail: synchronous unbuffered (unregistered)
    size: 16 GiB speed: spec: 2133 MT/s
    actual: 1067 MT/s volts: note: check curr: 1
    min: 1 max: 1 width (bits): data: 64 total: 64
    manufacturer: G.Skill part-no: F4-3200C16-16GVK
    serial: N/A
PCI Slots:
  Permissions: Unable to run dmidecode. Root
    privileges required.
CPU:
  Info: model: AMD Ryzen 7 3700X bits: 64 type: MT MCP
    arch: Zen 2 gen: 2 level: v3 note: check
    built: 2020-22 process: TSMC n7 (7nm)
    family: 0x17 (23) model-id: 0x71 (113) stepping: 0
    microcode: 0x8701034
  Topology: cpus: 1x dies: 1 clusters: 1 cores: 8
    threads: 16 tpc: 2 smt: enabled cache: L1: 512 KiB
    desc: d-8x32 KiB; i-8x32 KiB L2: 4 MiB
    desc: 8x512 KiB L3: 32 MiB desc: 2x16 MiB
  Speed (MHz): avg: 2200 min/max: 2200/4426
    boost: enabled scaling: driver: acpi-cpufreq
    governor: schedutil cores: 1: 2200 2: 2200 3: 2200
    4: 2200 5: 2200 6: 2200 7: 2200 8: 2200 9: 2200
    10: 2200 11: 2200 12: 2200 13: 2200 14: 2200
    15: 2200 16: 2200 bogomips: 115256
  Flags: 3dnowprefetch abm adx aes aperfmperf apic
    arat avic avx avx2 bmi1 bmi2 bpext cat_l3 cdp_l3
    clflush clflushopt clwb clzero cmov cmp_legacy
    constant_tsc cpb cpuid cqm cqm_llc cqm_mbm_local
    cqm_mbm_total cqm_occup_llc cr8_legacy cx16 cx8
    de decodeassists extapic extd_apicid f16c
    flushbyasid fma fpu fsgsbase fxsr fxsr_opt ht
    hw_pstate ibpb ibs irperf lahf_lm lbrv lm mba mca
    mce misalignsse mmx mmxext monitor movbe msr mtrr
    mwaitx nonstop_tsc nopl npt nrip_save nx osvw
    overflow_recov pae pat pausefilter pclmulqdq
    pdpe1gb perfctr_core perfctr_llc perfctr_nb
    pfthreshold pge pni popcnt pse pse36 rapl rdpid
    rdpru rdrand rdseed rdt_a rdtscp rep_good sep sev
    sev_es sha_ni skinit smap smca smep ssbd sse sse2
    sse4_1 sse4_2 sse4a ssse3 stibp succor svm
    svm_lock syscall tce topoext tsc tsc_scale umip
    v_spec_ctrl v_vmsave_vmload vgif vmcb_clean vme
    vmmcall wbnoinvd wdt xgetbv1 xsave xsavec
    xsaveerptr xsaveopt xtopology
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data status: Not affected
  Type: reg_file_data_sampling status: Not affected
  Type: retbleed mitigation: untrained return
    thunk; SMT enabled with STIBP protection
  Type: spec_rstack_overflow mitigation: Safe RET
  Type: spec_store_bypass mitigation: Speculative
    Store Bypass disabled via prctl
  Type: spectre_v1 mitigation: usercopy/swapgs
    barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Retpolines; IBPB:
    conditional; STIBP: always-on; RSB filling;
    PBRSB-eIBRS: Not affected; BHI: Not affected
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: NVIDIA GP107 [GeForce GTX 1050 Ti]
    driver: nvidia v: 550.144.03
    alternate: nouveau,nvidia_drm
    non-free: 550/565.xx+ status: current (as of
    2025-01; EOL~2026-12-xx) arch: Pascal code: GP10x
    process: TSMC 16nm built: 2016-2021 pcie: gen: 3
    speed: 8 GT/s lanes: 16 ports: active: none
    off: DP-1,HDMI-A-1 empty: DVI-D-1 bus-ID: 2d:00.0
    chip-ID: 10de:1c82 class-ID: 

[linux-aarhus]

@cscs got it covered.

The auth socket generated by sddm is stored in /tmp - I don’t know if you can use to communicate - but as wayland is intended to replace x11 especially in terms of security I doubt it.

 $ ls -l /tmp/sddm*
srwxr-xr-x 1 root root 0 10 mar 16:45 /tmp/sddm-auth-9f3a1f19-cc39-47f7-abb7-a774d9b3b286
srwx------ 1 sddm sddm 0 10 mar 16:45 /tmp/sddm--LrENLG

Plasma uses dbus for communication perhaps you can configure docker to do the same?

If you really need the x11 forward - you could try replacing sddm with e.g. lightdm - you already got it installed - at least it looks like - be sure you got a greeter installed too.

To disable sddm

sudo systemctl disable sddm
sudo systemctl enable lightdm

Then do a soft reboot

systemctl soft-reboot

Some Plasma functionality may rely on sddm - disabling may lead to unknown issues with Plasma.

[seeh]

Thank you everyone for your helpful suggestions. Unfortunately, after trying many different approaches, I wasn’t able to find a solution that allows me to use X11 forwarding with Docker on my Manjaro system without making significant changes to the host OS.

I also wanted to mention that I previously tried switching to LightDM (on February 25, 2025), and it resulted in a black screen and considerable difficulty accessing my system. It took me a while to recover, and I’m hesitant to try that again without being prepared to potentially reinstall everything.

Since modifying the host OS is not an option for me, and I’m concerned about the potential risks of switching display managers, I’m going to have to abandon this project for now. I appreciate your time and effort.

[aCursedComrade]

Since it was not mentioned here, I want to share another tip: Nested X11 Sessions

Its basically a separate X11 server running independent of your host’s X11 server and is usually interacted like a typical GUI application. There’s a few applications that can do this but Xephyr (ArchWiki) is popular for this. This way, you don’t have touch your host settings and avoid breaking anything.

I don’t use this typically, only on a few occasions when I was playing with firejail (application sandbox). But, it seems to be simple as passing the appropriate DISPLAY variable and the relevant socket file managed by Xephyr into the container: https://stackoverflow.com/a/40795185