Bug 16420 - "Call to lnusertemp failed (temporary directories full?)" - /home/user ownership changes to "nobody" after KDE login
Summary: "Call to lnusertemp failed (temporary directories full?)" - /home/user owners...
Status: RESOLVED INVALID
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 5
Hardware: x86_64 Linux
Priority: Normal major
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-19 21:00 CEST by macxi
Modified: 2016-01-06 15:50 CET (History)
2 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description macxi 2015-07-19 21:00:53 CEST
Description of problem:
1 - I did a clean install Mageia 5 DVD (classic) KDE, 64, on a physical machine with legacy grub boot (no grub2 and without UEFI).

2 - After installing, I've set the media, updated and then installed about 40 applications.

3 - But after restarting the machine, I was unable to access the KDE graphical environment, and appeared the warning:

"Call to lnusertemp failed {temporary directories full?}. Check your installation?"

4 - I could access the IceWM and saw that the Common User has become owner "nobody" and no allowing to access the folders.

5 - Through the root user, I corrected the owner of folders and managed to access the KDE, who returned to work normally.

6 - But after restart, the user has returned to owner "nobody", making it necessary again to correct the error.

7 - And the error happen again, whenever I reboot the system.

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

How reproducible:
The error continues to happen whenever I restart the system.

Steps to Reproduce:
1. After correcting the problems
2. restart the system
3.


Reproducible: 

Steps to Reproduce:
Comment 1 Florian Hubold 2015-07-21 19:38:32 CEST
Originally reported via https://forums.mageia.org/en/viewtopic.php?f=7&t=10051&

@macxi: Please provide the output of 

df -m
ls -al /home


Also, what do you mean in particular by "the Common User"?

CC: (none) => doktor5000

Florian Hubold 2015-07-21 19:40:33 CEST

Summary: common user switches to nobody owner => "Call to lnusertemp failed (temporary directories full?)" - /home/user ownership changes to "nobody" after KDE login

Comment 2 macxi 2015-11-08 11:40:58 CET
The "Common User" is one that is not root, is the "ordinary user"

[mageia5@localhost ~]$ su -
Senha:
[root@localhost ~]# ls -al /home
total 44
drwxr-x--x  8 root       adm         4096 Jul 16 13:48 ./
drwxr-xr-x 19 root       adm         4096 Nov  7 10:35 ../
lrwxrwxrwx  1 root       root          16 Nov  7 10:23 live -> /home/mageia5/
drwxr-x--x  2 root       root       16384 Jan 30  2010 lost+found/
drwxr-x--x 35 nobody     nogroup     4096 Nov  7 18:12 mageia3/
drwxr-x--x 43 nobody     nogroup     4096 Jun 21  2013 mageia2/
drwxr-x--x 31 mageia5 mageia5        4096 Nov  8 08:13 mageia5/
drwxr-x--x 27 nobody     nogroup     4096 Nov  1 13:11 mageia4/
drwxr-x--x 13 nobody     nogroup     4096 Mai 21  2012 xguest/
[root@localhost ~]# 
[root@localhost ~]# 
[root@localhost ~]# df -m
Sist. Arq.     1M-blocos Usado Disponível Uso% Montado em
devtmpfs             487     0        487   0% /dev
tmpfs                493     2        492   1% /dev/shm
tmpfs                493     1        492   1% /run
/dev/sda5          10474  6141       3779  62% /
tmpfs                493     0        493   0% /sys/fs/cgroup
tmpfs                493     1        493   1% /tmp
/dev/sda1          80133 54911      25222  69% /mnt/windows
/dev/sda8          10049  8394       1122  89% /mnt/linux
/dev/sda7          12056  8679       3361  73% /home
tmpfs                 99     1         99   1% /run/user/1000
[root@localhost ~]# 

I always have multiple installations, with multiple versions of Mageia. Since Mageia 1, I was installing Mageia 2 on another partition and keeping the Mageia 1.  I did this also with the "Mageia 3" and the "Mageia 4" and never gave problem. Now I'm with "Mageia 3" and "5 Mageia" installed on my desktop computer and notebook, and there seems to be some incompatibility with the file system or something, because after I installed Mageia 5, if I access to Mageia 3, the Mageia 5 files are nobody/nogroup. If I access the Mageia 5, files Mageia 3 are nobody/nogroup. The same error occurs on both machines, on your desktop computer and notebook.
Comment 3 macxi 2015-11-09 00:11:05 CET
When the user's owner change for nobody/nogroup, if I try to access the user, an error message appears::

"Call to lnusertemp failed {temporary directories full?}. Check your installation?"

To fix, I access a terminal as root and type:

chown -R mageia5:mageia5 /home/mageia5
or 
chown -R mageia3:mageia3 /home/mageia3

So I restart the computer and access the user
Comment 4 andré blais 2016-01-06 06:31:42 CET
I suspect that your non-root accounts with the same name on the different versions of Mageia don't have the same UID and GID.
The UID and GID are the numbers associated with the account and group names respectively.
The main GID for each user is the same as the UID by default.
However both GID and UID can be defined by the user, when an account is created after installation/upgrade.

Note that the base ordinary user account number changed from 500 to 1000 in Mageia 5, so that unless you had set the UID and GID explicitly when you defined the accounts, there would very likely be a mismatch between Mageia 5 and previous versions of Mageia.
Note that the UIDs and GIDs from 1 to 499 are reserved for special system accounts before Mageia 5.
Mageia 5 (and after) change this to 1 to 999, with a provision that ordinary user accounts can continue to exist in the 500 to 999 range.
Not sure that this applies to newly defined accounts, but expect so.

When this change occurred, I migrated my ordinary accounts to above 999 to avoid any problems.

Could you verify the UID and GID numbers associated with your ordinary user accounts, in Mageia 4 and Mageia 5 ?

CC: (none) => andre999mga

Comment 5 Florian Hubold 2016-01-06 08:57:18 CET
(In reply to andré blais from comment #4)
> Note that the UIDs and GIDs from 1 to 499 are reserved for special system
> accounts before Mageia 5.
> Mageia 5 (and after) change this to 1 to 999, with a provision that ordinary
> user accounts can continue to exist in the 500 to 999 range.

I already described this in the forums thread linked above. But this doesn't explain why ownership changed to nobody:nogroup ( 65534:65534 ) which would only make sense if NFS comes into play somehow for /home.


In any case, I don't think there's something we can do to prevent this issue.
Comment 6 andré blais 2016-01-06 15:50:43 CET
(In reply to Florian Hubold from comment #5)
> (In reply to andré blais from comment #4)
> 
> I already described this in the forums thread linked above. But this doesn't
> explain why ownership changed to nobody:nogroup ( 65534:65534 ) which would
> only make sense if NFS comes into play somehow for /home.

Msec can do that automatically if set to force user and/or group ownership, which is not the default for the standard security setting.
Also, if I remember correctly, I've encountered in some contexts nobody and/or nogroup displayed for other UID / UID values, if they don't correspond to a defined account.

There is an easy workaround for his problem.  Define a new account with whatever name for each of the old UIDs & GIDs, to allow access to the old files.
He could also allow access to most files by making the file owned by an additional group.
For other files in /home, he could simply copy them between the 2 accounts

> In any case, I don't think there's something we can do to prevent this issue.

I agree.  Also it would not be encountered with normal upgrades.
So this problem would rarely occur.
Considering this, since it is not really a bug, I'm closing this as INVALID.
We have given him enough info here to work around his problem.

Status: NEW => RESOLVED
Resolution: (none) => INVALID


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