Everyone:
Just did a clean install to Fedora 17 (x86_64 architecture) and KDE 4.
I used the Users and Groups app. (authenticating with the root password) to create two new users to hook in with two directories on /home (from the previous installation).
But when I try to log into either one, I get this:
call to lnusertemp failed (/Temporary directories full?)
But then when I try to execute lnusertemp manually, I can't find it. It seems never to have gotten installed.
What happened?
Temlakos
On 10/06/2012 03:35 AM, Temlakos wrote:
Everyone:
Just did a clean install to Fedora 17 (x86_64 architecture) and KDE 4.
I used the Users and Groups app. (authenticating with the root password) to create two new users to hook in with two directories on /home (from the previous installation).
But when I try to log into either one, I get this:
call to lnusertemp failed (/Temporary directories full?)
But then when I try to execute lnusertemp manually, I can't find it. It seems never to have gotten installed.
What happened?
lnusertemp does not exist in KDE 4.
On 10/05/2012 04:17 PM, Ed Greshko wrote:
On 10/06/2012 03:35 AM, Temlakos wrote:
Everyone:
Just did a clean install to Fedora 17 (x86_64 architecture) and KDE 4.
I used the Users and Groups app. (authenticating with the root password) to create two new users to hook in with two directories on /home (from the previous installation).
But when I try to log into either one, I get this:
call to lnusertemp failed (/Temporary directories full?)
But then when I try to execute lnusertemp manually, I can't find it. It seems never to have gotten installed.
What happened?
lnusertemp does not exist in KDE 4.
Ahem, /usr/libexec/kde4/lnusertemp
(it's an internal tool, not meant to be user-facing)
-- rex
On 10/06/2012 05:26 AM, Rex Dieter wrote:
Ahem, /usr/libexec/kde4/lnusertemp
(it's an internal tool, not meant to be user-facing)
Oooopsss...
On 10/05/2012 08:02 PM, Ed Greshko wrote:
On 10/06/2012 05:26 AM, Rex Dieter wrote:
Ahem, /usr/libexec/kde4/lnusertemp
(it's an internal tool, not meant to be user-facing)
Oooopsss...
Just for the record, I found the file. Thanks for letting me know where to find it, for future reference.
I solved my initial problem, though I must say my solution does /not/ satisfy. I had to make sure to re-create all my user accounts with the exact same UID. The trouble is, all those UIDs were in the 500s. I thought I could let the system designate them in the 1000s. But when I did that, I couldn't log in.
I'll have to continue this under separate cover, to get to the real issue.
Temlakos
Hi,
On Sun, Oct 7, 2012 at 2:41 AM, Temlakos temlakos@gmail.com wrote:
Just for the record, I found the file. Thanks for letting me know where to find it, for future reference.
locate lnusertemp (works only for file systems that are crawled by updatedb)
yum whatprovides */lnusertemp and using the output with rpm -ql (obviously works only for files provided by rpms)
www.google.com
are just a few of many different ways to locate a file on your machine.
I solved my initial problem, though I must say my solution does /not/ satisfy. I had to make sure to re-create all my user accounts with the exact same UID. The trouble is, all those UIDs were in the 500s. I thought I could let the system designate them in the 1000s. But when I did that, I couldn't log in.
UIDs are _unique identifiers_ of users that are used (among other things) to define access privileges for files. /etc/passwd provides the mapping between the numeric UIDs and the usernames. The latter don't mean much to the OS.If you have a home dir of a user with a certain UID on disk and you create the user in the system with a different UID, she will not be able to access her home dir. To fix that, either create the user with the same UID as used on the file system, or chown -R the directory to the UID:GID of your liking.
Cheers,
Andreas
-
Andreas Petzold -
Ed Greshko -
Rex Dieter -
Temlakos