Bug 20835 - After drakx11 "test", user can't login into DE session because of user's .Xauthority file is owned by root
Summary: After drakx11 "test", user can't login into DE session because of user's .Xau...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: High major
Target Milestone: Mageia 10
Assignee: Mageia tools maintainers
QA Contact:
Whiteboard: MGA8TOO, MGA9TOO
Keywords: IN_ERRATA9
Depends on:
Reported: 2017-05-13 05:37 CEST by Yuri Galitsky
Modified: 2024-01-12 23:34 CET (History)
7 users (show)

See Also:
Source RPM: drakx-kbd-mouse-x11
Status comment:

journalctl output (67.24 KB, text/plain)
2017-05-13 10:30 CEST, Marja Van Waes

Description Yuri Galitsky 2017-05-13 05:37:15 CEST
Description of problem:
Mageia6 sta2
After starting MCC by the user from the menu, then selecting "Hardware -> Configuring the graphic server -> Test -> Yes" after the performed testing the owner of the .Xauthority file of the user will be root. And in the next boot the user can not enter the DE session because of the rights restriction to this file.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run MCC from the menu, run test in the 'Configuring the graphic server' from the 'Hardvare' section
2.See your ~/.Xauthority file was owned by root
3.Reboot ant try to log in into DE
Comment 1 Marja Van Waes 2017-05-13 10:30:09 CEST
Created attachment 9294 [details]
journalctl output

Confirming the issue with a test user:

In /home/u/ there was:

-rw-------  1 u    u         54 apr 25 12:12 .Xauthority

After starting an XFCE session with "u" and running the graphic server test from MCC (but no settings changed) there was:

-rw-------  1 root root     108 mei 13 09:37 .Xauthority
-rw-------  2 u    u          0 mei 13 09:38 .Xauthority-c
-rw-------  2 u    u          0 mei 13 09:38 .Xauthority-l

and after logging out it was indeed impossible to log in again.

After running "chown u: .Xauthority" (which was probably bound to fail to solve the issue, since the file had twice the original size) logging in was stil impossible. I then noticed that the contents of that file had been deleted

-rw-------  1 u    u          0 mei 13 09:39 .Xauthority
-rw-------  2 u    u          0 mei 13 09:38 .Xauthority-c
-rw-------  2 u    u          0 mei 13 09:38 .Xauthority-l

After deleting all three .Xauthority* files, logging in worked fine again and the newly created .Xauthority had the correct size. 

Attaching the output of 

   journalctl -a --since="2017-05-13 09:35" --until="2017-05-13 09:41" 

I have _not_ tried whether this bug is also valid when you actually change your configuration before testing it. 

@ Yuri

Did you?

CC: (none) => marja11

Marja Van Waes 2017-05-13 10:31:31 CEST

Assignee: bugsquad => mageiatools
Source RPM: (none) => drakx-kbd-mouse-x11
Keywords: (none) => NEEDINFO

Comment 2 Yuri Galitsky 2017-05-16 09:22:37 CEST
If I changed the configuration of the Graphic Card before "testing", everything is seems fine with this file then.
Comment 3 Per Nelvig 2017-11-04 07:33:05 CET
I encountered this bug on two recently installed boxes with Mageia 6 64-bit and Mate desktop. Solved it by changing user and group on .Xautority from "root" to normal user.

CC: (none) => pernel

Comment 4 Florian Hubold 2021-05-02 18:11:45 CEST
@tv: As this happens pretty often to novice users when using the "Test" button in drakx11 - would it be difficult to implement a failsafe to chown any ~/.Xauthority* file in that users home folder to that user if it belongs to root ? That should probably go here, although I'm not that good at perl: http://gitweb.mageia.org/software/drakx-kbd-mouse-x11/tree/lib/Xconfig/test.pm#n137

CC: (none) => doktor5000, thierry.vignaud

Comment 5 Morgan Leijström 2021-10-05 15:12:22 CEST
I believe NEEDINFO got satisfied by comment 2.
This trap have been present since long time.

CC: (none) => fri
Keywords: NEEDINFO => (none)
Whiteboard: (none) => MGA8TOO

Comment 6 Morgan Leijström 2021-12-11 19:39:49 CET
Our GUI tool for novices makes novices locked out - pretty serious.
Raising severity and priority.

Priority: Normal => High
Severity: normal => major

Comment 7 Morgan Leijström 2022-08-21 18:52:13 CEST
I see yet another user now needed help on forum with this.
Comment 8 Morgan Leijström 2023-05-02 18:48:32 CEST
Cant we just remove that test button...?
Comment 9 Morgan Leijström 2023-05-02 18:49:49 CEST
As users naturally experiment with drivers maybe this should be an errata item

Keywords: (none) => FOR_ERRATA9

Morgan Leijström 2023-06-27 23:15:01 CEST

Summary: User can't login into DE session because of user's .Xauthority file was owned by root => After drakx11 "test", user can't login into DE session because of user's .Xauthority file is owned by root

Comment 10 Morgan Leijström 2023-06-28 11:01:18 CEST
Some sad tests:

_False negative

Another reason to remove the test button is that it can also give false negatives.

My system is happily using nvidia R535 on my GTX750.
I just now launched drakx11 and pressed the test button and screen went blaxk maybe five seconds then back to desktop with drakx11 showing:

 An error occurred:
 Fatal server error:

 Try to change some parameters

Nothing in journal

Just pressing the button again, screen went black, then successfully show the rainbow test.

_Regarding file ownership
I ran the test answering Yes one time and No another time in the question on the rainbow test screen, and it did in neither case change the ownership of  .Xauthority.

So have this somehow got fixed?  Or is the problem only arising under some circumstances?

Above, i had started mcc from konsole with: LC_ALL=C mcc
My user is member of wheel

_Hard freeze

Yet a reason to remove the dreaded test

Next, i launched mcc from plasma menu, and in popup question selected my test user (also member of wheel btw)
the test displayed the rainbow, but i could not select yes/no buttons, i saw no mouse pointer (maybe there was but that is a design problem, hard to see tiny on a 4K screen rainbow...) but i also dod not find keyboard working until it timed out.  -- and after timing out it returned to a plain black desktop with frozen mouse pointer.  Also ctrl-alt-F3 did not work (i verified earlier that it worked, bug 31994), not even REISUB. Had to use reset button.

I end my tests...


Added to errata


Comment 11 Frédéric "LpSolit" Buclin 2023-10-16 02:41:22 CEST
(In reply to Morgan Leijström from comment #8)
> Cant we just remove that test button...?

Yes, please! I just wasted several hours trying to understand why I couldn't log in anymore! I finally reinstalled Mageia but I kept my /home partition alone, which means that the permissions on .Xauthority were left unchanged and so I did all this painful work for nothing.

CC: (none) => LpSolit

Morgan Leijström 2023-10-16 09:21:08 CEST

Target Milestone: --- => Mageia 10
Whiteboard: MGA8TOO => MGA8TOO, MGA9TOO

Comment 12 Paul Blackburn 2024-01-12 16:32:38 CET
For anyone needing help to rescue a system with failing GUI login:


CC: (none) => paul.blackburn

Comment 13 sturmvogel 2024-01-12 23:34:39 CET Comment hidden (obsolete)

Note You need to log in before you can comment on or make changes to this bug.