After installation of OMV LX 3.0, I noticed no authentication step is required. Booting, rebooting, everytime system went straight to my session.
Tried configuring another user but didn’t help. Tried configuring initialization via MCC to SDDM. Then, after rebooting, I got a black screen asking for user login and password. I tried a regular user and write,
$ sddm
/usr/bin/xauth: timeout in locking authority file /usr/run/sddm/{my partition number one}
[02:04:17.717] (WW) DAEMON: Failed to change owner of the auth file.
[02:04:17.717] (WW) DAEMON: Failed to change owner of the socket
and the same for the other disk partition.
Then I tried the same as root and sddm start my user profile as before …
How to fix this and have a authentication sddm for different users login as usual?
Following your tips, I now have authentication/login options. Thanks.
But, anyway, there seems to be a few small and not so small problems that I would like to fix:
key NUMLOCK is always set at authentication, it has to be unset to provide password;
/home is at a small disk partition instead of being a symlink to the bigger one (I did not see an option to manage /home during installation in the live mode);
…
So, if there is nothing I can check on this and report to help to identify bugs, I am planning to try another installation out of the live mode …
There seems to be something weird with initialization here, sddm initialization with machine boot has been disable. Following Luca’s tip, I had to login as root, systemctl start sddm, MCC, plus resetting sddm service to start at boot again,
After such a long period considering this as solved, I realized that in my two OMV LX 3.0 installations regular users have not their passwords checked in SDDM login. I mean, no matter what we type as a password for regular users their sessions are opened.
Only my account (defined during installation) has its password checked.
How to change it to give regular users more privacy?
That might be the problem, our developers don’t like OMCC and the drakx tools. That’s because of how the code is written and that it is in perl I think? I suspect developer might say it’s better to use KUser. You can use KUser and reset password. Or reset password from command line:
I’ll try KUser as soon as I can. I have noticed that systemsettings provides SDDM managing of users but it has different rules for passwords. For example, a five characters password is not accepted.
I also noticed that some users have their password properly handled at SDDM login in one of my OMV installations while others have their sessions totally open.
By the way,
I’ve always thought of OMCC as one of the best features of Mandriva/Openmandriva distros. Is there something to substitute its many possibilities (hardware, software, system, …, configurations) all at once?
kuser begins with an error message in popup window: Error: Cannot open /etc/shadow.
I tried to reconfigure user’s password and got another error: Cannot open /etc/passwd.bak
As root, kuser returns,
$ kuser
Creating link /root/.kde4/cache-pc-local.
Created link from “/root/.kde4/cache-pc-local” to “/var/tmp/kdecache-root”
kuser(11443)/kdeui (kdelibs): Session bus not found
To circumvent this problem try the following command (with Linux and bash)
export $(dbus-launch)
Aborpted (core image recorded)
Most of the time, the graphical applications can be launched from the console as root, if you start the shell as login shell: su -
or su -l
or su -login
Another trick is to start the graphical app with xsudo (to be installed). That suppose the user is in the /etc/sudoers list.
The old MCC seems to have been ported for SuSE in a project called Manatools. Maybe Mageia is using Manatools somehow (???). Woudn’t it be a good point to start with to an updated OMCC?