Description of problem: userdrake assigns wrong permission to homedirectory As a result, when logging into KDE it cannot setup right. For exemple there is no taskbar Version-Release number of selected component (if applicable): How reproducible: Every time on every box when adding a new user through Userdrake This is valid vor KDE, I haven't checked Gnome Steps to Reproduce: 1.Install mga3 2.after first boot (which goes well) add another user 3.reboot and log in as this newly created user. You will not get a taskbar and on some boxes not even a desktop. BTW, the user created during the install has the permission drwxr-xr-x The user created using Userdrake has the permission drwx------ changing it to drwxr---- seems to work. Reproducible: Steps to Reproduce:
I am ready to donate some older boxes (with mga3 installed, nothing else) to a charity and the recipients adding them as user will get a terrible experience.
Priority: Normal => High
The difference between home directory permissions of users created by the installer and those created by userdrake is long-standing (see Bug#618 ), but so far as know has never caused the problem reported here. I have no problem logging in to a new "test" account created by userdrake and its KDE desktop is complete. ll /home ... drwx------ 18 test test 4096 Jul 17 23:36 test/ ...
I have this on at least 2 boxes and the VM (virtualbox) All don't get a taskbar and some of the older ones not even a desktop after changing the permission to drwxr it works. This seems to be a problem in >= mga3
By default the group is private to the user, so anything acting as the group would be the user himself and drwxr---- doesn't add any permission compared to drwx-----
CC: (none) => pterjan
So please let me know what the problem is or better how to fix it.
(In reply to Thomas Spuhler from comment #5) > So please let me know what the problem is or better how to fix it. I cannot recreate the problem (tested Mageia 3 i586 and x86_64). As Pascal noted, as the group and owner are the same, adding group permissions doesn't make any difference. Please try to recreate the problem, and attach the ~/.xsession-errors from the affected user. That may help identify what is actually causing the problem.
CC: (none) => davidwhodgins
Created attachment 4212 [details] xsession-errors
This error occurs randomly. I got it 2 errors out of 5 new user adds
The only thing that stands out to me, is the list of repositories being updated. None of the Release repositories are shown. Also, for tainted, only the backports appears to be enabled. Are they enabled?
Also, which iso is being used for the install?
(In reply to Dave Hodgins from comment #9) > The only thing that stands out to me, is the list of repositories > being updated. None of the Release repositories are shown. Also, > for tainted, only the backports appears to be enabled. > > Are they enabled? mcc show onone of the tainted being enabled.
(In reply to Dave Hodgins from comment #10) > Also, which iso is being used for the install? (This is on a vbox) I used the dual-arch cd w/o the LXDE. after the couple hundred packages were installed, I had to manually start the network and I added the repositories with urpm.addmedia and then did urpmi task-kde4 which added the rest. I thin, I then used the mcc removed all repos and added a new set from a certain mirror. I've done all update. On the other box, I used the boot isos and did a complete network install. That box only has a CD-ROM, no DVD. Let me know if I should try a different way of installation on the vbox, it only takes a little more than an hour.
(In reply to Thomas Spuhler from comment #11) > (In reply to Dave Hodgins from comment #9) > > The only thing that stands out to me, is the list of repositories > > being updated. None of the Release repositories are shown. Also, > > for tainted, only the backports appears to be enabled. > > > > Are they enabled? > > mcc show onone of the tainted being enabled. Sorry: mcc show non of the tainted being enabled.
Created attachment 4213 [details] xsession-errors from the Dell box, not a virtual machine On this box the missing taskbar is randomly too. I cannot detect any pattern.
I don't see anything unexpected there. Are all of the installs under virtualbox? I'm wondering if it's a resolution problem. I've seen in the past, that some times vb guests with XFdrake set to use automatic resolution would use 1600x1200, even though the host screen and the vb dialog were much smaller. In that case, the panel existed, but was not visible. No idea what triggers the problem in vb. Can you check /var/log/Xorg.0.log to see what resolution it has selected?
Let's close this, the problem lies somewhere else
Status: NEW => RESOLVEDResolution: (none) => FIXED