Description of problem: We have NIS tables auto.HOME -> "UID server:/didxy/&" -> on login or su, the autofs can´t change to the provided automount point. Sollution: change to - "UID server:/didxy/UID" Version-Release number of selected component (if applicable): autofs-4.1.4-27 How reproducible: Every time! Steps to Reproduce: 1. login as root 2. su - uidxy 3. Actual results: On every userchange i´am getting: su - uid04278 su: warning: cannot change directory to /HOME/uid04278: Permission denied -> but login... On other userchanges, same error message, but a NO login Expected results: -> No error message, because the same user works with FC4 FC3 FC2 AS4 AS3 Additional info: All user have a auto.HOME of the form: uid server:/vol/did/& If i change the auto.HOME to the form: uid server:/vol/did/uid -> then the error message still happend -> but a login is possible always.
(In reply to comment #0) > Description of problem: > We have NIS tables auto.HOME -> "UID server:/didxy/&" > -> on login or su, the autofs can´t change to the provided automount point. > Sollution: change to - "UID server:/didxy/UID" > > Version-Release number of selected component (if applicable): > autofs-4.1.4-27 > > How reproducible: > Every time! > > > Steps to Reproduce: > 1. login as root > 2. su - uidxy > 3. > > Actual results: > On every userchange i´am getting: > su - uid04278 > su: warning: cannot change directory to /HOME/uid04278: Permission denied > -> but login... > > On other userchanges, same error message, but a NO login > > Expected results: > -> No error message, because the same user works with FC4 FC3 FC2 AS4 AS3 > > Additional info: > All user have a auto.HOME of the form: > uid server:/vol/did/& > > If i change the auto.HOME to the form: > uid server:/vol/did/uid > -> then the error message still happend -> but a login is possible always. FC4 and FC5 are the same so there must be more to this than just autofs. Can you provide a debug log of the failure using the process outlined under "Filling bug reports" at: http://people.redhat.com/jmoyer please. Ian
Created attachment 132163 [details] autfs debug Filing bug reports: ========================================================= autofs rpm version, obtained via 'rpm -q autofs' ========================================================================== -> autofs-4.1.4-16.2.2 kernel version, obtained via 'uname -r' ========================================================================== -> 2.6.16-1.2080_FC5 contents of your autofs maps. This includes auto.master and at least the map which is problematic for you. ========================================================================== -> ypcat auto.master auto.APPL -rw,hard auto.DISK -rw,hard auto.HOME -rw,hard auto.PROJ -rw,hard auto.TREE -rw,hard auto.VOL -rw,hard auto.C3P -rw,hard,nosuid auto.USER -rw,hard auto.CD -> ypcat -k auto.HOME | grep uid05059 uid05059 rbgs343x:/vol/vol0/did01109/home/& contents of /etc/nsswitch.conf ========================================================================== passwd: files nis shadow: files nis group: files nis hosts: files nis dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files nis rpc: files services: files nis netgroup: files nis publickey: nisplus automount: files nis aliases: files nisplus contents of /etc/sysconfig/autofs ========================================================================== LOCALOPTIONS="-D OS_MAJ=2 -D OSARCH=x86_64" DAEMONOPTIONS="--timeout=60" UNDERSCORETODOT=1 DISABLE_DIRECT=1 DAEMON_EXIT_WAIT=10 Steps to reproduce the problem, or circumstances surrounding the problem. ========================================================================== Just make a "su - uid", of try to login via ssh and strict key authentication -> so keys are not found -> so error [root@rbgv359x ~]# ypcat -k auto.HOME |grep uid04972 uid04972 rbgs343x:/vol/vol0/did01109/home/uid04972 [root@rbgv359x ~]# ypcat -k auto.HOME | grep uid06510 uid06510 rbgs343x:/vol/vol0/did01109/home/& [root@rbgv359x ~]# ypcat -k auto.HOME | grep uid05059 uid05059 rbgs343x:/vol/vol0/did01109/home/& uid04771 rbgs371x:/did01102/home/& uid15320 rbgs372x:/did01082/home/& uid14088 rbgs344x:/did01009/home/& debug output. Add a line like the following to your /etc/syslog.conf: ========================================================================== -> see attachment...
(In reply to comment #2) > Created an attachment (id=132163) [edit] > autfs debug > > Filing bug reports: > ========================================================= > > autofs rpm version, obtained via 'rpm -q autofs' > ========================================================================== > -> autofs-4.1.4-16.2.2 The log shows you are running with 4.1.4-27. > > kernel version, obtained via 'uname -r' > ========================================================================== > -> 2.6.16-1.2080_FC5 > > contents of your autofs maps. This includes auto.master and at least the map > which is problematic for you. > ========================================================================== > -> ypcat auto.master > auto.APPL -rw,hard > auto.DISK -rw,hard > auto.HOME -rw,hard > auto.PROJ -rw,hard > auto.TREE -rw,hard > auto.VOL -rw,hard > auto.C3P -rw,hard,nosuid > auto.USER -rw,hard > auto.CD > > -> ypcat -k auto.HOME | grep uid05059 > uid05059 rbgs343x:/vol/vol0/did01109/home/& > > contents of /etc/nsswitch.conf > ========================================================================== > passwd: files nis > shadow: files nis > group: files nis > hosts: files nis dns > bootparams: nisplus [NOTFOUND=return] files > ethers: files > netmasks: files > networks: files > protocols: files nis > rpc: files > services: files nis > netgroup: files nis > publickey: nisplus > automount: files nis > aliases: files nisplus > > contents of /etc/sysconfig/autofs > ========================================================================== > LOCALOPTIONS="-D OS_MAJ=2 -D OSARCH=x86_64" > DAEMONOPTIONS="--timeout=60" > UNDERSCORETODOT=1 > DISABLE_DIRECT=1 > DAEMON_EXIT_WAIT=10 > > Steps to reproduce the problem, or circumstances surrounding the problem. > ========================================================================== > Just make a "su - uid", of try to login via ssh and strict key authentication > -> so keys are not found -> so error > > [root@rbgv359x ~]# ypcat -k auto.HOME |grep uid04972 > uid04972 rbgs343x:/vol/vol0/did01109/home/uid04972 > [root@rbgv359x ~]# ypcat -k auto.HOME | grep uid06510 > uid06510 rbgs343x:/vol/vol0/did01109/home/& > [root@rbgv359x ~]# ypcat -k auto.HOME | grep uid05059 > uid05059 rbgs343x:/vol/vol0/did01109/home/& > uid04771 rbgs371x:/did01102/home/& > uid15320 rbgs372x:/did01082/home/& > uid14088 rbgs344x:/did01009/home/& > > > debug output. > Add a line like the following to your /etc/syslog.conf: > ========================================================================== > -> see attachment... The log show that the mounts succeed but your not able to sccess the mount point. Very strange. Can you send a "cat /proc/mounts" immediately after the failure please. Ian
Hi, hope thats ok: [root@rbgv359x ~]# su - uid05059 su: warning: cannot change directory to /HOME/uid05059: Permission denied [uid05059@rbgv359x ~]$ exit logout [root@rbgv359x ~]# cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext3 rw,data=ordered 0 0 /dev /dev tmpfs rw 0 0 /proc /proc proc rw 0 0 /sys /sys sysfs rw 0 0 /proc/bus/usb /proc/bus/usb usbfs rw 0 0 devpts /dev/pts devpts rw 0 0 /dev/sdb1 /appl ext3 rw,data=ordered 0 0 /dev/sda1 /boot ext3 rw,data=ordered 0 0 tmpfs /dev/shm tmpfs rw 0 0 /dev/sda5 /disk/disk1 ext3 rw,data=ordered 0 0 /dev/sdb3 /disk/disk2 ext3 rw,data=ordered 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0 automount(pid2024) /net autofs rw 0 0 automount(pid2092) /APPL autofs rw 0 0 automount(pid2158) /DISK autofs rw 0 0 automount(pid2229) /HOME autofs rw 0 0 automount(pid2306) /PROJ autofs rw 0 0 automount(pid2390) /TREE autofs rw 0 0 automount(pid2476) /VOL autofs rw 0 0 automount(pid2573) /team autofs rw 0 0 automount(pid2671) /USER autofs rw 0 0 nfsd /proc/fs/nfsd nfsd rw 0 0 rbgs343x:/vol/vol0/did01109/home/uid05059 /HOME/uid05059 nfs rw,v3,rsize=32768,wsize=32768,hard,lock,proto=tcp,addr=rbgs343x 0 0 THANKS a lot - eike
(In reply to comment #4) > Hi, > hope thats ok: > [root@rbgv359x ~]# su - uid05059 > su: warning: cannot change directory to /HOME/uid05059: Permission denied > [uid05059@rbgv359x ~]$ exit > logout > [root@rbgv359x ~]# cat /proc/mounts > rootfs / rootfs rw 0 0 > /dev/root / ext3 rw,data=ordered 0 0 > /dev /dev tmpfs rw 0 0 > /proc /proc proc rw 0 0 > /sys /sys sysfs rw 0 0 > /proc/bus/usb /proc/bus/usb usbfs rw 0 0 > devpts /dev/pts devpts rw 0 0 > /dev/sdb1 /appl ext3 rw,data=ordered 0 0 > /dev/sda1 /boot ext3 rw,data=ordered 0 0 > tmpfs /dev/shm tmpfs rw 0 0 > /dev/sda5 /disk/disk1 ext3 rw,data=ordered 0 0 > /dev/sdb3 /disk/disk2 ext3 rw,data=ordered 0 0 > none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 > sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0 > automount(pid2024) /net autofs rw 0 0 > automount(pid2092) /APPL autofs rw 0 0 > automount(pid2158) /DISK autofs rw 0 0 > automount(pid2229) /HOME autofs rw 0 0 > automount(pid2306) /PROJ autofs rw 0 0 > automount(pid2390) /TREE autofs rw 0 0 > automount(pid2476) /VOL autofs rw 0 0 > automount(pid2573) /team autofs rw 0 0 > automount(pid2671) /USER autofs rw 0 0 > nfsd /proc/fs/nfsd nfsd rw 0 0 > rbgs343x:/vol/vol0/did01109/home/uid05059 /HOME/uid05059 nfs > rw,v3,rsize=32768,wsize=32768,hard,lock,proto=tcp,addr=rbgs343x 0 0 Sorry, this doesn't look like an autofs problem. Can you mount this filesystem manually on a directory somewhere else to verify that the mount should work ok. Do you have any access control on this such as netgroups or other mechanism? Do you have selinux enabled? Is there anything in the log we may have missed? Is there anything in the server log from mountd or anything else that may be related to this? Ian
Hi, sorry - hadn´t the debug enabled... again: [root@rbgv359x ~]# date;cat /dev/null > /var/log/debug;su - uid05059 Tue Jul 11 10:45:08 CEST 2006 su: warning: cannot change directory to /HOME/uid05059: Permission denied -> debug file - see upload
Funny - the debug file is still empty after su...
I know now -> entered --log instead of debug on autofs -> changed and restarted... -> So again... [root@rbgv359x oracle]# date; cat /dev/null > /var/log/debug; su - uid05059 Tue Jul 11 10:58:02 CEST 2006 su: warning: cannot change directory to /HOME/uid05059: Permission denied [uid05059@rbgv359x ~]$ exit logout [root@rbgv359x oracle]# mount rbgs343x:/vol/vol0/did01109/home/uid05059 /mnt/ mount: rbgs343x:/vol/vol0/did01109/home/uid05059 already mounted or /mnt/ busy mount: according to mtab, rbgs343x:/vol/vol0/did01109/home/uid05059 is mounted on /mnt [root@rbgv359x oracle]# umount /mnt/ [root@rbgv359x oracle]# date Tue Jul 11 10:58:19 CEST 2006 [root@rbgv359x oracle]# mount rbgs343x:/vol/vol0/did01109/home/uid05059 /mnt/ [root@rbgv359x oracle]# umount /mnt/ Do you have selinux enabled? -> system-config-security-tui -> disabled /etc/system-config/selinux -> SELINUX=disabled Netgroups: Yes we are using them -> but should be ok, so the netgroups for the same host was woring with FC4 and also a manual mount is working...
Created attachment 132221 [details] the debug from today
(In reply to comment #8) > I know now -> entered --log instead of debug on autofs > -> changed and restarted... > -> So again... > [root@rbgv359x oracle]# date; cat /dev/null > /var/log/debug; su - uid05059 > Tue Jul 11 10:58:02 CEST 2006 > su: warning: cannot change directory to /HOME/uid05059: Permission denied OK, right here we want to get information about the environment as the user. Do an "ls -l". And maybe an "id". And "cat /proc/mounts". And "cat /etc/mtab". > [uid05059@rbgv359x ~]$ exit > logout > [root@rbgv359x oracle]# mount rbgs343x:/vol/vol0/did01109/home/uid05059 /mnt/ > mount: rbgs343x:/vol/vol0/did01109/home/uid05059 already mounted or /mnt/ busy > mount: according to mtab, rbgs343x:/vol/vol0/did01109/home/uid05059 is mounted > on /mnt > [root@rbgv359x oracle]# umount /mnt/ > [root@rbgv359x oracle]# date > Tue Jul 11 10:58:19 CEST 2006 > [root@rbgv359x oracle]# mount rbgs343x:/vol/vol0/did01109/home/uid05059 /mnt/ > [root@rbgv359x oracle]# umount /mnt/ > > Do you have selinux enabled? > -> system-config-security-tui -> disabled > /etc/system-config/selinux -> SELINUX=disabled > > > > Netgroups: > Yes we are using them -> but should be ok, so the netgroups for the same host > was woring with FC4 and also a manual mount is working... >
(In reply to comment #9) > Created an attachment (id=132221) [edit] > the debug from today > Once again this shows everything is working fine as far as autofs is concerned. We need to find out what else is wrong.
(In reply to comment #8) > > Netgroups: > Yes we are using them -> but should be ok, so the netgroups for the same host > was woring with FC4 and also a manual mount is working... Sure, the mount is working and the log confirms that. But my question was "do you use netgroups for host access control of your NFS mounts" but either way that doesn't appear to be the problem as the manual mount works. Hows' that, answering my own dumb questions now. So what about the netgroups setup for this user on this host (assuming your using netgroups for user access control). Can you verify that is all ok? Ian
(In reply to comment #10) > > -> So again... > > [root@rbgv359x oracle]# date; cat /dev/null > /var/log/debug; su - uid05059 > > Tue Jul 11 10:58:02 CEST 2006 > > su: warning: cannot change directory to /HOME/uid05059: Permission denied > > OK, right here we want to get information about the environment as > the user. > Do an "ls -l". And an "ls -ln". > And maybe an "id". > And "cat /proc/mounts". > And "cat /etc/mtab". > And a "ypmatch uid05059 passwd" (get rid of the crypt). And an "ls -l" and "ls -ln" of the directory on the server that is mounted by this login. Ian
We are using the netgroups to get a host based access controll of the HOME tree... -> So with the manual mount, it works as root -> so be also fine for a user on the same system... [root@rbgv359x ~]# su - uid05059 su: warning: cannot change directory to /HOME/uid05059: Permission denied [uid05059@rbgv359x ~]$ ls -l total 1080 -rw------- 1 uid05059 uid05059 999 Jun 7 16:29 dead.letter drwx------ 3 uid05059 uid05059 4096 Aug 4 2005 Desktop drwxrwx--- 5 uid05059 uid05059 4096 Jun 29 2005 DIPLOMARBEIT -rw-r--r-- 1 uid05059 uid05059 1065034 Dec 9 2005 export.log drwxrwx--- 5 uid05059 uid05059 4096 Jun 15 2005 OpenSSH drwxrwx--- 3 uid05059 uid05059 4096 Mar 12 2004 SCRIPTS drwxrwx--- 7 uid05059 uid05059 4096 Jun 15 2005 SOFTWARE drwxr-xr-x 3 root sys 4096 Aug 26 2005 ssh_script_new drwxr-xr-x 2 root sys 4096 Jun 25 2005 test [uid05059@rbgv359x ~]$ ls -ln total 1080 -rw------- 1 4086 4086 999 Jun 7 16:29 dead.letter drwx------ 3 4086 4086 4096 Aug 4 2005 Desktop drwxrwx--- 5 4086 4086 4096 Jun 29 2005 DIPLOMARBEIT -rw-r--r-- 1 4086 4086 1065034 Dec 9 2005 export.log drwxrwx--- 5 4086 4086 4096 Jun 15 2005 OpenSSH drwxrwx--- 3 4086 4086 4096 Mar 12 2004 SCRIPTS drwxrwx--- 7 4086 4086 4096 Jun 15 2005 SOFTWARE drwxr-xr-x 3 0 3 4096 Aug 26 2005 ssh_script_new drwxr-xr-x 2 0 3 4096 Jun 25 2005 test [uid05059@rbgv359x ~]$ id uid=4086(uid05059) gid=4086(uid05059) groups=4086(uid05059),4731(aida),10230 (wetp_int),107 96(linux),11196(unixadm) [uid05059@rbgv359x ~]$ cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext3 rw,data=ordered 0 0 /dev /dev tmpfs rw 0 0 /proc /proc proc rw 0 0 /sys /sys sysfs rw 0 0 /proc/bus/usb /proc/bus/usb usbfs rw 0 0 devpts /dev/pts devpts rw 0 0 /dev/sdb1 /appl ext3 rw,data=ordered 0 0 /dev/sda1 /boot ext3 rw,data=ordered 0 0 tmpfs /dev/shm tmpfs rw 0 0 /dev/sda5 /disk/disk1 ext3 rw,data=ordered 0 0 /dev/sdb3 /disk/disk2 ext3 rw,data=ordered 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0 nfsd /proc/fs/nfsd nfsd rw 0 0 automount(pid8908) /net autofs rw 0 0 automount(pid8966) /APPL autofs rw 0 0 automount(pid9031) /DISK autofs rw 0 0 automount(pid9103) /HOME autofs rw 0 0 automount(pid9179) /PROJ autofs rw 0 0 automount(pid9262) /TREE autofs rw 0 0 automount(pid9351) /VOL autofs rw 0 0 automount(pid9447) /team autofs rw 0 0 automount(pid9547) /USER autofs rw 0 0 rbgs343x:/vol/vol0/did01109/home/uid05059 /HOME/uid05059 nfs rw,v3,rsize=32768,wsize=32768 ,hard,lock,prot o=tcp,addr=rbgs343x 0 0 [uid05059@rbgv359x ~]$ cat /etc/mtab /dev/sda2 / ext3 rw 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 devpts /dev/pts devpts rw,gid=5,mode=620 0 0 /dev/sdb1 /appl ext3 rw 0 0 /dev/sda1 /boot ext3 rw 0 0 tmpfs /dev/shm tmpfs rw 0 0 /dev/sda5 /disk/disk1 ext3 rw 0 0 /dev/sdb3 /disk/disk2 ext3 rw 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0 nfsd /proc/fs/nfsd nfsd rw 0 0 automount(pid8908) /net autofs rw,fd=5,pgrp=8908,minproto=2,maxproto=4 0 0 automount(pid8966) /APPL autofs rw,fd=5,pgrp=8966,minproto=2,maxproto=4 0 0 automount(pid9031) /DISK autofs rw,fd=5,pgrp=9031,minproto=2,maxproto=4 0 0 automount(pid9103) /HOME autofs rw,fd=5,pgrp=9103,minproto=2,maxproto=4 0 0 automount(pid9179) /PROJ autofs rw,fd=5,pgrp=9179,minproto=2,maxproto=4 0 0 automount(pid9262) /TREE autofs rw,fd=5,pgrp=9262,minproto=2,maxproto=4 0 0 automount(pid9351) /VOL autofs rw,fd=5,pgrp=9351,minproto=2,maxproto=4 0 0 automount(pid9447) /team autofs rw,fd=5,pgrp=9447,minproto=2,maxproto=4 0 0 automount(pid9547) /USER autofs rw,fd=5,pgrp=9547,minproto=2,maxproto=4 0 0 rbgs343x:/vol/vol0/did01109/home/uid05059 /HOME/uid05059 nfs rw,hard,addr=144.145.75.143 0 0 [uid05059@rbgv359x ~]$ ypmatch uid05059 passwd uid05059:q81Wc2YLafP8.:4086:4086:Eike Ehringer, SV_IO_IT_BO_US Regensburg, Tel=+49 (941) 7 90-4559, Kst=R528, uid05059,19.05.06 16.45,:/HOME/uid05059:/bin/csh ========================== [root@rbgv359x TREE]# ls -l total 4 drwxr-xr-x 6 root root 4096 May 13 2004 did01109 [root@rbgv359x TREE]# cd did01109/ [root@rbgv359x did01109]# ls -l total 16 drwxr-xr-x 2 root bin 4096 May 14 2004 _AccessRights_FolderResponsibles drwxr-xr-x 57 root root 8192 Jul 7 07:16 home drwxr-xr-x 4 root root 4096 Feb 6 12:24 proj [root@rbgv359x did01109]# cd home/ [root@rbgv359x home]# ls -l | grep uid05059 drwxrws--- 26 uid05059 uid05059 20480 Jun 7 16:29 uid05059 Does this help? Looks all fine... for me...
(In reply to comment #14) > [root@rbgv359x ~]# su - uid05059 > su: warning: cannot change directory to /HOME/uid05059: Permission denied > [uid05059@rbgv359x ~]$ ls -l > total 1080 > -rw------- 1 uid05059 uid05059 999 Jun 7 16:29 dead.letter > drwx------ 3 uid05059 uid05059 4096 Aug 4 2005 Desktop > drwxrwx--- 5 uid05059 uid05059 4096 Jun 29 2005 DIPLOMARBEIT > -rw-r--r-- 1 uid05059 uid05059 1065034 Dec 9 2005 export.log > drwxrwx--- 5 uid05059 uid05059 4096 Jun 15 2005 OpenSSH > drwxrwx--- 3 uid05059 uid05059 4096 Mar 12 2004 SCRIPTS > drwxrwx--- 7 uid05059 uid05059 4096 Jun 15 2005 SOFTWARE > drwxr-xr-x 3 root sys 4096 Aug 26 2005 ssh_script_new > drwxr-xr-x 2 root sys 4096 Jun 25 2005 test I guess a "pwd" shows you are in fact in /HOME/uid05059. Is that right? I think you said that this does work but the error message is odd. And also that it sometimes didn't work, correct? Perhaps this is a bug in "su". I'm stumped. > > Does this help? Looks all fine... for me... Looks fine to me also. The only other thing I would check is to do a "getent passwd uid05059" on the client and make sure the user profile it sees is the same as NIS. But I don't expect that will show anything unusual. Ian Ian
Yes - correct - /HOME/ [root@rbgv359x ~]# su - uid05059 su: warning: cannot change directory to /HOME/uid05059: Permission denied [uid05059@rbgv359x ~]$ pwd /HOME/uid05059 [uid05059@rbgv359x ~]$ getent passwd uid05059 uid05059:q81Wc2YLafP8.:4086:4086:Eike Ehringer, SV_IO_IT_BO_US Regensburg, Tel=+49 (941) 790-4559, Kst=R528, uid05059,19.05.06 16.45,:/HOME/uid05059:/bin/csh [uid05059@rbgv359x ~]$ Question: How can we get rid of the error message?
(In reply to comment #16) > Yes - correct - /HOME/ > > [root@rbgv359x ~]# su - uid05059 > su: warning: cannot change directory to /HOME/uid05059: Permission denied > [uid05059@rbgv359x ~]$ pwd > /HOME/uid05059 > [uid05059@rbgv359x ~]$ getent passwd uid05059 > uid05059:q81Wc2YLafP8.:4086:4086:Eike Ehringer, SV_IO_IT_BO_US Regensburg, > Tel=+49 (941) 790-4559, Kst=R528, uid05059,19.05.06 > 16.45,:/HOME/uid05059:/bin/csh > [uid05059@rbgv359x ~]$ > > Question: > How can we get rid of the error message? Oh .. that would be your original question .. haha. You have other systems that are functioning ok so I'd check versions. Find one that is working with a reasonably recent version and grab the srpm and build it on the fc4 machine and see if that helps. That's the "coreutils" package. Ian
(In reply to comment #17) > (In reply to comment #16) > > Yes - correct - /HOME/ > > > > [root@rbgv359x ~]# su - uid05059 > > su: warning: cannot change directory to /HOME/uid05059: Permission denied > > [uid05059@rbgv359x ~]$ pwd > > /HOME/uid05059 > > [uid05059@rbgv359x ~]$ getent passwd uid05059 > > uid05059:q81Wc2YLafP8.:4086:4086:Eike Ehringer, SV_IO_IT_BO_US Regensburg, > > Tel=+49 (941) 790-4559, Kst=R528, uid05059,19.05.06 > > 16.45,:/HOME/uid05059:/bin/csh > > [uid05059@rbgv359x ~]$ > > > > Question: > > How can we get rid of the error message? > > Oh .. that would be your original question .. haha. > > You have other systems that are functioning ok so I'd > check versions. Find one that is working with a reasonably > recent version and grab the srpm and build it on the fc4 > machine and see if that helps. > > That's the "coreutils" package. Of course first check you have the latest fc4 update available first. We really should be assigning this bz to the coreutils maintainer. He's likely to have a much better idea of what's going on here. One more round here and we'll do that OK. Ian
Hi, thanks for your help!! Well we have a lot of FC3 and FC4 systems with no problem.... actually, i updated the systems the last weekend :-) -> Last update bevore migrating to FC5 What exact packages would you like to know? Please offer my a list of what to do... thanks eike
(In reply to comment #19) > Hi, > thanks for your help!! > Well we have a lot of FC3 and FC4 systems with no problem.... > > actually, i updated the systems the last weekend :-) > -> Last update bevore migrating to FC5 > > What exact packages would you like to know? > Please offer my a list of what to do... The problem you have appears to be with the coreutils su program so can we compare versions on serveral FC4 systems please. I looks like the last update was August 2005. Maybe reinstalling the package would help. I can't see any reason for this happening. Ian
Good morning! How was your weekend? Sorry for the delay - had to migrate a Oracle DB... FC5: coreutils-5.96-1.2 ( rbgv359x ) FC3: coreutils-5.2.1-31 ( rbgs401x ) FC4: coreutils-5.2.1-48.1 ( rbgs402x ) FC4: coreutils-5.2.1-48.1 ( rbgs403x ) FC3: coreutils-5.2.1-31 ( rbgs404x ) FC4: coreutils-5.2.1-48.1 ( rbgs405x ) FC4: coreutils-5.2.1-48.1 ( rbgs406x ) FC4: coreutils-5.2.1-48.1 ( rbgs407x ) FC4: coreutils-5.2.1-48.1 ( rbgs408x ) -> So you see, we are using the same version on all FC4s -> 5.2.1-48.1 -> So you see, we are using the same version on all FC3s -> 5.2.1-31
(In reply to comment #21) > Good morning! > How was your weekend? Busy! > Sorry for the delay - had to migrate a Oracle DB... > FC5: coreutils-5.96-1.2 ( rbgv359x ) How about downgrading this to the version that was shipped with FC5, coreutils-5.93-7.2.i386.rpm. Basically we need to change something to see if we can find out what's going on. Ian
We can do this... I´am in vecation next week! Would give you a response the days after... Thanks - Eike
Hello, how are you? Well, i´am back from vecation. Downgreated and retried: # su - uid05059 su: warning: cannot change directory to /HOME/uid05059: Permission denied [uid05059@rbgv359x ~]$ date Mon Jul 31 13:33:15 CEST 2006 [uid05059@rbgv359x ~]$ rpm -q coreutils coreutils-5.93-7.2 -> does not help! -> Tried one of the latest of FC4 x86_64 [root@rbgv359x:~$] # cd /PROJ/linux/install/fc4-amd64/Update/ [root@rbgv359x:/PROJ/linux/install/fc4-amd64/Update$] # rpm -Uvh --force coreutils-5.2.1-48.1.x86_64.rpm warning: coreutils-5.2.1-48.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 Preparing... ########################################### [100%] 1:coreutils ########################################### [100%] [root@rbgv359x:/PROJ/linux/install/fc4-amd64/Update$] # su - uid05059 [uid05059@rbgv359x ~]$ exit logout [root@rbgv359x:/PROJ/linux/install/fc4-amd64/Update$] # rpm -q coreutils coreutils-5.2.1-48.1 [root@rbgv359x:/PROJ/linux/install/fc4-amd64/Update$] -> WORKS!!!! -> ? May a BUG in coreutils ? bye eike
Good morning! How are you? Well do you have some news according the coreutils? Is there a BUG then in coreutils from FC5? I already retried the sittuation, installed a fresh FC5 -> Had the problem -> installed coreutils-5.2.1-48.1 from FC4 -> -> NO PROBLEMS!
(In reply to comment #25) > Good morning! > How are you? > Well do you have some news according the coreutils? > Is there a BUG then in coreutils from FC5? > I already retried the sittuation, installed a fresh FC5 > -> Had the problem > -> installed coreutils-5.2.1-48.1 from FC4 > -> -> NO PROBLEMS! Sorry, I should have reassigned this to coreutils. I'll do that now. Ian
Thanks for information! -> if you reassign this, the call number is still the same?
I would like to see the system calls that 'su' makes. To do that, I'll need to you follow these steps: 1. Get a root login (i.e. the '#' prompt) and find out the PID of the bash process like this: 'echo $$'. Leave that terminal alone for the moment. 2. Get another root login and run this command: strace -p 5000 2>su.log (replace '5000' with the PID of the first root login) 3. Now, in the first root login, run the su command. 4. When you see the error message, press control-C on the second ('strace') root login, and attach that su.log file here. Thanks.
Hi, # echo $$ 19943
Created attachment 134629 [details] su.log
Thanks. Now please do the same again, but this time with the 'f' option: strace -fp 5000 2>su.log
Created attachment 134692 [details] strace -fp
Thanks. Please try this test update 5.97-1.2: https://www.redhat.com/archives/fedora-test-list/2006-August/msg00385.html You should be able to do that with: yum --enablerepo=updates-testing update coreutils once the mirrors have been updated.
Hi, done it: # rpm -q coreutils coreutils-5.93-7.2 [rooteieh@rbgv359x:~$] # ls -l | grep core -rw-r--r-- 1 rootmara root 3715358 Aug 24 11:24 coreutils-5.97-1.2.x86_64.rpm [rooteieh@rbgv359x:~$] # rpm -Fvh coreutils-5.97-1.2.x86_64.rpm warning: coreutils-5.97-1.2.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 30c9ecf8 Preparing... ########################################### [100%] 1:coreutils ########################################### [100%] [rooteieh@rbgv359x:~$] # su - uid05059 -> -> WORKS!!! So was this a BUG? When could be a permanent fix?
An update has been issued to fix this problem.
Thanks a lot! Can you estimate a time, when the update will be released? I don´t have any experience with the timeline of the Fedora-Releases
It was released on August 24th -- see comment #35.