Mount failed with error, "mount.nfs: access denied by server while mounting".

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux 10
  • Red Hat Enterprise Linux 9
  • Red Hat Enterprise Linux 8
  • Red Hat Enterprise Linux 7
  • NFS client

Issue

  • Mount failed with error mount.nfs: access denied by server while mounting
  • Unable to mount a NFS export at boot time

Resolution

  • If the NFS provider is RHEL, include insecure option in /etc/exports like below:

    # cat /etc/exports 
    /path/to/export *(rw,sync,no_root_squash,insecure)
    
  • Then re-export the share:

    # exportfs -rvf
    
  • Try to mount the NFS export from the NFS client.

  • Please refer to the solution Mounting the nfs share from a RHEL NFS server giver error "mount.nfs: access denied by server while mounting" and ensure the share is being exported to client in question.

    Note: Share should be unmounted from all the clients before making any configuration changes on the NFS server, else the share will become stale

Root Cause

  • The TCP/UDP ports in the range from 0 to 1024 are reserved for privileged services and designated as well-known ports.

  • The below error was captured on the NFS server side log, indicating it requires a secure port:

    rpc.mountd[8111]: refused mount request from *.*.*.* for /path/to/export (/path/to/export): illegal port 21645
    

Diagnostic Steps

  • The NFS server should be pingable and should be able to telnet on port 2049 and 111.

  • Check, if showmount -e <nfs server ip> command results in a hung?

  • Whether showmount -e <nfs_server_ip> comes back with no shares available (blank)?

    # showmount -e 1 <nfs-server-ip>
    Export list for <nfs-server-ip>
    
  • Ideally, it should appear with shares like below, if it's properly exported:

    # showmount -e <nfs-server-ip>
    Export list for <nfs-server-ip>
    /home   ***.***.***.0/24
    /export-1  ***.***.***.0/24
    /export2   ***.***.***.0/24
    
  • Check /var/lib/nfs/etab on the NFS server, for ensuring whether the share is properly exported?

  • The command rpcinfo -p <nfs_server_ip> displays list of all registered RPC programs. Verify that the needed services have the version being used (v3, v4, etc.)

    # rpcinfo -p <nfs_server_ip>
    program vers proto   port  service
    100000    2   udp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    3   udp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    4   tcp    111  portmapper
    100003    3   udp   2049  nfs
    100003    3   tcp   2049  nfs
    100005    1   udp    635  mountd
    100005    2   udp    635  mountd
    100005    3   udp    635  mountd
    100005    1   tcp    635  mountd
    100005    2   tcp    635  mountd
    100005    3   tcp    635  mountd
    100021    4   udp   4045  nlockmgr
    100021    4   tcp   4045  nlockmgr
    100024    1   udp   4046  status
    100024    1   tcp   4046  status
    
  • The packet capture analysis:

    # tshark -tad -n -r client.pcap -Y 'frame.number == 500' -O rpc | sed '/^Re/,$ !d'
    Remote Procedure Call, Type:Reply XID:0x3f510e1b
        Fragment header: Last fragment, 20 bytes
            1... .... .... .... .... .... .... .... = Last Fragment: Yes
            .000 0000 0000 0000 0000 0000 0001 0100 = Fragment Length: 20
        XID: 0x3f510e1b (1062276635)
        Message Type: Reply (1)
        [Program: NFS (100003)]
        [Program Version: 4]
        [Procedure: COMPOUND (1)]
        Reply State: denied (1)
        [This is a reply to a request in frame 498]
        [Time from request: 0.000611000 seconds]
        Reject State: AUTH_ERROR (1)                            <===== Error
        Auth State: bad credential (seal broken) (1)
    
    • The nfs-server can not authenticate the NFS client.
  • Further packet capture analysis:

    # tshark -tad -nr client.pcap -Y nfs.status!=0
    20 2018-12-18 13:46:46.377409  *.*.*.* → *.*.*.*  NFS 144 V4 Reply (Call In 12) PUTROOTFH | GETATTR Status: 
    NFS4ERR_PERM 
    
    • The error NFS4ERR_PERM indicates that the requester is not the owner. The operation was not allowed because the caller is neither a privileged user (root) nor the owner of the target of the operation.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments