Description of problem: NFS not work. I can't mount directories like /home/vascom/nfs. But /home/vascom mount normally. Version-Release number of selected component (if applicable): nfs-utils-1.2.6-14.fc18.x86_64 How reproducible: Always. Steps to Reproduce: 1. Content of /etc/exports /home/vascom *(ro,sync) /home/vascom/nfs *(ro,sync) 2. Start nfs-server via systemctl, open nfs in system-config-firewall. 3. Try mount shares on client (F17): #mount 192.168.0.2:/home/vascom/nfs ~/nfs Actual results: mount.nfs: timeout set for Fri Nov 30 09:27:06 2012 mount.nfs: trying text-based options 'vers=4,addr=192.168.0.2,clientaddr=192.168.0.3' mount.nfs: mount(2): Permission denied mount.nfs: access denied by server while mounting 192.168.0.2:/home/vascom/nfs Expected results: Normal mounting Additional info: When I mount second share it mount normally: #mount 192.168.0.2:/home/vascom ~/nfs mount.nfs: timeout set for Fri Nov 30 09:31:46 2012 mount.nfs: trying text-based options 'vers=4,addr=192.168.0.2,clientaddr=192.168.0.3' Please help me.
I wonder if this is the same issue as Neil reported here: http://mid.gmane.org/<20120918112329.7d88ed9e> What are the permissions on the directory /home? Do you have the same problem if you use NFSv3 (mount -overs=3).
ll -Z for this directories: drwx------. vascom vascom unconfined_u:object_r:user_home_dir_t:s0 vascom drwxrwxrwx. vascom vascom unconfined_u:object_r:user_home_t:s0 nfs nfs not mounted even if drwxrwxrwx. With mount -overs=3 I have the same results.
I can report a near identical issue on an F18 machine, upgraded with fedup from F17. In this case, I am using NFSv4.1 with sec=krb5p, and my /etc/exports is as follows: /export 10.77.79.0/24(fsid=0,crossmnt,sec=krb5p) /export/media/video/tv0 10.77.79.0/24(ro,sec=krb5p) /export/media/video/tv1 10.77.79.0/24(ro,sec=krb5p) My /export directory permission structure is as follows: 0755 /export 0750 /export/media 0750 /export/media/video 0750 /export/media/video/tv0 0750 /export/media/video/tv1 Of perhaps significant note, this F18 server is also an NFSv4.1 client of an F17 server running sec=krb5p. All servers have added "+4.1" to /proc/fs/nfsd/versions and all clients have added "minorversion=1" to their mount options in /etc/fstab. My local F18 (MythTV) clients all receive the "mount.nfs: mount(2): Permission denied" error, just as above, while this exact same configuration worked perfectly just a few hours ago (before the fedup upgrade). I have no SELinux errors in either enforcing or permissive mode. I can telnet to port 2049 without issue. Also of my servers have used RPCNFSDARGS="-N 2 -N 3 -U" for quite some time. I have tried changing the permissions on the /export folders according to the reference in comment #1 to no avail.
Could I see a network trace? So: tcpudmp -s0 -wtmp.pcap, then reproduce the problem, the kill tcpdump and attach tmp.pcap to this report. If you're using krb5p, first try to reproduce with krb5. (Otherwise the encryption makes the trace unreadable.)
Created attachment 699163 [details] tcpdump tcpdump on the server, where dst and src below are the client: tcpdump -s0 -wtmp.pcap dst host 10.77.79.103 or src host 10.77.79.103
I ran "wireshark tmp.pcap" and took a look. Frame 65 has the reply to a putrootfh/getfh sequence which gives us the root filehandle with hash 0x86d21d96. Frame 81 and 82 have an access call on that filehandle which shows lookup permissions are denied. What are the permissions on "/"? They probably need to permit at least execute to anyone.
~]# ls -la / total 160 dr-xr-xr-x. 19 root root 4096 Feb 17 14:19 . dr-xr-xr-x. 19 root root 4096 Feb 17 14:19 .. lrwxrwxrwx. 1 root root 7 Feb 17 06:54 bin -> usr/bin dr-xr-xr-x. 5 root root 3072 Feb 17 07:15 boot drwxr-xr-x. 20 root root 3780 Feb 19 06:50 dev drwxr-xr-x. 111 root root 12288 Feb 19 06:50 etc drwxr-xr-x. 3 root root 4096 Jun 18 2012 export drwxr-xr-x. 12 root root 4096 Oct 17 10:49 home lrwxrwxrwx. 1 root root 7 Feb 17 06:54 lib -> usr/lib lrwxrwxrwx. 1 root root 9 Feb 17 06:54 lib64 -> usr/lib64 drwx------. 2 root root 16384 Jun 18 2012 lost+found drwxr-xr-x. 2 root root 4096 Feb 3 2012 media drwxr-xr-x. 3 root root 4096 Jul 19 2012 mnt drwxr-xr-x. 2 root root 4096 Jul 19 2012 opt dr-xr-xr-x. 164 root root 0 Feb 19 06:50 proc -rw-r--r--. 1 root root 83651 Feb 17 14:19 .readahead dr-xr-x---. 9 root root 4096 Feb 19 08:23 root drwxr-xr-x. 27 root root 920 Feb 19 07:16 run lrwxrwxrwx. 1 root root 8 Feb 17 06:54 sbin -> usr/sbin drwxr-xr-x. 3 root root 4096 Jul 19 2012 srv dr-xr-xr-x. 13 root root 0 Feb 19 06:50 sys drwxrwxrwt. 9 root root 220 Feb 19 08:23 tmp drwxr-xr-x. 13 root root 4096 Feb 17 06:54 usr drwxr-xr-x. 18 root root 4096 Feb 17 06:54 var
Whoops, sorry I see you were using fsid=0 on /export so putrootfh is taking us to /export, so it's the permissions on /export, not /, that matter.... That said, /export looks like it permits read and execute to everyone, and you say you have selinux turned on, and there's no sign of ACLs on /export, so I'm at a loss. Might be interesting to see the contents of /proc/net/rpc/nfsd.fh/content and /proc/net/rpc/nfsd.export/content after the failed mount.
As mentioned earlier, my /export directory permission structure is as follows an is what I've been using for years. If each subdirectory now requires execute permission for the world user, that is a change. 0755 /export 0750 /export/media 0750 /export/media/video 0750 /export/media/video/tv0 0750 /export/media/video/tv1 Here is the contents requested in comment #8. # cat /proc/net/rpc/nfsd.fh/content #domain fsidtype fsid [path] 10.77.79.0/24 1 0x00000000 /export/media/video/tv0 10.77.79.0/24 6 0x9211ebbaa763bff20000000000000000 /export/media/video/tv0 # cat /proc/net/rpc/nfsd.export/content #path domain(flags) /export 10.77.79.0/24(ro,root_squash,sync,wdelay,crossmnt,no_subtree_check,fsid=0,uuid=f845cdb8:ca481901:00000000:00000000,sec=390003) /export/media/video/tv0 10.77.79.0/24(ro,root_squash,sync,wdelay,no_subtree_check,uuid=baeb1192:f2bf63a7:00000000:00000000,sec=390003)
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.