Bug 36861 - nis users from rh6 can not login to rh71 kde2
nis users from rh6 can not login to rh71 kde2
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Pete Zaitcev
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-20 13:26 EDT by David Westfall
Modified: 2007-04-18 12:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-20 13:26:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Westfall 2001-04-20 13:26:23 EDT
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 14:16:06 EDT
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.