Below are the results of a simple umount command, it occurs in exactly the same way in FC6-rel and in the 1.0.10-3.fc6 update package. # umount /mnt umount.nfs: 1.2.3.4:/fc6: not found / mounted or server not reachable umount.nfs: 1.2.3.4:/fc6: not found / mounted or server not reachable # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/mta-root 7935392 1003916 6521876 14% / /dev/hda1 101086 10817 85050 12% /boot tmpfs 387396 0 387396 0% /dev/shm 1.2.3.4:/fc6 164171200 122169664 42001536 75% /mnt # rm /sbin/umount.nfs # umount /mnt # It seems that the regular umount command works where umount.nfs doesn't.hh
Is there any kind of avc denied messages in /var/log/messages?
There isn't, and the bug works in exactly the same manner in permissive mode. If there was an SE Linux issue related to this I would have discovered it and sent a policy patch upstream. iptables -I INPUT -p tcp --dport 909 -j ACCEPT After examining tcpdump output it seems that a rejected attempt to connect to port 909 via TCP is the problem. I ran the above on my NFS server (which runs FC5) and things started working.
Sorry about that, my browser cached the password for my redhat.com account. It would probably be good if my redhat.com account was closed...
Cool....
Why is it not a bug that there is a new umount program that suddenly makes things stop working? Why is it not a bug that a network which has worked essentially unchanged since Fedora Core 1 days suddenly breaks on Fedora Core 6? Incidentally is there any code in the nfs server start scripts for FC6 to enable that port in the firewall? If not you'll get other similar reports.
Sorry about that... I misread Comment #4 as this not being a problem... Could you post some of those tcpdump (bzip2 please). I would like to see what your seeing...
07:27:43.200484 IP CLIENT.42810 > SERVER.sunrpc: F 61:61(0) ack 33 win 46 <nop,nop,timestamp 4294956294 19499187> 07:27:43.200686 IP SERVER.sunrpc > CLIENT.42810: F 33:33(0) ack 62 win 46 <nop,nop,timestamp 19499188 4294956294> 07:27:43.200723 IP CLIENT.42810 > SERVER.sunrpc: . ack 34 win 46 <nop,nop,timestamp 4294956294 19499188> 07:27:43.201291 IP CLIENT.46301 > SERVER.ideafarm-catch: S 2583767313:2583767313(0) win 5840 <mss 1460,sackOK,timestamp 4294956294 0,nop,wscale 7> 07:27:43.201408 IP SERVER > CLIENT: ICMP host SERVER unreachable - admin prohibited, length 68 07:27:43.202067 IP CLIENT.826 > SERVER.ideafarm-catch: S 2575525337:2575525337 (0) win 5840 <mss 1460,sackOK,timestamp 4294956294 0,nop,wscale 7> 07:27:43.202178 IP SERVER > CLIENT: ICMP host SERVER unreachable - admin prohibited, length 68 07:27:43.206475 IP CLIENT.46971 > SERVER.sunrpc: S 2587867624:2587867624(0) win 5840 <mss 1460,sackOK,timestamp 4294956295 0,nop,wscale 7> 07:27:43.206595 IP SERVER.sunrpc > CLIENT.46971: S 2645547725:2645547725(0) ack 2587867625 win 5792 <mss 1460,sackOK,timestamp 19499189 4294956295,nop,wscale 7> 07:27:43.206676 IP CLIENT.46971 > SERVER.sunrpc: . ack 1 win 46 <nop,nop,timestamp 4294956295 19499189> 07:27:43.207376 IP CLIENT.46971 > SERVER.sunrpc: P 1:61(60) ack 1 win 46 <nop,nop,timestamp 4294956296 19499189> 07:27:43.207570 IP SERVER.sunrpc > CLIENT.46971: . ack 61 win 46 <nop,nop,timestamp 19499189 4294956296> 07:27:43.207683 IP SERVER.sunrpc > CLIENT.46971: P 1:33(32) ack 61 win 46 <nop,nop,timestamp 19499189 4294956296> 07:27:43.207732 IP CLIENT.46971 > SERVER.sunrpc: . ack 33 win 46 <nop,nop,timestamp 4294956296 19499189> 07:27:43.208284 IP CLIENT.46971 > SERVER.sunrpc: F 61:61(0) ack 33 win 46 <nop,nop,timestamp 4294956296 19499189> 07:27:43.208403 IP SERVER.sunrpc > CLIENT.46971: F 33:33(0) ack 62 win 46 <nop,nop,timestamp 19499190 4294956296> 07:27:43.208432 IP CLIENT.46971 > SERVER.sunrpc: . ack 34 win 46 <nop,nop,timestamp 4294956296 19499190> 07:27:43.209059 IP CLIENT.49566 > SERVER.ideafarm-catch: S 2581594611:2581594611(0) win 5840 <mss 1460,sackOK,timestamp 4294956296 0,nop,wscale 7> 07:27:43.209165 IP SERVER > CLIENT: ICMP host SERVER unreachable - admin prohibited, length 68 07:27:43.209820 IP CLIENT.827 > SERVER.ideafarm-catch: S 2585809004:2585809004 (0) win 5840 <mss 1460,sackOK,timestamp 4294956296 0,nop,wscale 7> 07:27:43.209931 IP SERVER > CLIENT: ICMP host SERVER unreachable - admin prohibited, length 68 From the client: # rpcinfo -p SERVER | grep 903 100005 1 tcp 903 mountd 100005 2 tcp 903 mountd 100005 3 tcp 903 mountd I can provide tcpdump capture files if that helps, but it seems that the plain text output is providing all that's needed.
Just curious... if you bring up both TCP and UDP on the server, does umount start to work?
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.