Results 1 to 4 of 4

Thread: rpcinfo -u localhost 100003 4 command fails for nfsv 4

  1. #1

    Unhappy rpcinfo -u localhost 100003 4 command fails for nfsv 4

    Hi

    We found that below command fails:
    #rpcinfo -u localhost 100003 4
    rpcinfo: RPC: Program/version mismatch; low version = 3, high version = 4
    program 100003 version 4 is not available

    rpcinfo -p localhost
    program vers proto port service
    100000 4 tcp 111 portmapper
    100000 3 tcp 111 portmapper
    100000 2 tcp 111 portmapper
    100000 4 udp 111 portmapper
    100000 3 udp 111 portmapper
    100000 2 udp 111 portmapper
    100024 1 udp 54697 status
    100024 1 tcp 57111 status
    100005 1 udp 20048 mountd
    100005 1 tcp 20048 mountd
    100005 2 udp 20048 mountd
    100005 2 tcp 20048 mountd
    100005 3 udp 20048 mountd
    100005 3 tcp 20048 mountd
    100003 3 tcp 2049 nfs
    100003 4 tcp 2049 nfs
    100227 3 tcp 2049 nfs_acl
    100003 3 udp 2049 nfs
    100227 3 udp 2049 nfs_acl
    100021 1 udp 42289 nlockmgr
    100021 3 udp 42289 nlockmgr
    100021 4 udp 42289 nlockmgr
    100021 1 tcp 41387 nlockmgr
    100021 3 tcp 41387 nlockmgr
    100021 4 tcp 41387 nlockmgr

    not able to get the nfs service listen for udp hence the command "rpcinfo -u localhost 100003 4 fails."
    Can you please help us to correct this configuration. Are we doing any configuration wrong ?

    Thanks

  2. Re: rpcinfo -u localhost 100003 4 command fails for nfsv 4

    H ishasthrisuse,

    from RFC5661 (NFS v4.1) section 2.9.1 (https://tools.ietf.org/html/rfc5661):

    Where an NFSv4.1 implementation supports operation over the IP
    network protocol, any transport used between NFS and IP MUST be among
    the IETF-approved congestion control transport protocols. At the
    time this document was written, the only two transports that had the
    above attributes were TCP and the Stream Control Transmission
    Protocol (SCTP).

    [...]

    It is permissible for a connectionless transport to be used under
    NFSv4.1; however, reliable and in-order delivery of data combined
    with congestion control by the connectionless transport is REQUIRED.
    As a consequence, UDP by itself MUST NOT be used as an NFSv4.1
    transport.
    Likely that's why you see UDP for NFSv3 only.

    With regards,
    J
    From the times when today's "old school" was "new school"

    If you find this post helpful and are logged into the web interface, show your appreciation and click on the star below...

  3. #3

    Re: rpcinfo -u localhost 100003 4 command fails for nfsv 4

    Quote Originally Posted by jmozdzen View Post
    H ishasthrisuse,

    from RFC5661 (NFS v4.1) section 2.9.1 (https://tools.ietf.org/html/rfc5661):



    Likely that's why you see UDP for NFSv3 only.

    With regards,
    J

    Thank you jmozdzen for your inputs.
    But the concern is atleast it should have allowed us to ping localhost. another observation is , all other distros including SLES till SLES 15 had allowed to ping nfs program 100003 via udp and rpcinfo -p was listing the same.But suddenly the entry "100003 4 udp 2049 nfs" has disappeared in SLES 15. Was it done knowingly or we have to do some configuration to get this back.?

  4. Re: rpcinfo -u localhost 100003 4 command fails for nfsv 4

    Hi shasthrisuse,

    Quote Originally Posted by shasthrisuse View Post
    Thank you jmozdzen for your inputs.
    But the concern is atleast it should have allowed us to ping localhost.
    I don't see why? If the service (prognum/progvers/proto combo) isn't registered with portmapper, you won't be able to "ping" it. (I guess you're referring to the "-u" option to rpcinfo, which will call RPC function "0" of a registered RPC service)

    Quote Originally Posted by shasthrisuse View Post
    another observation is , all other distros including SLES till SLES 15 had allowed to ping nfs program 100003 via udp and rpcinfo -p was listing the same.But suddenly the entry "100003 4 udp 2049 nfs" has disappeared in SLES 15. Was it done knowingly or we have to do some configuration to get this back.?
    I'm still trying to locate info on that. To me, it looks like adopting to the RFCs, but would have expected some info in i.e. the release notes. Other distros even made the move to only enable TCP, by default (meaning that even v3 would be available only via TCP), but a look at /etc/nfs.conf reveals that the SLES 15 version still does default to udp=yes, tcp=yes.

    If I find out more, I'll report back here.

    Regards,
    J
    From the times when today's "old school" was "new school"

    If you find this post helpful and are logged into the web interface, show your appreciation and click on the star below...

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •