This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 882097 - NFS can't mount users directories
NFS can't mount users directories
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-11-30 00:31 EST by Vasiliy Glazov
Modified: 2014-02-05 08:25 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-02-05 08:25:33 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
tcpdump (15.63 KB, application/vnd.tcpdump.pcap)
2013-02-18 16:46 EST, Anthony Messina
no flags Details

  None (edit)
Description Vasiliy Glazov 2012-11-30 00:31:36 EST
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):

How reproducible:

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 ~/nfs

Actual results:
mount.nfs: timeout set for Fri Nov 30 09:27:06 2012
mount.nfs: trying text-based options 'vers=4,addr=,clientaddr='
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting

Expected results:
Normal mounting

Additional info:
When I mount second share it mount normally:
#mount ~/nfs

mount.nfs: timeout set for Fri Nov 30 09:31:46 2012
mount.nfs: trying text-based options 'vers=4,addr=,clientaddr='

Please help me.
Comment 1 J. Bruce Fields 2012-11-30 09:43:07 EST
I wonder if this is the same issue as Neil reported here:<20120918112329.7d88ed9e@notabene.brown>

What are the permissions on the directory /home?  Do you have the same problem if you use NFSv3 (mount -overs=3).
Comment 2 Vasiliy Glazov 2012-11-30 11:24:30 EST
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.
Comment 3 Anthony Messina 2013-02-17 14:30:10 EST
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:


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.
Comment 4 J. Bruce Fields 2013-02-18 11:26:51 EST
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.)
Comment 5 Anthony Messina 2013-02-18 16:46:28 EST
Created attachment 699163 [details]

tcpdump on the server, where dst and src below are the client:
tcpdump -s0 -wtmp.pcap dst host or src host
Comment 6 J. Bruce Fields 2013-02-19 09:19:04 EST
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.
Comment 7 Anthony Messina 2013-02-19 09:24:33 EST
~]# 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
Comment 8 J. Bruce Fields 2013-02-19 09:52:05 EST
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.
Comment 9 Anthony Messina 2013-02-19 10:41:19 EST
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] 1 0x00000000 /export/media/video/tv0                                                                                                                                                                                   6 0x9211ebbaa763bff20000000000000000 /export/media/video/tv0

# cat /proc/net/rpc/nfsd.export/content                                                                                                                                                                            
#path domain(flags)                                                                                                                                                                                                                          
Comment 10 Fedora End Of Life 2013-12-21 04:34:02 EST
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.
Comment 11 Fedora End Of Life 2014-02-05 08:25:39 EST
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

Thank you for reporting this bug and we are sorry it could not be fixed.

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