Bug 36861 - nis users from rh6 can not login to rh71 kde2
Summary: nis users from rh6 can not login to rh71 kde2
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils
Version: 7.1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-04-20 17:26 UTC by David Westfall
Modified: 2007-04-18 16:32 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-04-20 17:26:27 UTC
Embargoed:


Attachments (Terms of Use)

Description David Westfall 2001-04-20 17:26:23 UTC
After cpu was installed with rh71/kde2, our nis users would be asked if
they wanted there kde1 files to be converted, removed, or ingored.  If
remove or convert is picked kde2 dies saying 
	could not read connection list /home/dave/.DCOPserver_dexter_0:0
	please check that the "dcopserver" program is running.

If you pick ignor kde2 starts ok.  In trying to track down the problem we
noticed that root could not delete files that it owned that were on a NFS
mount.  We also notcied that the files in .kde director for each user were
owned by root.  This is were the problem for kde2 is, it can not remove or
convert these files because they are owned by root and are on a NFS
automount.  We have not found out which version created these files with
root owning them.  We have a SGI origin200 serving our nis and automount. 
We have been using RH 60 61 62 and 70 with no problem.  We can work around
by deleteing .kde before a user trys to login in to rh71 for the first
time.

Comment 1 Bernhard Rosenkraenzer 2001-04-23 18:16:06 UTC
We don't (and can't) create those files owned by root anywhere (if we did this,
it would mean we're 
allowing users to create files as root).

If the .kde files are not writable, KDE 1.x didn't work well either (users
couldn't save their settings).

This must be a local setup problem.

By any chance, did someone chown those files on your system to prevent users
from messing up their desktop, or did someone cp -aR /etc/skel/.kde ~usename as
root?


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