NFS only mount with -o udp option

NFS only mount with -o udp option

[Edgar Almonte]

hello list

like the subject say after some upgrade of my distro ( i have 2
machine with the same distro and only in one happne the problem ) i
can only mount nfs share using the option -o udp , without it i get
this error
mount.nfs: mount system call failed

i am using avahi-dns ( mdns ) for hostname resolve

command used:
mount heaven.local:/STORAGE /nfs/STORAGE/
check dns is work right :

 ping heaven.local
PING heaven.local (192.168.1.102) 56(84) bytes of data.
64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
^C
--- heaven.local ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms


anyidea what i need check for solve this issue ?

thanks

Re: NFS only mount with -o udp option

[Chuck Lever]

On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:

> hello list
> 
> like the subject say after some upgrade of my distro ( i have 2
> machine with the same distro and only in one happne the problem ) i
> can only mount nfs share using the option -o udp , without it i get
> this error
> mount.nfs: mount system call failed

What does

  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v

say?  It should tell you how the mount command is negotiating with the server.

> i am using avahi-dns ( mdns ) for hostname resolve
> 
> command used:
> mount heaven.local:/STORAGE /nfs/STORAGE/
> check dns is work right :
> 
> ping heaven.local
> PING heaven.local (192.168.1.102) 56(84) bytes of data.
> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
> ^C
> --- heaven.local ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
> 
> 
> anyidea what i need check for solve this issue ?
> 
> thanks
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFS only mount with -o udp option

[Edgar Almonte]

i get this without udp option:

mount: no type was given - I'll assume nfs because of the colon
mount.nfs: timeout set for Fri Feb 11 13:27:33 2011
mount.nfs: trying text-based options
'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options
'vers=4,addr=fe80::224:21ff:fe57:368d,clientaddr=::'
mount.nfs: mount(2): Input/output error
mount.nfs: mount system call failed


and with udp option:

ount: no type was given - I'll assume nfs because of the colon
mount.nfs: timeout set for Fri Feb 11 13:28:29 2011
mount.nfs: trying text-based options
'udp,vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'udp,addr=192.168.1.102'
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot UDP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
heaven.local:/STORAGE on /nfs/STORAGE type nfs (rw,udp)


for other distro ( debian laptop ) without the udp option:

mount: no type was given - I'll assume nfs because of the colon
mount.nfs: timeout set for Fri Feb 11 13:31:37 2011
mount.nfs: trying text-based options
'vers=4,addr=192.168.1.102,clientaddr=192.168.1.107'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'addr=192.168.1.102'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
heaven.local:/STORAGE on /srv/nfs type nfs (rw)


and look like is some ipv6 issues


On Thu, Feb 10, 2011 at 11:50 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>
> On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:
>
>> hello list
>>
>> like the subject say after some upgrade of my distro ( i have 2
>> machine with the same distro and only in one happne the problem ) i
>> can only mount nfs share using the option -o udp , without it i get
>> this error
>> mount.nfs: mount system call failed
>
> What does
>
>  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v
>
> say?  It should tell you how the mount command is negotiating with the server.
>
>> i am using avahi-dns ( mdns ) for hostname resolve
>>
>> command used:
>> mount heaven.local:/STORAGE /nfs/STORAGE/
>> check dns is work right :
>>
>> ping heaven.local
>> PING heaven.local (192.168.1.102) 56(84) bytes of data.
>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
>> ^C
>> --- heaven.local ping statistics ---
>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
>>
>>
>> anyidea what i need check for solve this issue ?
>>
>> thanks
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
>
>

Re: NFS only mount with -o udp option

[Chuck Lever]

Which nfs-utils version and kernel release are you using?  What transport protocols are available from your NFS server?  It looks like only UDP.  I recall a bug fix in this area in the past year.

On Feb 11, 2011, at 12:35 PM, Edgar Almonte wrote:

> i get this without udp option:
> 
> mount: no type was given - I'll assume nfs because of the colon
> mount.nfs: timeout set for Fri Feb 11 13:27:33 2011
> mount.nfs: trying text-based options
> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
> mount.nfs: mount(2): No such file or directory
> mount.nfs: trying text-based options
> 'vers=4,addr=fe80::224:21ff:fe57:368d,clientaddr=::'
> mount.nfs: mount(2): Input/output error
> mount.nfs: mount system call failed
> 
> 
> and with udp option:
> 
> ount: no type was given - I'll assume nfs because of the colon
> mount.nfs: timeout set for Fri Feb 11 13:28:29 2011
> mount.nfs: trying text-based options
> 'udp,vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
> mount.nfs: mount(2): No such file or directory
> mount.nfs: trying text-based options 'udp,addr=192.168.1.102'
> mount.nfs: prog 100003, trying vers=3, prot=17
> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot UDP port 2049
> mount.nfs: prog 100005, trying vers=3, prot=17
> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
> heaven.local:/STORAGE on /nfs/STORAGE type nfs (rw,udp)
> 
> 
> for other distro ( debian laptop ) without the udp option:
> 
> mount: no type was given - I'll assume nfs because of the colon
> mount.nfs: timeout set for Fri Feb 11 13:31:37 2011
> mount.nfs: trying text-based options
> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.107'
> mount.nfs: mount(2): No such file or directory
> mount.nfs: trying text-based options 'addr=192.168.1.102'
> mount.nfs: prog 100003, trying vers=3, prot=6
> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
> mount.nfs: prog 100005, trying vers=3, prot=17
> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
> heaven.local:/STORAGE on /srv/nfs type nfs (rw)
> 
> 
> and look like is some ipv6 issues
> 
> 
> On Thu, Feb 10, 2011 at 11:50 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>> 
>> On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:
>> 
>>> hello list
>>> 
>>> like the subject say after some upgrade of my distro ( i have 2
>>> machine with the same distro and only in one happne the problem ) i
>>> can only mount nfs share using the option -o udp , without it i get
>>> this error
>>> mount.nfs: mount system call failed
>> 
>> What does
>> 
>>  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v
>> 
>> say?  It should tell you how the mount command is negotiating with the server.
>> 
>>> i am using avahi-dns ( mdns ) for hostname resolve
>>> 
>>> command used:
>>> mount heaven.local:/STORAGE /nfs/STORAGE/
>>> check dns is work right :
>>> 
>>> ping heaven.local
>>> PING heaven.local (192.168.1.102) 56(84) bytes of data.
>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
>>> ^C
>>> --- heaven.local ping statistics ---
>>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>>> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
>>> 
>>> 
>>> anyidea what i need check for solve this issue ?
>>> 
>>> thanks
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>> 
>> 
>> 
>> 
>> 

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFS only mount with -o udp option

[Edgar Almonte]

[root@circle zen]# pacman -Qs nfs-utils
local/nfs-utils 1.2.2-4 [0.69 MB]
    Support programs for Network File Systems
[root@circle zen]# uname -a
Linux circle 2.6.36-ARCH #1 SMP PREEMPT Mon Jan 24 18:34:55 UTC 2011
i686 Intel(R) Atom(TM) CPU D510 @ 1.66GHz GenuineIntel GNU/Linux


On Fri, Feb 11, 2011 at 1:40 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
> Which nfs-utils version and kernel release are you using?  What transport protocols are available from your NFS server?  It looks like only UDP.  I recall a bug fix in this area in the past year.
>
> On Feb 11, 2011, at 12:35 PM, Edgar Almonte wrote:
>
>> i get this without udp option:
>>
>> mount: no type was given - I'll assume nfs because of the colon
>> mount.nfs: timeout set for Fri Feb 11 13:27:33 2011
>> mount.nfs: trying text-based options
>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>> mount.nfs: mount(2): No such file or directory
>> mount.nfs: trying text-based options
>> 'vers=4,addr=fe80::224:21ff:fe57:368d,clientaddr=::'
>> mount.nfs: mount(2): Input/output error
>> mount.nfs: mount system call failed
>>
>>
>> and with udp option:
>>
>> ount: no type was given - I'll assume nfs because of the colon
>> mount.nfs: timeout set for Fri Feb 11 13:28:29 2011
>> mount.nfs: trying text-based options
>> 'udp,vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>> mount.nfs: mount(2): No such file or directory
>> mount.nfs: trying text-based options 'udp,addr=192.168.1.102'
>> mount.nfs: prog 100003, trying vers=3, prot=17
>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot UDP port 2049
>> mount.nfs: prog 100005, trying vers=3, prot=17
>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>> heaven.local:/STORAGE on /nfs/STORAGE type nfs (rw,udp)
>>
>>
>> for other distro ( debian laptop ) without the udp option:
>>
>> mount: no type was given - I'll assume nfs because of the colon
>> mount.nfs: timeout set for Fri Feb 11 13:31:37 2011
>> mount.nfs: trying text-based options
>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.107'
>> mount.nfs: mount(2): No such file or directory
>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>> mount.nfs: prog 100003, trying vers=3, prot=6
>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>> mount.nfs: prog 100005, trying vers=3, prot=17
>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>> heaven.local:/STORAGE on /srv/nfs type nfs (rw)
>>
>>
>> and look like is some ipv6 issues
>>
>>
>> On Thu, Feb 10, 2011 at 11:50 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>
>>> On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:
>>>
>>>> hello list
>>>>
>>>> like the subject say after some upgrade of my distro ( i have 2
>>>> machine with the same distro and only in one happne the problem ) i
>>>> can only mount nfs share using the option -o udp , without it i get
>>>> this error
>>>> mount.nfs: mount system call failed
>>>
>>> What does
>>>
>>>  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v
>>>
>>> say?  It should tell you how the mount command is negotiating with the server.
>>>
>>>> i am using avahi-dns ( mdns ) for hostname resolve
>>>>
>>>> command used:
>>>> mount heaven.local:/STORAGE /nfs/STORAGE/
>>>> check dns is work right :
>>>>
>>>> ping heaven.local
>>>> PING heaven.local (192.168.1.102) 56(84) bytes of data.
>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
>>>> ^C
>>>> --- heaven.local ping statistics ---
>>>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>>>> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
>>>>
>>>>
>>>> anyidea what i need check for solve this issue ?
>>>>
>>>> thanks
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>> --
>>> Chuck Lever
>>> chuck[dot]lever[at]oracle[dot]com
>>>
>>>
>>>
>>>
>>>
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
>
>

Re: NFS only mount with -o udp option

[Edgar Almonte]

Was a ipv6 issues because i add this to the client with the problem:
options ipv6 disable=1
in /etc/modprobe.d/modprobe.conf
reboot and mount without using udp option work, output:

[root@circle zen]# mount heaven.local:/STORAGE /nfs/STORAGE/ -v
mount: no type was given - I'll assume nfs because of the colon
mount.nfs: timeout set for Fri Feb 11 19:11:53 2011
mount.nfs: trying text-based options
'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'addr=192.168.1.102'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41849

and i think maybe is a bug of nfs-utils that can't handle in the
proper way this because a connection using ipv4 protocol exist ( even
it detect it )

should i need report something like this ? or and wrong ?


On Fri, Feb 11, 2011 at 6:57 PM, Edgar Almonte <samudhio@gmail.com> wrote:
> [root@circle zen]# pacman -Qs nfs-utils
> local/nfs-utils 1.2.2-4 [0.69 MB]
>    Support programs for Network File Systems
> [root@circle zen]# uname -a
> Linux circle 2.6.36-ARCH #1 SMP PREEMPT Mon Jan 24 18:34:55 UTC 2011
> i686 Intel(R) Atom(TM) CPU D510 @ 1.66GHz GenuineIntel GNU/Linux
>
>
> On Fri, Feb 11, 2011 at 1:40 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>> Which nfs-utils version and kernel release are you using?  What transport protocols are available from your NFS server?  It looks like only UDP.  I recall a bug fix in this area in the past year.
>>
>> On Feb 11, 2011, at 12:35 PM, Edgar Almonte wrote:
>>
>>> i get this without udp option:
>>>
>>> mount: no type was given - I'll assume nfs because of the colon
>>> mount.nfs: timeout set for Fri Feb 11 13:27:33 2011
>>> mount.nfs: trying text-based options
>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>> mount.nfs: mount(2): No such file or directory
>>> mount.nfs: trying text-based options
>>> 'vers=4,addr=fe80::224:21ff:fe57:368d,clientaddr=::'
>>> mount.nfs: mount(2): Input/output error
>>> mount.nfs: mount system call failed
>>>
>>>
>>> and with udp option:
>>>
>>> ount: no type was given - I'll assume nfs because of the colon
>>> mount.nfs: timeout set for Fri Feb 11 13:28:29 2011
>>> mount.nfs: trying text-based options
>>> 'udp,vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>> mount.nfs: mount(2): No such file or directory
>>> mount.nfs: trying text-based options 'udp,addr=192.168.1.102'
>>> mount.nfs: prog 100003, trying vers=3, prot=17
>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot UDP port 2049
>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>> heaven.local:/STORAGE on /nfs/STORAGE type nfs (rw,udp)
>>>
>>>
>>> for other distro ( debian laptop ) without the udp option:
>>>
>>> mount: no type was given - I'll assume nfs because of the colon
>>> mount.nfs: timeout set for Fri Feb 11 13:31:37 2011
>>> mount.nfs: trying text-based options
>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.107'
>>> mount.nfs: mount(2): No such file or directory
>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>> heaven.local:/STORAGE on /srv/nfs type nfs (rw)
>>>
>>>
>>> and look like is some ipv6 issues
>>>
>>>
>>> On Thu, Feb 10, 2011 at 11:50 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>
>>>> On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:
>>>>
>>>>> hello list
>>>>>
>>>>> like the subject say after some upgrade of my distro ( i have 2
>>>>> machine with the same distro and only in one happne the problem ) i
>>>>> can only mount nfs share using the option -o udp , without it i get
>>>>> this error
>>>>> mount.nfs: mount system call failed
>>>>
>>>> What does
>>>>
>>>>  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v
>>>>
>>>> say?  It should tell you how the mount command is negotiating with the server.
>>>>
>>>>> i am using avahi-dns ( mdns ) for hostname resolve
>>>>>
>>>>> command used:
>>>>> mount heaven.local:/STORAGE /nfs/STORAGE/
>>>>> check dns is work right :
>>>>>
>>>>> ping heaven.local
>>>>> PING heaven.local (192.168.1.102) 56(84) bytes of data.
>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
>>>>> ^C
>>>>> --- heaven.local ping statistics ---
>>>>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>>>>> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
>>>>>
>>>>>
>>>>> anyidea what i need check for solve this issue ?
>>>>>
>>>>> thanks
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>> --
>>>> Chuck Lever
>>>> chuck[dot]lever[at]oracle[dot]com
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>>
>>
>>
>>
>>
>

Re: NFS only mount with -o udp option

[Chuck Lever]

On Feb 11, 2011, at 6:13 PM, Edgar Almonte wrote:

> Was a ipv6 issues because i add this to the client with the problem:
> options ipv6 disable=1
> in /etc/modprobe.d/modprobe.conf
> reboot and mount without using udp option work, output:
> 
> [root@circle zen]# mount heaven.local:/STORAGE /nfs/STORAGE/ -v
> mount: no type was given - I'll assume nfs because of the colon
> mount.nfs: timeout set for Fri Feb 11 19:11:53 2011
> mount.nfs: trying text-based options
> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
> mount.nfs: mount(2): No such file or directory
> mount.nfs: trying text-based options 'addr=192.168.1.102'
> mount.nfs: prog 100003, trying vers=3, prot=6
> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
> mount.nfs: prog 100005, trying vers=3, prot=17
> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41849
> 
> and i think maybe is a bug of nfs-utils that can't handle in the
> proper way this because a connection using ipv4 protocol exist ( even
> it detect it )
> 
> should i need report something like this ? or and wrong ?

I swear this has been discussed and fixed already, but I can't find a specific fix in the bugzilla database or the git log.  nfs-utils 1.2.2 is at least a year old.  Can you update to the latest version and try again?

Also, please report the NFS server's transport capabilities.  "rpcinfo 192.168.1.102" should work.  You may need the "-p" option.

> On Fri, Feb 11, 2011 at 6:57 PM, Edgar Almonte <samudhio@gmail.com> wrote:
>> [root@circle zen]# pacman -Qs nfs-utils
>> local/nfs-utils 1.2.2-4 [0.69 MB]
>>    Support programs for Network File Systems
>> [root@circle zen]# uname -a
>> Linux circle 2.6.36-ARCH #1 SMP PREEMPT Mon Jan 24 18:34:55 UTC 2011
>> i686 Intel(R) Atom(TM) CPU D510 @ 1.66GHz GenuineIntel GNU/Linux
>> 
>> 
>> On Fri, Feb 11, 2011 at 1:40 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>> Which nfs-utils version and kernel release are you using?  What transport protocols are available from your NFS server?  It looks like only UDP.  I recall a bug fix in this area in the past year.
>>> 
>>> On Feb 11, 2011, at 12:35 PM, Edgar Almonte wrote:
>>> 
>>>> i get this without udp option:
>>>> 
>>>> mount: no type was given - I'll assume nfs because of the colon
>>>> mount.nfs: timeout set for Fri Feb 11 13:27:33 2011
>>>> mount.nfs: trying text-based options
>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>> mount.nfs: mount(2): No such file or directory
>>>> mount.nfs: trying text-based options
>>>> 'vers=4,addr=fe80::224:21ff:fe57:368d,clientaddr=::'
>>>> mount.nfs: mount(2): Input/output error
>>>> mount.nfs: mount system call failed
>>>> 
>>>> 
>>>> and with udp option:
>>>> 
>>>> ount: no type was given - I'll assume nfs because of the colon
>>>> mount.nfs: timeout set for Fri Feb 11 13:28:29 2011
>>>> mount.nfs: trying text-based options
>>>> 'udp,vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>> mount.nfs: mount(2): No such file or directory
>>>> mount.nfs: trying text-based options 'udp,addr=192.168.1.102'
>>>> mount.nfs: prog 100003, trying vers=3, prot=17
>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot UDP port 2049
>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>> heaven.local:/STORAGE on /nfs/STORAGE type nfs (rw,udp)
>>>> 
>>>> 
>>>> for other distro ( debian laptop ) without the udp option:
>>>> 
>>>> mount: no type was given - I'll assume nfs because of the colon
>>>> mount.nfs: timeout set for Fri Feb 11 13:31:37 2011
>>>> mount.nfs: trying text-based options
>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.107'
>>>> mount.nfs: mount(2): No such file or directory
>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>> heaven.local:/STORAGE on /srv/nfs type nfs (rw)
>>>> 
>>>> 
>>>> and look like is some ipv6 issues
>>>> 
>>>> 
>>>> On Thu, Feb 10, 2011 at 11:50 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>> 
>>>>> On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:
>>>>> 
>>>>>> hello list
>>>>>> 
>>>>>> like the subject say after some upgrade of my distro ( i have 2
>>>>>> machine with the same distro and only in one happne the problem ) i
>>>>>> can only mount nfs share using the option -o udp , without it i get
>>>>>> this error
>>>>>> mount.nfs: mount system call failed
>>>>> 
>>>>> What does
>>>>> 
>>>>>  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v
>>>>> 
>>>>> say?  It should tell you how the mount command is negotiating with the server.
>>>>> 
>>>>>> i am using avahi-dns ( mdns ) for hostname resolve
>>>>>> 
>>>>>> command used:
>>>>>> mount heaven.local:/STORAGE /nfs/STORAGE/
>>>>>> check dns is work right :
>>>>>> 
>>>>>> ping heaven.local
>>>>>> PING heaven.local (192.168.1.102) 56(84) bytes of data.
>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
>>>>>> ^C
>>>>>> --- heaven.local ping statistics ---
>>>>>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>>>>>> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
>>>>>> 
>>>>>> 
>>>>>> anyidea what i need check for solve this issue ?
>>>>>> 
>>>>>> thanks
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>> 
>>>>> --
>>>>> Chuck Lever
>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> --
>>> Chuck Lever
>>> chuck[dot]lever[at]oracle[dot]com
>>> 
>>> 
>>> 
>>> 
>>> 
>> 

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFS only mount with -o udp option

[Edgar Almonte]

hmm i will try update to the last version but is the lasted in
official repository of my distro
the rpcinfo -p localhost output ( run at the server )

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
    391002    2   tcp    661  sgi_fam
    100024    1   udp  49216  status
    100024    1   tcp  42903  status
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049  nfs_acl
    100227    3   tcp   2049  nfs_acl
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049  nfs_acl
    100227    3   udp   2049  nfs_acl
    100021    1   udp  36092  nlockmgr
    100021    3   udp  36092  nlockmgr
    100021    4   udp  36092  nlockmgr
    100021    1   tcp  52268  nlockmgr
    100021    3   tcp  52268  nlockmgr
    100021    4   tcp  52268  nlockmgr
    100005    3   udp  41849  mountd
    100005    3   tcp  46012  mountd


On Fri, Feb 11, 2011 at 7:27 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>
> On Feb 11, 2011, at 6:13 PM, Edgar Almonte wrote:
>
>> Was a ipv6 issues because i add this to the client with the problem:
>> options ipv6 disable=1
>> in /etc/modprobe.d/modprobe.conf
>> reboot and mount without using udp option work, output:
>>
>> [root@circle zen]# mount heaven.local:/STORAGE /nfs/STORAGE/ -v
>> mount: no type was given - I'll assume nfs because of the colon
>> mount.nfs: timeout set for Fri Feb 11 19:11:53 2011
>> mount.nfs: trying text-based options
>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>> mount.nfs: mount(2): No such file or directory
>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>> mount.nfs: prog 100003, trying vers=3, prot=6
>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>> mount.nfs: prog 100005, trying vers=3, prot=17
>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41849
>>
>> and i think maybe is a bug of nfs-utils that can't handle in the
>> proper way this because a connection using ipv4 protocol exist ( even
>> it detect it )
>>
>> should i need report something like this ? or and wrong ?
>
> I swear this has been discussed and fixed already, but I can't find a specific fix in the bugzilla database or the git log.  nfs-utils 1.2.2 is at least a year old.  Can you update to the latest version and try again?
>
> Also, please report the NFS server's transport capabilities.  "rpcinfo 192.168.1.102" should work.  You may need the "-p" option.
>
>> On Fri, Feb 11, 2011 at 6:57 PM, Edgar Almonte <samudhio@gmail.com> wrote:
>>> [root@circle zen]# pacman -Qs nfs-utils
>>> local/nfs-utils 1.2.2-4 [0.69 MB]
>>>    Support programs for Network File Systems
>>> [root@circle zen]# uname -a
>>> Linux circle 2.6.36-ARCH #1 SMP PREEMPT Mon Jan 24 18:34:55 UTC 2011
>>> i686 Intel(R) Atom(TM) CPU D510 @ 1.66GHz GenuineIntel GNU/Linux
>>>
>>>
>>> On Fri, Feb 11, 2011 at 1:40 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>> Which nfs-utils version and kernel release are you using?  What transport protocols are available from your NFS server?  It looks like only UDP.  I recall a bug fix in this area in the past year.
>>>>
>>>> On Feb 11, 2011, at 12:35 PM, Edgar Almonte wrote:
>>>>
>>>>> i get this without udp option:
>>>>>
>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>> mount.nfs: timeout set for Fri Feb 11 13:27:33 2011
>>>>> mount.nfs: trying text-based options
>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>> mount.nfs: mount(2): No such file or directory
>>>>> mount.nfs: trying text-based options
>>>>> 'vers=4,addr=fe80::224:21ff:fe57:368d,clientaddr=::'
>>>>> mount.nfs: mount(2): Input/output error
>>>>> mount.nfs: mount system call failed
>>>>>
>>>>>
>>>>> and with udp option:
>>>>>
>>>>> ount: no type was given - I'll assume nfs because of the colon
>>>>> mount.nfs: timeout set for Fri Feb 11 13:28:29 2011
>>>>> mount.nfs: trying text-based options
>>>>> 'udp,vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>> mount.nfs: mount(2): No such file or directory
>>>>> mount.nfs: trying text-based options 'udp,addr=192.168.1.102'
>>>>> mount.nfs: prog 100003, trying vers=3, prot=17
>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot UDP port 2049
>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>> heaven.local:/STORAGE on /nfs/STORAGE type nfs (rw,udp)
>>>>>
>>>>>
>>>>> for other distro ( debian laptop ) without the udp option:
>>>>>
>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>> mount.nfs: timeout set for Fri Feb 11 13:31:37 2011
>>>>> mount.nfs: trying text-based options
>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.107'
>>>>> mount.nfs: mount(2): No such file or directory
>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>> heaven.local:/STORAGE on /srv/nfs type nfs (rw)
>>>>>
>>>>>
>>>>> and look like is some ipv6 issues
>>>>>
>>>>>
>>>>> On Thu, Feb 10, 2011 at 11:50 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>
>>>>>> On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:
>>>>>>
>>>>>>> hello list
>>>>>>>
>>>>>>> like the subject say after some upgrade of my distro ( i have 2
>>>>>>> machine with the same distro and only in one happne the problem ) i
>>>>>>> can only mount nfs share using the option -o udp , without it i get
>>>>>>> this error
>>>>>>> mount.nfs: mount system call failed
>>>>>>
>>>>>> What does
>>>>>>
>>>>>>  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v
>>>>>>
>>>>>> say?  It should tell you how the mount command is negotiating with the server.
>>>>>>
>>>>>>> i am using avahi-dns ( mdns ) for hostname resolve
>>>>>>>
>>>>>>> command used:
>>>>>>> mount heaven.local:/STORAGE /nfs/STORAGE/
>>>>>>> check dns is work right :
>>>>>>>
>>>>>>> ping heaven.local
>>>>>>> PING heaven.local (192.168.1.102) 56(84) bytes of data.
>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
>>>>>>> ^C
>>>>>>> --- heaven.local ping statistics ---
>>>>>>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>>>>>>> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
>>>>>>>
>>>>>>>
>>>>>>> anyidea what i need check for solve this issue ?
>>>>>>>
>>>>>>> thanks
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>> --
>>>>>> Chuck Lever
>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Chuck Lever
>>>> chuck[dot]lever[at]oracle[dot]com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
>
>

Re: NFS only mount with -o udp option

[Chuck Lever]

Hi Edgar-

On Feb 11, 2011, at 6:46 PM, Edgar Almonte wrote:

> hmm i will try update to the last version but is the lasted in
> official repository of my distro

Yes, that could be a problem.  Out of curiosity, can you tell us what version of nfs-utils is running on the working Debian client you have?

> the rpcinfo -p localhost output ( run at the server )
> 
> 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
>    391002    2   tcp    661  sgi_fam
>    100024    1   udp  49216  status
>    100024    1   tcp  42903  status
>    100003    2   tcp   2049  nfs
>    100003    3   tcp   2049  nfs
>    100003    4   tcp   2049  nfs
>    100227    2   tcp   2049  nfs_acl
>    100227    3   tcp   2049  nfs_acl
>    100003    2   udp   2049  nfs
>    100003    3   udp   2049  nfs
>    100003    4   udp   2049  nfs
>    100227    2   udp   2049  nfs_acl
>    100227    3   udp   2049  nfs_acl
>    100021    1   udp  36092  nlockmgr
>    100021    3   udp  36092  nlockmgr
>    100021    4   udp  36092  nlockmgr
>    100021    1   tcp  52268  nlockmgr
>    100021    3   tcp  52268  nlockmgr
>    100021    4   tcp  52268  nlockmgr
>    100005    3   udp  41849  mountd
>    100005    3   tcp  46012  mountd

This looks weird.  NFS is available on TCP and UDP in all three versions, but MNT is available in version 3.  I wonder if this is confusing mount.nfs.  Is there any reason why your server is configured to disable MNT version 1?

> On Fri, Feb 11, 2011 at 7:27 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>> 
>> On Feb 11, 2011, at 6:13 PM, Edgar Almonte wrote:
>> 
>>> Was a ipv6 issues because i add this to the client with the problem:
>>> options ipv6 disable=1
>>> in /etc/modprobe.d/modprobe.conf
>>> reboot and mount without using udp option work, output:
>>> 
>>> [root@circle zen]# mount heaven.local:/STORAGE /nfs/STORAGE/ -v
>>> mount: no type was given - I'll assume nfs because of the colon
>>> mount.nfs: timeout set for Fri Feb 11 19:11:53 2011
>>> mount.nfs: trying text-based options
>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>> mount.nfs: mount(2): No such file or directory
>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41849
>>> 
>>> and i think maybe is a bug of nfs-utils that can't handle in the
>>> proper way this because a connection using ipv4 protocol exist ( even
>>> it detect it )
>>> 
>>> should i need report something like this ? or and wrong ?
>> 
>> I swear this has been discussed and fixed already, but I can't find a specific fix in the bugzilla database or the git log.  nfs-utils 1.2.2 is at least a year old.  Can you update to the latest version and try again?
>> 
>> Also, please report the NFS server's transport capabilities.  "rpcinfo 192.168.1.102" should work.  You may need the "-p" option.
>> 
>>> On Fri, Feb 11, 2011 at 6:57 PM, Edgar Almonte <samudhio@gmail.com> wrote:
>>>> [root@circle zen]# pacman -Qs nfs-utils
>>>> local/nfs-utils 1.2.2-4 [0.69 MB]
>>>>    Support programs for Network File Systems
>>>> [root@circle zen]# uname -a
>>>> Linux circle 2.6.36-ARCH #1 SMP PREEMPT Mon Jan 24 18:34:55 UTC 2011
>>>> i686 Intel(R) Atom(TM) CPU D510 @ 1.66GHz GenuineIntel GNU/Linux
>>>> 
>>>> 
>>>> On Fri, Feb 11, 2011 at 1:40 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>> Which nfs-utils version and kernel release are you using?  What transport protocols are available from your NFS server?  It looks like only UDP.  I recall a bug fix in this area in the past year.
>>>>> 
>>>>> On Feb 11, 2011, at 12:35 PM, Edgar Almonte wrote:
>>>>> 
>>>>>> i get this without udp option:
>>>>>> 
>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>> mount.nfs: timeout set for Fri Feb 11 13:27:33 2011
>>>>>> mount.nfs: trying text-based options
>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>> mount.nfs: trying text-based options
>>>>>> 'vers=4,addr=fe80::224:21ff:fe57:368d,clientaddr=::'
>>>>>> mount.nfs: mount(2): Input/output error
>>>>>> mount.nfs: mount system call failed
>>>>>> 
>>>>>> 
>>>>>> and with udp option:
>>>>>> 
>>>>>> ount: no type was given - I'll assume nfs because of the colon
>>>>>> mount.nfs: timeout set for Fri Feb 11 13:28:29 2011
>>>>>> mount.nfs: trying text-based options
>>>>>> 'udp,vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>> mount.nfs: trying text-based options 'udp,addr=192.168.1.102'
>>>>>> mount.nfs: prog 100003, trying vers=3, prot=17
>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot UDP port 2049
>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>> heaven.local:/STORAGE on /nfs/STORAGE type nfs (rw,udp)
>>>>>> 
>>>>>> 
>>>>>> for other distro ( debian laptop ) without the udp option:
>>>>>> 
>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>> mount.nfs: timeout set for Fri Feb 11 13:31:37 2011
>>>>>> mount.nfs: trying text-based options
>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.107'
>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>> heaven.local:/STORAGE on /srv/nfs type nfs (rw)
>>>>>> 
>>>>>> 
>>>>>> and look like is some ipv6 issues
>>>>>> 
>>>>>> 
>>>>>> On Thu, Feb 10, 2011 at 11:50 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>> 
>>>>>>> On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:
>>>>>>> 
>>>>>>>> hello list
>>>>>>>> 
>>>>>>>> like the subject say after some upgrade of my distro ( i have 2
>>>>>>>> machine with the same distro and only in one happne the problem ) i
>>>>>>>> can only mount nfs share using the option -o udp , without it i get
>>>>>>>> this error
>>>>>>>> mount.nfs: mount system call failed
>>>>>>> 
>>>>>>> What does
>>>>>>> 
>>>>>>>  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v
>>>>>>> 
>>>>>>> say?  It should tell you how the mount command is negotiating with the server.
>>>>>>> 
>>>>>>>> i am using avahi-dns ( mdns ) for hostname resolve
>>>>>>>> 
>>>>>>>> command used:
>>>>>>>> mount heaven.local:/STORAGE /nfs/STORAGE/
>>>>>>>> check dns is work right :
>>>>>>>> 
>>>>>>>> ping heaven.local
>>>>>>>> PING heaven.local (192.168.1.102) 56(84) bytes of data.
>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
>>>>>>>> ^C
>>>>>>>> --- heaven.local ping statistics ---
>>>>>>>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>>>>>>>> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
>>>>>>>> 
>>>>>>>> 
>>>>>>>> anyidea what i need check for solve this issue ?
>>>>>>>> 
>>>>>>>> thanks
>>>>>>>> --
>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>> 
>>>>>>> --
>>>>>>> Chuck Lever
>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> --
>>>>> Chuck Lever
>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>> 
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>> 
>> 
>> 
>> 
>> 

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFS only mount with -o udp option

[Edgar Almonte]

in debian dont exist a package called nfs-utils , i get nfs-common and
say the same version of the nfs-utils of archlinux
not sure about MNT version config , i dont remember intentionally
changing this , where i can check it ?

pd: sorry for the double email i forget press reply all

On Mon, Feb 14, 2011 at 11:56 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
> Hi Edgar-
>
> On Feb 11, 2011, at 6:46 PM, Edgar Almonte wrote:
>
>> hmm i will try update to the last version but is the lasted in
>> official repository of my distro
>
> Yes, that could be a problem.  Out of curiosity, can you tell us what version of nfs-utils is running on the working Debian client you have?
>
>> the rpcinfo -p localhost output ( run at the server )
>>
>> 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
>>    391002    2   tcp    661  sgi_fam
>>    100024    1   udp  49216  status
>>    100024    1   tcp  42903  status
>>    100003    2   tcp   2049  nfs
>>    100003    3   tcp   2049  nfs
>>    100003    4   tcp   2049  nfs
>>    100227    2   tcp   2049  nfs_acl
>>    100227    3   tcp   2049  nfs_acl
>>    100003    2   udp   2049  nfs
>>    100003    3   udp   2049  nfs
>>    100003    4   udp   2049  nfs
>>    100227    2   udp   2049  nfs_acl
>>    100227    3   udp   2049  nfs_acl
>>    100021    1   udp  36092  nlockmgr
>>    100021    3   udp  36092  nlockmgr
>>    100021    4   udp  36092  nlockmgr
>>    100021    1   tcp  52268  nlockmgr
>>    100021    3   tcp  52268  nlockmgr
>>    100021    4   tcp  52268  nlockmgr
>>    100005    3   udp  41849  mountd
>>    100005    3   tcp  46012  mountd
>
> This looks weird.  NFS is available on TCP and UDP in all three versions, but MNT is available in version 3.  I wonder if this is confusing mount.nfs.  Is there any reason why your server is configured to disable MNT version 1?
>
>> On Fri, Feb 11, 2011 at 7:27 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>
>>> On Feb 11, 2011, at 6:13 PM, Edgar Almonte wrote:
>>>
>>>> Was a ipv6 issues because i add this to the client with the problem:
>>>> options ipv6 disable=1
>>>> in /etc/modprobe.d/modprobe.conf
>>>> reboot and mount without using udp option work, output:
>>>>
>>>> [root@circle zen]# mount heaven.local:/STORAGE /nfs/STORAGE/ -v
>>>> mount: no type was given - I'll assume nfs because of the colon
>>>> mount.nfs: timeout set for Fri Feb 11 19:11:53 2011
>>>> mount.nfs: trying text-based options
>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>> mount.nfs: mount(2): No such file or directory
>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41849
>>>>
>>>> and i think maybe is a bug of nfs-utils that can't handle in the
>>>> proper way this because a connection using ipv4 protocol exist ( even
>>>> it detect it )
>>>>
>>>> should i need report something like this ? or and wrong ?
>>>
>>> I swear this has been discussed and fixed already, but I can't find a specific fix in the bugzilla database or the git log.  nfs-utils 1.2.2 is at least a year old.  Can you update to the latest version and try again?
>>>
>>> Also, please report the NFS server's transport capabilities.  "rpcinfo 192.168.1.102" should work.  You may need the "-p" option.
>>>
>>>> On Fri, Feb 11, 2011 at 6:57 PM, Edgar Almonte <samudhio@gmail.com> wrote:
>>>>> [root@circle zen]# pacman -Qs nfs-utils
>>>>> local/nfs-utils 1.2.2-4 [0.69 MB]
>>>>>    Support programs for Network File Systems
>>>>> [root@circle zen]# uname -a
>>>>> Linux circle 2.6.36-ARCH #1 SMP PREEMPT Mon Jan 24 18:34:55 UTC 2011
>>>>> i686 Intel(R) Atom(TM) CPU D510 @ 1.66GHz GenuineIntel GNU/Linux
>>>>>
>>>>>
>>>>> On Fri, Feb 11, 2011 at 1:40 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>> Which nfs-utils version and kernel release are you using?  What transport protocols are available from your NFS server?  It looks like only UDP.  I recall a bug fix in this area in the past year.
>>>>>>
>>>>>> On Feb 11, 2011, at 12:35 PM, Edgar Almonte wrote:
>>>>>>
>>>>>>> i get this without udp option:
>>>>>>>
>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:27:33 2011
>>>>>>> mount.nfs: trying text-based options
>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>> mount.nfs: trying text-based options
>>>>>>> 'vers=4,addr=fe80::224:21ff:fe57:368d,clientaddr=::'
>>>>>>> mount.nfs: mount(2): Input/output error
>>>>>>> mount.nfs: mount system call failed
>>>>>>>
>>>>>>>
>>>>>>> and with udp option:
>>>>>>>
>>>>>>> ount: no type was given - I'll assume nfs because of the colon
>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:28:29 2011
>>>>>>> mount.nfs: trying text-based options
>>>>>>> 'udp,vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>> mount.nfs: trying text-based options 'udp,addr=192.168.1.102'
>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=17
>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot UDP port 2049
>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>>> heaven.local:/STORAGE on /nfs/STORAGE type nfs (rw,udp)
>>>>>>>
>>>>>>>
>>>>>>> for other distro ( debian laptop ) without the udp option:
>>>>>>>
>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:31:37 2011
>>>>>>> mount.nfs: trying text-based options
>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.107'
>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>>> heaven.local:/STORAGE on /srv/nfs type nfs (rw)
>>>>>>>
>>>>>>>
>>>>>>> and look like is some ipv6 issues
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 10, 2011 at 11:50 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>>
>>>>>>>> On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:
>>>>>>>>
>>>>>>>>> hello list
>>>>>>>>>
>>>>>>>>> like the subject say after some upgrade of my distro ( i have 2
>>>>>>>>> machine with the same distro and only in one happne the problem ) i
>>>>>>>>> can only mount nfs share using the option -o udp , without it i get
>>>>>>>>> this error
>>>>>>>>> mount.nfs: mount system call failed
>>>>>>>>
>>>>>>>> What does
>>>>>>>>
>>>>>>>>  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v
>>>>>>>>
>>>>>>>> say?  It should tell you how the mount command is negotiating with the server.
>>>>>>>>
>>>>>>>>> i am using avahi-dns ( mdns ) for hostname resolve
>>>>>>>>>
>>>>>>>>> command used:
>>>>>>>>> mount heaven.local:/STORAGE /nfs/STORAGE/
>>>>>>>>> check dns is work right :
>>>>>>>>>
>>>>>>>>> ping heaven.local
>>>>>>>>> PING heaven.local (192.168.1.102) 56(84) bytes of data.
>>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
>>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
>>>>>>>>> ^C
>>>>>>>>> --- heaven.local ping statistics ---
>>>>>>>>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>>>>>>>>> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> anyidea what i need check for solve this issue ?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> --
>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>>
>>>>>>>> --
>>>>>>>> Chuck Lever
>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Chuck Lever
>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>> --
>>> Chuck Lever
>>> chuck[dot]lever[at]oracle[dot]com
>>>
>>>
>>>
>>>
>>>
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
>
>

Re: NFS only mount with -o udp option

[Trond Myklebust]

On Mon, 2011-02-14 at 22:09 -0400, Edgar Almonte wrote: 
> in debian dont exist a package called nfs-utils , i get nfs-common and
> say the same version of the nfs-utils of archlinux
> not sure about MNT version config , i dont remember intentionally
> changing this , where i can check it ?
> 
> pd: sorry for the double email i forget press reply all
> 
> On Mon, Feb 14, 2011 at 11:56 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
> > Hi Edgar-
> >
> > On Feb 11, 2011, at 6:46 PM, Edgar Almonte wrote:
> >
> >> hmm i will try update to the last version but is the lasted in
> >> official repository of my distro
> >
> > Yes, that could be a problem.  Out of curiosity, can you tell us what version of nfs-utils is running on the working Debian client you have?
> >
> >> the rpcinfo -p localhost output ( run at the server )
> >>
> >> 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
> >>    391002    2   tcp    661  sgi_fam
> >>    100024    1   udp  49216  status
> >>    100024    1   tcp  42903  status
> >>    100003    2   tcp   2049  nfs
> >>    100003    3   tcp   2049  nfs
> >>    100003    4   tcp   2049  nfs
> >>    100227    2   tcp   2049  nfs_acl
> >>    100227    3   tcp   2049  nfs_acl
> >>    100003    2   udp   2049  nfs
> >>    100003    3   udp   2049  nfs
> >>    100003    4   udp   2049  nfs
> >>    100227    2   udp   2049  nfs_acl
> >>    100227    3   udp   2049  nfs_acl
> >>    100021    1   udp  36092  nlockmgr
> >>    100021    3   udp  36092  nlockmgr
> >>    100021    4   udp  36092  nlockmgr
> >>    100021    1   tcp  52268  nlockmgr
> >>    100021    3   tcp  52268  nlockmgr
> >>    100021    4   tcp  52268  nlockmgr
> >>    100005    3   udp  41849  mountd
> >>    100005    3   tcp  46012  mountd

UDP and TCP appear to be running on different ports.

     1. Does running 'sudo netstat -anp' on the server show any other
        processes running on TCP port 41849 or UDP port 46012? 
     2. Does running 'sudo iptables -n -L' on the server show anything
        rejecting TCP connections on port 46012?

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: NFS only mount with -o udp option

[Edgar Almonte]

1- no

2:
[root@heaven Desktop]# iptables -n -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

On Mon, Feb 14, 2011 at 10:22 PM, Trond Myklebust
<Trond.Myklebust@netapp.com> wrote:
> On Mon, 2011-02-14 at 22:09 -0400, Edgar Almonte wrote:
>> in debian dont exist a package called nfs-utils , i get nfs-common and
>> say the same version of the nfs-utils of archlinux
>> not sure about MNT version config , i dont remember intentionally
>> changing this , where i can check it ?
>>
>> pd: sorry for the double email i forget press reply all
>>
>> On Mon, Feb 14, 2011 at 11:56 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>> > Hi Edgar-
>> >
>> > On Feb 11, 2011, at 6:46 PM, Edgar Almonte wrote:
>> >
>> >> hmm i will try update to the last version but is the lasted in
>> >> official repository of my distro
>> >
>> > Yes, that could be a problem.  Out of curiosity, can you tell us what version of nfs-utils is running on the working Debian client you have?
>> >
>> >> the rpcinfo -p localhost output ( run at the server )
>> >>
>> >> 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
>> >>    391002    2   tcp    661  sgi_fam
>> >>    100024    1   udp  49216  status
>> >>    100024    1   tcp  42903  status
>> >>    100003    2   tcp   2049  nfs
>> >>    100003    3   tcp   2049  nfs
>> >>    100003    4   tcp   2049  nfs
>> >>    100227    2   tcp   2049  nfs_acl
>> >>    100227    3   tcp   2049  nfs_acl
>> >>    100003    2   udp   2049  nfs
>> >>    100003    3   udp   2049  nfs
>> >>    100003    4   udp   2049  nfs
>> >>    100227    2   udp   2049  nfs_acl
>> >>    100227    3   udp   2049  nfs_acl
>> >>    100021    1   udp  36092  nlockmgr
>> >>    100021    3   udp  36092  nlockmgr
>> >>    100021    4   udp  36092  nlockmgr
>> >>    100021    1   tcp  52268  nlockmgr
>> >>    100021    3   tcp  52268  nlockmgr
>> >>    100021    4   tcp  52268  nlockmgr
>> >>    100005    3   udp  41849  mountd
>> >>    100005    3   tcp  46012  mountd
>
> UDP and TCP appear to be running on different ports.
>
>     1. Does running 'sudo netstat -anp' on the server show any other
>        processes running on TCP port 41849 or UDP port 46012?
>     2. Does running 'sudo iptables -n -L' on the server show anything
>        rejecting TCP connections on port 46012?
>
> Cheers
>  Trond
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
>
>

Re: NFS only mount with -o udp option

[Chuck Lever]

On Feb 14, 2011, at 9:09 PM, Edgar Almonte wrote:

> in debian dont exist a package called nfs-utils , i get nfs-common and
> say the same version of the nfs-utils of archlinux

The same nfs-utils version should behave the same way no matter what (modulo bugs, of course).  It may be that the two packages were built with different configure options.  Not sure how we could find out how these were built.

Basically, I'm trying to figure out how to reproduce the problem here.

> not sure about MNT version config , i dont remember intentionally
> changing this , where i can check it ?

On the server, look at the command line options for rpc.mountd.  I'm not familiar with Ubuntu or Debian's start-up scripts, so I can't be more specific than that.

Note that this is an independent issue from the mount problem, but it's incorrect and contributing to mount's misbehavior.

> pd: sorry for the double email i forget press reply all
> 
> On Mon, Feb 14, 2011 at 11:56 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>> Hi Edgar-
>> 
>> On Feb 11, 2011, at 6:46 PM, Edgar Almonte wrote:
>> 
>>> hmm i will try update to the last version but is the lasted in
>>> official repository of my distro
>> 
>> Yes, that could be a problem.  Out of curiosity, can you tell us what version of nfs-utils is running on the working Debian client you have?
>> 
>>> the rpcinfo -p localhost output ( run at the server )
>>> 
>>> 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
>>>    391002    2   tcp    661  sgi_fam
>>>    100024    1   udp  49216  status
>>>    100024    1   tcp  42903  status
>>>    100003    2   tcp   2049  nfs
>>>    100003    3   tcp   2049  nfs
>>>    100003    4   tcp   2049  nfs
>>>    100227    2   tcp   2049  nfs_acl
>>>    100227    3   tcp   2049  nfs_acl
>>>    100003    2   udp   2049  nfs
>>>    100003    3   udp   2049  nfs
>>>    100003    4   udp   2049  nfs
>>>    100227    2   udp   2049  nfs_acl
>>>    100227    3   udp   2049  nfs_acl
>>>    100021    1   udp  36092  nlockmgr
>>>    100021    3   udp  36092  nlockmgr
>>>    100021    4   udp  36092  nlockmgr
>>>    100021    1   tcp  52268  nlockmgr
>>>    100021    3   tcp  52268  nlockmgr
>>>    100021    4   tcp  52268  nlockmgr
>>>    100005    3   udp  41849  mountd
>>>    100005    3   tcp  46012  mountd
>> 
>> This looks weird.  NFS is available on TCP and UDP in all three versions, but MNT is available in version 3.  I wonder if this is confusing mount.nfs.  Is there any reason why your server is configured to disable MNT version 1?
>> 
>>> On Fri, Feb 11, 2011 at 7:27 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>> 
>>>> On Feb 11, 2011, at 6:13 PM, Edgar Almonte wrote:
>>>> 
>>>>> Was a ipv6 issues because i add this to the client with the problem:
>>>>> options ipv6 disable=1
>>>>> in /etc/modprobe.d/modprobe.conf
>>>>> reboot and mount without using udp option work, output:
>>>>> 
>>>>> [root@circle zen]# mount heaven.local:/STORAGE /nfs/STORAGE/ -v
>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>> mount.nfs: timeout set for Fri Feb 11 19:11:53 2011
>>>>> mount.nfs: trying text-based options
>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>> mount.nfs: mount(2): No such file or directory
>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41849
>>>>> 
>>>>> and i think maybe is a bug of nfs-utils that can't handle in the
>>>>> proper way this because a connection using ipv4 protocol exist ( even
>>>>> it detect it )
>>>>> 
>>>>> should i need report something like this ? or and wrong ?
>>>> 
>>>> I swear this has been discussed and fixed already, but I can't find a specific fix in the bugzilla database or the git log.  nfs-utils 1.2.2 is at least a year old.  Can you update to the latest version and try again?
>>>> 
>>>> Also, please report the NFS server's transport capabilities.  "rpcinfo 192.168.1.102" should work.  You may need the "-p" option.
>>>> 
>>>>> On Fri, Feb 11, 2011 at 6:57 PM, Edgar Almonte <samudhio@gmail.com> wrote:
>>>>>> [root@circle zen]# pacman -Qs nfs-utils
>>>>>> local/nfs-utils 1.2.2-4 [0.69 MB]
>>>>>>    Support programs for Network File Systems
>>>>>> [root@circle zen]# uname -a
>>>>>> Linux circle 2.6.36-ARCH #1 SMP PREEMPT Mon Jan 24 18:34:55 UTC 2011
>>>>>> i686 Intel(R) Atom(TM) CPU D510 @ 1.66GHz GenuineIntel GNU/Linux
>>>>>> 
>>>>>> 
>>>>>> On Fri, Feb 11, 2011 at 1:40 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>> Which nfs-utils version and kernel release are you using?  What transport protocols are available from your NFS server?  It looks like only UDP.  I recall a bug fix in this area in the past year.
>>>>>>> 
>>>>>>> On Feb 11, 2011, at 12:35 PM, Edgar Almonte wrote:
>>>>>>> 
>>>>>>>> i get this without udp option:
>>>>>>>> 
>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:27:33 2011
>>>>>>>> mount.nfs: trying text-based options
>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>> mount.nfs: trying text-based options
>>>>>>>> 'vers=4,addr=fe80::224:21ff:fe57:368d,clientaddr=::'
>>>>>>>> mount.nfs: mount(2): Input/output error
>>>>>>>> mount.nfs: mount system call failed
>>>>>>>> 
>>>>>>>> 
>>>>>>>> and with udp option:
>>>>>>>> 
>>>>>>>> ount: no type was given - I'll assume nfs because of the colon
>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:28:29 2011
>>>>>>>> mount.nfs: trying text-based options
>>>>>>>> 'udp,vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>> mount.nfs: trying text-based options 'udp,addr=192.168.1.102'
>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=17
>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot UDP port 2049
>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>>>> heaven.local:/STORAGE on /nfs/STORAGE type nfs (rw,udp)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> for other distro ( debian laptop ) without the udp option:
>>>>>>>> 
>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:31:37 2011
>>>>>>>> mount.nfs: trying text-based options
>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.107'
>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>>>> heaven.local:/STORAGE on /srv/nfs type nfs (rw)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> and look like is some ipv6 issues
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Thu, Feb 10, 2011 at 11:50 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>> On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:
>>>>>>>>> 
>>>>>>>>>> hello list
>>>>>>>>>> 
>>>>>>>>>> like the subject say after some upgrade of my distro ( i have 2
>>>>>>>>>> machine with the same distro and only in one happne the problem ) i
>>>>>>>>>> can only mount nfs share using the option -o udp , without it i get
>>>>>>>>>> this error
>>>>>>>>>> mount.nfs: mount system call failed
>>>>>>>>> 
>>>>>>>>> What does
>>>>>>>>> 
>>>>>>>>>  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v
>>>>>>>>> 
>>>>>>>>> say?  It should tell you how the mount command is negotiating with the server.
>>>>>>>>> 
>>>>>>>>>> i am using avahi-dns ( mdns ) for hostname resolve
>>>>>>>>>> 
>>>>>>>>>> command used:
>>>>>>>>>> mount heaven.local:/STORAGE /nfs/STORAGE/
>>>>>>>>>> check dns is work right :
>>>>>>>>>> 
>>>>>>>>>> ping heaven.local
>>>>>>>>>> PING heaven.local (192.168.1.102) 56(84) bytes of data.
>>>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
>>>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
>>>>>>>>>> ^C
>>>>>>>>>> --- heaven.local ping statistics ---
>>>>>>>>>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>>>>>>>>>> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> anyidea what i need check for solve this issue ?
>>>>>>>>>> 
>>>>>>>>>> thanks
>>>>>>>>>> --
>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Chuck Lever
>>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Chuck Lever
>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>>>> --
>>>> Chuck Lever
>>>> chuck[dot]lever[at]oracle[dot]com
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>> 
>> 
>> 
>> 
>> 

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFS only mount with -o udp option

[Jim Rees]

Chuck Lever wrote:

  On the server, look at the command line options for rpc.mountd.  I'm not
  familiar with Ubuntu or Debian's start-up scripts, so I can't be more
  specific than that.

This should be in /etc/default/nfs-kernel-server on Ubuntu.  Debian may be
the same.

Re: NFS only mount with -o udp option

[Edgar Almonte]

i confirm the ipv6 things i tell you , i comment the line

options ipv6 disable=1

in /etc/modprobe.d/modprobe.conf

the same error in mount without using -o udp

but the thing is i share folder in that client and mount it in the
server normal without the upd option and work fine ( the server have
the same distro that the client with the problem "archlinux" ) and in
the server i dont have the option in the /etc/modprobe.d/modprobe.conf

[root@heaven Desktop]# mount  circle.local:/torrent_files
/media/torrent_files/ -v
mount: no type was given - I'll assume nfs because of the colon
mount.nfs: timeout set for Tue Feb 15 18:27:24 2011
mount.nfs: trying text-based options
'vers=4,addr=192.168.1.103,clientaddr=192.168.1.102'
circle.local:/torrent_files on /media/torrent_files type nfs (rw)

i use nfs4 for this share in the server and using nfs3 for the share

another thing is that the server have the version 64bit of the same
package in the client but i686 plataform

rpc.mountd option:
root@heaven Desktop]# ps aux | grep rpc.mountd
root      4351  0.0  0.0  54512   660 ?        Ss   18:11   0:00
/usr/sbin/rpc.mountd --no-nfs-version 1 --no-nfs-version 2


On Tue, Feb 15, 2011 at 11:27 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>
> On Feb 14, 2011, at 9:09 PM, Edgar Almonte wrote:
>
>> in debian dont exist a package called nfs-utils , i get nfs-common and
>> say the same version of the nfs-utils of archlinux
>
> The same nfs-utils version should behave the same way no matter what (modulo bugs, of course).  It may be that the two packages were built with different configure options.  Not sure how we could find out how these were built.
>
> Basically, I'm trying to figure out how to reproduce the problem here.
>
>> not sure about MNT version config , i dont remember intentionally
>> changing this , where i can check it ?
>
> On the server, look at the command line options for rpc.mountd.  I'm not familiar with Ubuntu or Debian's start-up scripts, so I can't be more specific than that.
>
> Note that this is an independent issue from the mount problem, but it's incorrect and contributing to mount's misbehavior.
>
>> pd: sorry for the double email i forget press reply all
>>
>> On Mon, Feb 14, 2011 at 11:56 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>> Hi Edgar-
>>>
>>> On Feb 11, 2011, at 6:46 PM, Edgar Almonte wrote:
>>>
>>>> hmm i will try update to the last version but is the lasted in
>>>> official repository of my distro
>>>
>>> Yes, that could be a problem.  Out of curiosity, can you tell us what version of nfs-utils is running on the working Debian client you have?
>>>
>>>> the rpcinfo -p localhost output ( run at the server )
>>>>
>>>> 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
>>>>    391002    2   tcp    661  sgi_fam
>>>>    100024    1   udp  49216  status
>>>>    100024    1   tcp  42903  status
>>>>    100003    2   tcp   2049  nfs
>>>>    100003    3   tcp   2049  nfs
>>>>    100003    4   tcp   2049  nfs
>>>>    100227    2   tcp   2049  nfs_acl
>>>>    100227    3   tcp   2049  nfs_acl
>>>>    100003    2   udp   2049  nfs
>>>>    100003    3   udp   2049  nfs
>>>>    100003    4   udp   2049  nfs
>>>>    100227    2   udp   2049  nfs_acl
>>>>    100227    3   udp   2049  nfs_acl
>>>>    100021    1   udp  36092  nlockmgr
>>>>    100021    3   udp  36092  nlockmgr
>>>>    100021    4   udp  36092  nlockmgr
>>>>    100021    1   tcp  52268  nlockmgr
>>>>    100021    3   tcp  52268  nlockmgr
>>>>    100021    4   tcp  52268  nlockmgr
>>>>    100005    3   udp  41849  mountd
>>>>    100005    3   tcp  46012  mountd
>>>
>>> This looks weird.  NFS is available on TCP and UDP in all three versions, but MNT is available in version 3.  I wonder if this is confusing mount.nfs.  Is there any reason why your server is configured to disable MNT version 1?
>>>
>>>> On Fri, Feb 11, 2011 at 7:27 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>
>>>>> On Feb 11, 2011, at 6:13 PM, Edgar Almonte wrote:
>>>>>
>>>>>> Was a ipv6 issues because i add this to the client with the problem:
>>>>>> options ipv6 disable=1
>>>>>> in /etc/modprobe.d/modprobe.conf
>>>>>> reboot and mount without using udp option work, output:
>>>>>>
>>>>>> [root@circle zen]# mount heaven.local:/STORAGE /nfs/STORAGE/ -v
>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>> mount.nfs: timeout set for Fri Feb 11 19:11:53 2011
>>>>>> mount.nfs: trying text-based options
>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41849
>>>>>>
>>>>>> and i think maybe is a bug of nfs-utils that can't handle in the
>>>>>> proper way this because a connection using ipv4 protocol exist ( even
>>>>>> it detect it )
>>>>>>
>>>>>> should i need report something like this ? or and wrong ?
>>>>>
>>>>> I swear this has been discussed and fixed already, but I can't find a specific fix in the bugzilla database or the git log.  nfs-utils 1.2.2 is at least a year old.  Can you update to the latest version and try again?
>>>>>
>>>>> Also, please report the NFS server's transport capabilities.  "rpcinfo 192.168.1.102" should work.  You may need the "-p" option.
>>>>>
>>>>>> On Fri, Feb 11, 2011 at 6:57 PM, Edgar Almonte <samudhio@gmail.com> wrote:
>>>>>>> [root@circle zen]# pacman -Qs nfs-utils
>>>>>>> local/nfs-utils 1.2.2-4 [0.69 MB]
>>>>>>>    Support programs for Network File Systems
>>>>>>> [root@circle zen]# uname -a
>>>>>>> Linux circle 2.6.36-ARCH #1 SMP PREEMPT Mon Jan 24 18:34:55 UTC 2011
>>>>>>> i686 Intel(R) Atom(TM) CPU D510 @ 1.66GHz GenuineIntel GNU/Linux
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Feb 11, 2011 at 1:40 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>> Which nfs-utils version and kernel release are you using?  What transport protocols are available from your NFS server?  It looks like only UDP.  I recall a bug fix in this area in the past year.
>>>>>>>>
>>>>>>>> On Feb 11, 2011, at 12:35 PM, Edgar Almonte wrote:
>>>>>>>>
>>>>>>>>> i get this without udp option:
>>>>>>>>>
>>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:27:33 2011
>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>> 'vers=4,addr=fe80::224:21ff:fe57:368d,clientaddr=::'
>>>>>>>>> mount.nfs: mount(2): Input/output error
>>>>>>>>> mount.nfs: mount system call failed
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> and with udp option:
>>>>>>>>>
>>>>>>>>> ount: no type was given - I'll assume nfs because of the colon
>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:28:29 2011
>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>> 'udp,vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>> mount.nfs: trying text-based options 'udp,addr=192.168.1.102'
>>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=17
>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot UDP port 2049
>>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>>>>> heaven.local:/STORAGE on /nfs/STORAGE type nfs (rw,udp)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> for other distro ( debian laptop ) without the udp option:
>>>>>>>>>
>>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:31:37 2011
>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.107'
>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>>>>> heaven.local:/STORAGE on /srv/nfs type nfs (rw)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> and look like is some ipv6 issues
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Feb 10, 2011 at 11:50 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:
>>>>>>>>>>
>>>>>>>>>>> hello list
>>>>>>>>>>>
>>>>>>>>>>> like the subject say after some upgrade of my distro ( i have 2
>>>>>>>>>>> machine with the same distro and only in one happne the problem ) i
>>>>>>>>>>> can only mount nfs share using the option -o udp , without it i get
>>>>>>>>>>> this error
>>>>>>>>>>> mount.nfs: mount system call failed
>>>>>>>>>>
>>>>>>>>>> What does
>>>>>>>>>>
>>>>>>>>>>  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v
>>>>>>>>>>
>>>>>>>>>> say?  It should tell you how the mount command is negotiating with the server.
>>>>>>>>>>
>>>>>>>>>>> i am using avahi-dns ( mdns ) for hostname resolve
>>>>>>>>>>>
>>>>>>>>>>> command used:
>>>>>>>>>>> mount heaven.local:/STORAGE /nfs/STORAGE/
>>>>>>>>>>> check dns is work right :
>>>>>>>>>>>
>>>>>>>>>>> ping heaven.local
>>>>>>>>>>> PING heaven.local (192.168.1.102) 56(84) bytes of data.
>>>>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
>>>>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
>>>>>>>>>>> ^C
>>>>>>>>>>> --- heaven.local ping statistics ---
>>>>>>>>>>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>>>>>>>>>>> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> anyidea what i need check for solve this issue ?
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> --
>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Chuck Lever
>>>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Chuck Lever
>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>> --
>>>>> Chuck Lever
>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>> --
>>> Chuck Lever
>>> chuck[dot]lever[at]oracle[dot]com
>>>
>>>
>>>
>>>
>>>
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
>
>

Re: NFS only mount with -o udp option

[Chuck Lever]

On Feb 15, 2011, at 5:31 PM, Edgar Almonte wrote:

> i confirm the ipv6 things i tell you , i comment the line
> 
> options ipv6 disable=1
> 
> in /etc/modprobe.d/modprobe.conf
> 
> the same error in mount without using -o udp
> 
> but the thing is i share folder in that client and mount it in the
> server normal without the upd option and work fine ( the server have
> the same distro that the client with the problem "archlinux" ) and in
> the server i dont have the option in the /etc/modprobe.d/modprobe.conf
> 
> [root@heaven Desktop]# mount  circle.local:/torrent_files
> /media/torrent_files/ -v
> mount: no type was given - I'll assume nfs because of the colon
> mount.nfs: timeout set for Tue Feb 15 18:27:24 2011
> mount.nfs: trying text-based options
> 'vers=4,addr=192.168.1.103,clientaddr=192.168.1.102'
> circle.local:/torrent_files on /media/torrent_files type nfs (rw)
> 
> i use nfs4 for this share in the server and using nfs3 for the share
> 
> another thing is that the server have the version 64bit of the same
> package in the client but i686 plataform

Let me confirm what you said:

  1.  The server is running the latest ARCH (x86-64).  Mounting the share via loopback on the server gets you an NFSv4 mount
  2.  The client is running the latest ARCH (x86-32).  Mounting the share from the client gets you an NFSv3, not an NFSv4, mount, and you have to specify UDP to make the negotiation complete successfully
  3.  Preventing ipv6.ko from loading on the client allows the mount to proceed without specifying extra options

I tried to reproduce this this morning from an x86-64 client using the latest upstream nfs-utils source, and was able to get an NFSv4 mount immediately.  In other words, I reproduced the behavior in 1, but was not able to reproduce the behavior in 2.  I can try again with an x86-32 client soon, but I'm traveling tomorrow.

Specifying "udp" forces the mount request to use IPv4.  If my theory is correct, specifying "tcp" also works, and gets you an NFSv4 mount.  I wasn't aware that ARCH had libtirpc and an IPv6-enabled nfs-utils build.  Does the failing client have a copy of /etc/netconfig, and can you send it?

> rpc.mountd option:
> root@heaven Desktop]# ps aux | grep rpc.mountd
> root      4351  0.0  0.0  54512   660 ?        Ss   18:11   0:00
> /usr/sbin/rpc.mountd --no-nfs-version 1 --no-nfs-version 2

That's consistent with the "rpcinfo" output you provided, but it doesn't explain why nfsd is still providing NFSv2.  Probably not a big deal, as the mount command on your client is failing before it even tries vers=2.

> On Tue, Feb 15, 2011 at 11:27 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>> 
>> On Feb 14, 2011, at 9:09 PM, Edgar Almonte wrote:
>> 
>>> in debian dont exist a package called nfs-utils , i get nfs-common and
>>> say the same version of the nfs-utils of archlinux
>> 
>> The same nfs-utils version should behave the same way no matter what (modulo bugs, of course).  It may be that the two packages were built with different configure options.  Not sure how we could find out how these were built.
>> 
>> Basically, I'm trying to figure out how to reproduce the problem here.
>> 
>>> not sure about MNT version config , i dont remember intentionally
>>> changing this , where i can check it ?
>> 
>> On the server, look at the command line options for rpc.mountd.  I'm not familiar with Ubuntu or Debian's start-up scripts, so I can't be more specific than that.
>> 
>> Note that this is an independent issue from the mount problem, but it's incorrect and contributing to mount's misbehavior.
>> 
>>> pd: sorry for the double email i forget press reply all
>>> 
>>> On Mon, Feb 14, 2011 at 11:56 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>> Hi Edgar-
>>>> 
>>>> On Feb 11, 2011, at 6:46 PM, Edgar Almonte wrote:
>>>> 
>>>>> hmm i will try update to the last version but is the lasted in
>>>>> official repository of my distro
>>>> 
>>>> Yes, that could be a problem.  Out of curiosity, can you tell us what version of nfs-utils is running on the working Debian client you have?
>>>> 
>>>>> the rpcinfo -p localhost output ( run at the server )
>>>>> 
>>>>> 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
>>>>>    391002    2   tcp    661  sgi_fam
>>>>>    100024    1   udp  49216  status
>>>>>    100024    1   tcp  42903  status
>>>>>    100003    2   tcp   2049  nfs
>>>>>    100003    3   tcp   2049  nfs
>>>>>    100003    4   tcp   2049  nfs
>>>>>    100227    2   tcp   2049  nfs_acl
>>>>>    100227    3   tcp   2049  nfs_acl
>>>>>    100003    2   udp   2049  nfs
>>>>>    100003    3   udp   2049  nfs
>>>>>    100003    4   udp   2049  nfs
>>>>>    100227    2   udp   2049  nfs_acl
>>>>>    100227    3   udp   2049  nfs_acl
>>>>>    100021    1   udp  36092  nlockmgr
>>>>>    100021    3   udp  36092  nlockmgr
>>>>>    100021    4   udp  36092  nlockmgr
>>>>>    100021    1   tcp  52268  nlockmgr
>>>>>    100021    3   tcp  52268  nlockmgr
>>>>>    100021    4   tcp  52268  nlockmgr
>>>>>    100005    3   udp  41849  mountd
>>>>>    100005    3   tcp  46012  mountd
>>>> 
>>>> This looks weird.  NFS is available on TCP and UDP in all three versions, but MNT is available in version 3.  I wonder if this is confusing mount.nfs.  Is there any reason why your server is configured to disable MNT version 1?
>>>> 
>>>>> On Fri, Feb 11, 2011 at 7:27 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>> 
>>>>>> On Feb 11, 2011, at 6:13 PM, Edgar Almonte wrote:
>>>>>> 
>>>>>>> Was a ipv6 issues because i add this to the client with the problem:
>>>>>>> options ipv6 disable=1
>>>>>>> in /etc/modprobe.d/modprobe.conf
>>>>>>> reboot and mount without using udp option work, output:
>>>>>>> 
>>>>>>> [root@circle zen]# mount heaven.local:/STORAGE /nfs/STORAGE/ -v
>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>> mount.nfs: timeout set for Fri Feb 11 19:11:53 2011
>>>>>>> mount.nfs: trying text-based options
>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41849
>>>>>>> 
>>>>>>> and i think maybe is a bug of nfs-utils that can't handle in the
>>>>>>> proper way this because a connection using ipv4 protocol exist ( even
>>>>>>> it detect it )
>>>>>>> 
>>>>>>> should i need report something like this ? or and wrong ?
>>>>>> 
>>>>>> I swear this has been discussed and fixed already, but I can't find a specific fix in the bugzilla database or the git log.  nfs-utils 1.2.2 is at least a year old.  Can you update to the latest version and try again?
>>>>>> 
>>>>>> Also, please report the NFS server's transport capabilities.  "rpcinfo 192.168.1.102" should work.  You may need the "-p" option.
>>>>>> 
>>>>>>> On Fri, Feb 11, 2011 at 6:57 PM, Edgar Almonte <samudhio@gmail.com> wrote:
>>>>>>>> [root@circle zen]# pacman -Qs nfs-utils
>>>>>>>> local/nfs-utils 1.2.2-4 [0.69 MB]
>>>>>>>>    Support programs for Network File Systems
>>>>>>>> [root@circle zen]# uname -a
>>>>>>>> Linux circle 2.6.36-ARCH #1 SMP PREEMPT Mon Jan 24 18:34:55 UTC 2011
>>>>>>>> i686 Intel(R) Atom(TM) CPU D510 @ 1.66GHz GenuineIntel GNU/Linux
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Fri, Feb 11, 2011 at 1:40 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>>> Which nfs-utils version and kernel release are you using?  What transport protocols are available from your NFS server?  It looks like only UDP.  I recall a bug fix in this area in the past year.
>>>>>>>>> 
>>>>>>>>> On Feb 11, 2011, at 12:35 PM, Edgar Almonte wrote:
>>>>>>>>> 
>>>>>>>>>> i get this without udp option:
>>>>>>>>>> 
>>>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:27:33 2011
>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>> 'vers=4,addr=fe80::224:21ff:fe57:368d,clientaddr=::'
>>>>>>>>>> mount.nfs: mount(2): Input/output error
>>>>>>>>>> mount.nfs: mount system call failed
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> and with udp option:
>>>>>>>>>> 
>>>>>>>>>> ount: no type was given - I'll assume nfs because of the colon
>>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:28:29 2011
>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>> 'udp,vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>>> mount.nfs: trying text-based options 'udp,addr=192.168.1.102'
>>>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=17
>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot UDP port 2049
>>>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>>>>>> heaven.local:/STORAGE on /nfs/STORAGE type nfs (rw,udp)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> for other distro ( debian laptop ) without the udp option:
>>>>>>>>>> 
>>>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:31:37 2011
>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.107'
>>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>>>>>> heaven.local:/STORAGE on /srv/nfs type nfs (rw)
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> and look like is some ipv6 issues
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Thu, Feb 10, 2011 at 11:50 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> hello list
>>>>>>>>>>>> 
>>>>>>>>>>>> like the subject say after some upgrade of my distro ( i have 2
>>>>>>>>>>>> machine with the same distro and only in one happne the problem ) i
>>>>>>>>>>>> can only mount nfs share using the option -o udp , without it i get
>>>>>>>>>>>> this error
>>>>>>>>>>>> mount.nfs: mount system call failed
>>>>>>>>>>> 
>>>>>>>>>>> What does
>>>>>>>>>>> 
>>>>>>>>>>>  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v
>>>>>>>>>>> 
>>>>>>>>>>> say?  It should tell you how the mount command is negotiating with the server.
>>>>>>>>>>> 
>>>>>>>>>>>> i am using avahi-dns ( mdns ) for hostname resolve
>>>>>>>>>>>> 
>>>>>>>>>>>> command used:
>>>>>>>>>>>> mount heaven.local:/STORAGE /nfs/STORAGE/
>>>>>>>>>>>> check dns is work right :
>>>>>>>>>>>> 
>>>>>>>>>>>> ping heaven.local
>>>>>>>>>>>> PING heaven.local (192.168.1.102) 56(84) bytes of data.
>>>>>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
>>>>>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
>>>>>>>>>>>> ^C
>>>>>>>>>>>> --- heaven.local ping statistics ---
>>>>>>>>>>>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>>>>>>>>>>>> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> anyidea what i need check for solve this issue ?
>>>>>>>>>>>> 
>>>>>>>>>>>> thanks
>>>>>>>>>>>> --
>>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Chuck Lever
>>>>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Chuck Lever
>>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Chuck Lever
>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> --
>>>> Chuck Lever
>>>> chuck[dot]lever[at]oracle[dot]com
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>> 
>> 
>> 
>> 
>> 

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFS only mount with -o udp option

[Edgar Almonte]

 yes the server is  archlinux x86-64. i mount in the server a folder
that i share in the client using NFSv4 setup :
client share setup:
(/etc/exports )
/srv/nfs4          192.168.1.1/24(rw,fsid=0,no_subtree_check,async,crossmnt)
/srv/nfs4/torrent_files   192.168.1.1/24(rw,no_subtree_check,async)

i have this setup in the client ( with the problem , archlinux i686 )
and i mount this in the main server ( file server ) without udp option
and work fine ( and without the modprobe.conf ipv6 line )

now the share setup in the server ( the X86-64 ) :
(/etc/exports )
/STORAGE/ 192.168.1.1/24(ro,fsid=0,no_subtree_check,insecure,sync,nohide)

which i read is the way of share for NFSv3 and/or NFSv2
( i do this because i am noob at nfs but i will take in the future the
NFSv4 way )
now when i mount that share in the client is where i get the error (
without using the udp option and without the modprobe.conf line of
ipv6 )



netconfig cat output:
#
# The network configuration file. This file is currently only used in
# conjunction with the TI-RPC code in the libtirpc library.
#
# Entries consist of:
#
#       <network_id> <semantics> <flags> <protofamily> <protoname> \
#               <device> <nametoaddr_libs>
#
# The <device> and <nametoaddr_libs> fields are always empty in this
# implementation.
#
udp        tpi_clts      v     inet     udp     -       -
tcp        tpi_cots_ord  v     inet     tcp     -       -
udp6       tpi_clts      v     inet6    udp     -       -
tcp6       tpi_cots_ord  v     inet6    tcp     -       -
rawip      tpi_raw       -     inet      -      -       -
local      tpi_cots_ord  -     loopback  -      -       -
unix       tpi_cots_ord  -     loopback  -      -       -

On Tue, Feb 15, 2011 at 6:54 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>
> On Feb 15, 2011, at 5:31 PM, Edgar Almonte wrote:
>
>> i confirm the ipv6 things i tell you , i comment the line
>>
>> options ipv6 disable=1
>>
>> in /etc/modprobe.d/modprobe.conf
>>
>> the same error in mount without using -o udp
>>
>> but the thing is i share folder in that client and mount it in the
>> server normal without the upd option and work fine ( the server have
>> the same distro that the client with the problem "archlinux" ) and in
>> the server i dont have the option in the /etc/modprobe.d/modprobe.conf
>>
>> [root@heaven Desktop]# mount  circle.local:/torrent_files
>> /media/torrent_files/ -v
>> mount: no type was given - I'll assume nfs because of the colon
>> mount.nfs: timeout set for Tue Feb 15 18:27:24 2011
>> mount.nfs: trying text-based options
>> 'vers=4,addr=192.168.1.103,clientaddr=192.168.1.102'
>> circle.local:/torrent_files on /media/torrent_files type nfs (rw)
>>
>> i use nfs4 for this share in the server and using nfs3 for the share
>>
>> another thing is that the server have the version 64bit of the same
>> package in the client but i686 plataform
>
> Let me confirm what you said:
>
>  1.  The server is running the latest ARCH (x86-64).  Mounting the share via loopback on the server gets you an NFSv4 mount
>  2.  The client is running the latest ARCH (x86-32).  Mounting the share from the client gets you an NFSv3, not an NFSv4, mount, and you have to specify UDP to make the negotiation complete successfully
>  3.  Preventing ipv6.ko from loading on the client allows the mount to proceed without specifying extra options
>
> I tried to reproduce this this morning from an x86-64 client using the latest upstream nfs-utils source, and was able to get an NFSv4 mount immediately.  In other words, I reproduced the behavior in 1, but was not able to reproduce the behavior in 2.  I can try again with an x86-32 client soon, but I'm traveling tomorrow.
>
> Specifying "udp" forces the mount request to use IPv4.  If my theory is correct, specifying "tcp" also works, and gets you an NFSv4 mount.  I wasn't aware that ARCH had libtirpc and an IPv6-enabled nfs-utils build.  Does the failing client have a copy of /etc/netconfig, and can you send it?
>
>> rpc.mountd option:
>> root@heaven Desktop]# ps aux | grep rpc.mountd
>> root      4351  0.0  0.0  54512   660 ?        Ss   18:11   0:00
>> /usr/sbin/rpc.mountd --no-nfs-version 1 --no-nfs-version 2
>
> That's consistent with the "rpcinfo" output you provided, but it doesn't explain why nfsd is still providing NFSv2.  Probably not a big deal, as the mount command on your client is failing before it even tries vers=2.
>
>> On Tue, Feb 15, 2011 at 11:27 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>
>>> On Feb 14, 2011, at 9:09 PM, Edgar Almonte wrote:
>>>
>>>> in debian dont exist a package called nfs-utils , i get nfs-common and
>>>> say the same version of the nfs-utils of archlinux
>>>
>>> The same nfs-utils version should behave the same way no matter what (modulo bugs, of course).  It may be that the two packages were built with different configure options.  Not sure how we could find out how these were built.
>>>
>>> Basically, I'm trying to figure out how to reproduce the problem here.
>>>
>>>> not sure about MNT version config , i dont remember intentionally
>>>> changing this , where i can check it ?
>>>
>>> On the server, look at the command line options for rpc.mountd.  I'm not familiar with Ubuntu or Debian's start-up scripts, so I can't be more specific than that.
>>>
>>> Note that this is an independent issue from the mount problem, but it's incorrect and contributing to mount's misbehavior.
>>>
>>>> pd: sorry for the double email i forget press reply all
>>>>
>>>> On Mon, Feb 14, 2011 at 11:56 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>> Hi Edgar-
>>>>>
>>>>> On Feb 11, 2011, at 6:46 PM, Edgar Almonte wrote:
>>>>>
>>>>>> hmm i will try update to the last version but is the lasted in
>>>>>> official repository of my distro
>>>>>
>>>>> Yes, that could be a problem.  Out of curiosity, can you tell us what version of nfs-utils is running on the working Debian client you have?
>>>>>
>>>>>> the rpcinfo -p localhost output ( run at the server )
>>>>>>
>>>>>> 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
>>>>>>    391002    2   tcp    661  sgi_fam
>>>>>>    100024    1   udp  49216  status
>>>>>>    100024    1   tcp  42903  status
>>>>>>    100003    2   tcp   2049  nfs
>>>>>>    100003    3   tcp   2049  nfs
>>>>>>    100003    4   tcp   2049  nfs
>>>>>>    100227    2   tcp   2049  nfs_acl
>>>>>>    100227    3   tcp   2049  nfs_acl
>>>>>>    100003    2   udp   2049  nfs
>>>>>>    100003    3   udp   2049  nfs
>>>>>>    100003    4   udp   2049  nfs
>>>>>>    100227    2   udp   2049  nfs_acl
>>>>>>    100227    3   udp   2049  nfs_acl
>>>>>>    100021    1   udp  36092  nlockmgr
>>>>>>    100021    3   udp  36092  nlockmgr
>>>>>>    100021    4   udp  36092  nlockmgr
>>>>>>    100021    1   tcp  52268  nlockmgr
>>>>>>    100021    3   tcp  52268  nlockmgr
>>>>>>    100021    4   tcp  52268  nlockmgr
>>>>>>    100005    3   udp  41849  mountd
>>>>>>    100005    3   tcp  46012  mountd
>>>>>
>>>>> This looks weird.  NFS is available on TCP and UDP in all three versions, but MNT is available in version 3.  I wonder if this is confusing mount.nfs.  Is there any reason why your server is configured to disable MNT version 1?
>>>>>
>>>>>> On Fri, Feb 11, 2011 at 7:27 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>
>>>>>>> On Feb 11, 2011, at 6:13 PM, Edgar Almonte wrote:
>>>>>>>
>>>>>>>> Was a ipv6 issues because i add this to the client with the problem:
>>>>>>>> options ipv6 disable=1
>>>>>>>> in /etc/modprobe.d/modprobe.conf
>>>>>>>> reboot and mount without using udp option work, output:
>>>>>>>>
>>>>>>>> [root@circle zen]# mount heaven.local:/STORAGE /nfs/STORAGE/ -v
>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>> mount.nfs: timeout set for Fri Feb 11 19:11:53 2011
>>>>>>>> mount.nfs: trying text-based options
>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41849
>>>>>>>>
>>>>>>>> and i think maybe is a bug of nfs-utils that can't handle in the
>>>>>>>> proper way this because a connection using ipv4 protocol exist ( even
>>>>>>>> it detect it )
>>>>>>>>
>>>>>>>> should i need report something like this ? or and wrong ?
>>>>>>>
>>>>>>> I swear this has been discussed and fixed already, but I can't find a specific fix in the bugzilla database or the git log.  nfs-utils 1.2.2 is at least a year old.  Can you update to the latest version and try again?
>>>>>>>
>>>>>>> Also, please report the NFS server's transport capabilities.  "rpcinfo 192.168.1.102" should work.  You may need the "-p" option.
>>>>>>>
>>>>>>>> On Fri, Feb 11, 2011 at 6:57 PM, Edgar Almonte <samudhio@gmail.com> wrote:
>>>>>>>>> [root@circle zen]# pacman -Qs nfs-utils
>>>>>>>>> local/nfs-utils 1.2.2-4 [0.69 MB]
>>>>>>>>>    Support programs for Network File Systems
>>>>>>>>> [root@circle zen]# uname -a
>>>>>>>>> Linux circle 2.6.36-ARCH #1 SMP PREEMPT Mon Jan 24 18:34:55 UTC 2011
>>>>>>>>> i686 Intel(R) Atom(TM) CPU D510 @ 1.66GHz GenuineIntel GNU/Linux
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Feb 11, 2011 at 1:40 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>>>> Which nfs-utils version and kernel release are you using?  What transport protocols are available from your NFS server?  It looks like only UDP.  I recall a bug fix in this area in the past year.
>>>>>>>>>>
>>>>>>>>>> On Feb 11, 2011, at 12:35 PM, Edgar Almonte wrote:
>>>>>>>>>>
>>>>>>>>>>> i get this without udp option:
>>>>>>>>>>>
>>>>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:27:33 2011
>>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>>> 'vers=4,addr=fe80::224:21ff:fe57:368d,clientaddr=::'
>>>>>>>>>>> mount.nfs: mount(2): Input/output error
>>>>>>>>>>> mount.nfs: mount system call failed
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> and with udp option:
>>>>>>>>>>>
>>>>>>>>>>> ount: no type was given - I'll assume nfs because of the colon
>>>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:28:29 2011
>>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>>> 'udp,vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>>>> mount.nfs: trying text-based options 'udp,addr=192.168.1.102'
>>>>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=17
>>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot UDP port 2049
>>>>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>>>>>>> heaven.local:/STORAGE on /nfs/STORAGE type nfs (rw,udp)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> for other distro ( debian laptop ) without the udp option:
>>>>>>>>>>>
>>>>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:31:37 2011
>>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.107'
>>>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>>>>>>> heaven.local:/STORAGE on /srv/nfs type nfs (rw)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> and look like is some ipv6 issues
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Feb 10, 2011 at 11:50 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> hello list
>>>>>>>>>>>>>
>>>>>>>>>>>>> like the subject say after some upgrade of my distro ( i have 2
>>>>>>>>>>>>> machine with the same distro and only in one happne the problem ) i
>>>>>>>>>>>>> can only mount nfs share using the option -o udp , without it i get
>>>>>>>>>>>>> this error
>>>>>>>>>>>>> mount.nfs: mount system call failed
>>>>>>>>>>>>
>>>>>>>>>>>> What does
>>>>>>>>>>>>
>>>>>>>>>>>>  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v
>>>>>>>>>>>>
>>>>>>>>>>>> say?  It should tell you how the mount command is negotiating with the server.
>>>>>>>>>>>>
>>>>>>>>>>>>> i am using avahi-dns ( mdns ) for hostname resolve
>>>>>>>>>>>>>
>>>>>>>>>>>>> command used:
>>>>>>>>>>>>> mount heaven.local:/STORAGE /nfs/STORAGE/
>>>>>>>>>>>>> check dns is work right :
>>>>>>>>>>>>>
>>>>>>>>>>>>> ping heaven.local
>>>>>>>>>>>>> PING heaven.local (192.168.1.102) 56(84) bytes of data.
>>>>>>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
>>>>>>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
>>>>>>>>>>>>> ^C
>>>>>>>>>>>>> --- heaven.local ping statistics ---
>>>>>>>>>>>>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>>>>>>>>>>>>> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> anyidea what i need check for solve this issue ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> --
>>>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Chuck Lever
>>>>>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Chuck Lever
>>>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Chuck Lever
>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>> --
>>>>> Chuck Lever
>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>> --
>>> Chuck Lever
>>> chuck[dot]lever[at]oracle[dot]com
>>>
>>>
>>>
>>>
>>>
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
>
>

Re: NFS only mount with -o udp option

[Chuck Lever]

On Feb 15, 2011, at 5:55 PM, Edgar Almonte wrote:

> yes the server is  archlinux x86-64. i mount in the server a folder
> that i share in the client using NFSv4 setup :
> client share setup:
> (/etc/exports )
> /srv/nfs4          192.168.1.1/24(rw,fsid=0,no_subtree_check,async,crossmnt)
> /srv/nfs4/torrent_files   192.168.1.1/24(rw,no_subtree_check,async)
> 
> i have this setup in the client ( with the problem , archlinux i686 )
> and i mount this in the main server ( file server ) without udp option
> and work fine ( and without the modprobe.conf ipv6 line )
> 
> now the share setup in the server ( the X86-64 ) :
> (/etc/exports )
> /STORAGE/ 192.168.1.1/24(ro,fsid=0,no_subtree_check,insecure,sync,nohide)
> 
> which i read is the way of share for NFSv3 and/or NFSv2
> ( i do this because i am noob at nfs but i will take in the future the
> NFSv4 way )
> now when i mount that share in the client is where i get the error (
> without using the udp option and without the modprobe.conf line of
> ipv6 )

I can't reproduce your mount failure on my x86 client running the latest nfs-utils.  I recommend contacting your distributor for support, as I suspect whatever problem you have hit is fixed by a later release of nfs-utils.

> netconfig cat output:
> #
> # The network configuration file. This file is currently only used in
> # conjunction with the TI-RPC code in the libtirpc library.
> #
> # Entries consist of:
> #
> #       <network_id> <semantics> <flags> <protofamily> <protoname> \
> #               <device> <nametoaddr_libs>
> #
> # The <device> and <nametoaddr_libs> fields are always empty in this
> # implementation.
> #
> udp        tpi_clts      v     inet     udp     -       -
> tcp        tpi_cots_ord  v     inet     tcp     -       -
> udp6       tpi_clts      v     inet6    udp     -       -
> tcp6       tpi_cots_ord  v     inet6    tcp     -       -
> rawip      tpi_raw       -     inet      -      -       -
> local      tpi_cots_ord  -     loopback  -      -       -
> unix       tpi_cots_ord  -     loopback  -      -       -
> 
> On Tue, Feb 15, 2011 at 6:54 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>> 
>> On Feb 15, 2011, at 5:31 PM, Edgar Almonte wrote:
>> 
>>> i confirm the ipv6 things i tell you , i comment the line
>>> 
>>> options ipv6 disable=1
>>> 
>>> in /etc/modprobe.d/modprobe.conf
>>> 
>>> the same error in mount without using -o udp
>>> 
>>> but the thing is i share folder in that client and mount it in the
>>> server normal without the upd option and work fine ( the server have
>>> the same distro that the client with the problem "archlinux" ) and in
>>> the server i dont have the option in the /etc/modprobe.d/modprobe.conf
>>> 
>>> [root@heaven Desktop]# mount  circle.local:/torrent_files
>>> /media/torrent_files/ -v
>>> mount: no type was given - I'll assume nfs because of the colon
>>> mount.nfs: timeout set for Tue Feb 15 18:27:24 2011
>>> mount.nfs: trying text-based options
>>> 'vers=4,addr=192.168.1.103,clientaddr=192.168.1.102'
>>> circle.local:/torrent_files on /media/torrent_files type nfs (rw)
>>> 
>>> i use nfs4 for this share in the server and using nfs3 for the share
>>> 
>>> another thing is that the server have the version 64bit of the same
>>> package in the client but i686 plataform
>> 
>> Let me confirm what you said:
>> 
>>  1.  The server is running the latest ARCH (x86-64).  Mounting the share via loopback on the server gets you an NFSv4 mount
>>  2.  The client is running the latest ARCH (x86-32).  Mounting the share from the client gets you an NFSv3, not an NFSv4, mount, and you have to specify UDP to make the negotiation complete successfully
>>  3.  Preventing ipv6.ko from loading on the client allows the mount to proceed without specifying extra options
>> 
>> I tried to reproduce this this morning from an x86-64 client using the latest upstream nfs-utils source, and was able to get an NFSv4 mount immediately.  In other words, I reproduced the behavior in 1, but was not able to reproduce the behavior in 2.  I can try again with an x86-32 client soon, but I'm traveling tomorrow.
>> 
>> Specifying "udp" forces the mount request to use IPv4.  If my theory is correct, specifying "tcp" also works, and gets you an NFSv4 mount.  I wasn't aware that ARCH had libtirpc and an IPv6-enabled nfs-utils build.  Does the failing client have a copy of /etc/netconfig, and can you send it?
>> 
>>> rpc.mountd option:
>>> root@heaven Desktop]# ps aux | grep rpc.mountd
>>> root      4351  0.0  0.0  54512   660 ?        Ss   18:11   0:00
>>> /usr/sbin/rpc.mountd --no-nfs-version 1 --no-nfs-version 2
>> 
>> That's consistent with the "rpcinfo" output you provided, but it doesn't explain why nfsd is still providing NFSv2.  Probably not a big deal, as the mount command on your client is failing before it even tries vers=2.
>> 
>>> On Tue, Feb 15, 2011 at 11:27 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>> 
>>>> On Feb 14, 2011, at 9:09 PM, Edgar Almonte wrote:
>>>> 
>>>>> in debian dont exist a package called nfs-utils , i get nfs-common and
>>>>> say the same version of the nfs-utils of archlinux
>>>> 
>>>> The same nfs-utils version should behave the same way no matter what (modulo bugs, of course).  It may be that the two packages were built with different configure options.  Not sure how we could find out how these were built.
>>>> 
>>>> Basically, I'm trying to figure out how to reproduce the problem here.
>>>> 
>>>>> not sure about MNT version config , i dont remember intentionally
>>>>> changing this , where i can check it ?
>>>> 
>>>> On the server, look at the command line options for rpc.mountd.  I'm not familiar with Ubuntu or Debian's start-up scripts, so I can't be more specific than that.
>>>> 
>>>> Note that this is an independent issue from the mount problem, but it's incorrect and contributing to mount's misbehavior.
>>>> 
>>>>> pd: sorry for the double email i forget press reply all
>>>>> 
>>>>> On Mon, Feb 14, 2011 at 11:56 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>> Hi Edgar-
>>>>>> 
>>>>>> On Feb 11, 2011, at 6:46 PM, Edgar Almonte wrote:
>>>>>> 
>>>>>>> hmm i will try update to the last version but is the lasted in
>>>>>>> official repository of my distro
>>>>>> 
>>>>>> Yes, that could be a problem.  Out of curiosity, can you tell us what version of nfs-utils is running on the working Debian client you have?
>>>>>> 
>>>>>>> the rpcinfo -p localhost output ( run at the server )
>>>>>>> 
>>>>>>> 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
>>>>>>>    391002    2   tcp    661  sgi_fam
>>>>>>>    100024    1   udp  49216  status
>>>>>>>    100024    1   tcp  42903  status
>>>>>>>    100003    2   tcp   2049  nfs
>>>>>>>    100003    3   tcp   2049  nfs
>>>>>>>    100003    4   tcp   2049  nfs
>>>>>>>    100227    2   tcp   2049  nfs_acl
>>>>>>>    100227    3   tcp   2049  nfs_acl
>>>>>>>    100003    2   udp   2049  nfs
>>>>>>>    100003    3   udp   2049  nfs
>>>>>>>    100003    4   udp   2049  nfs
>>>>>>>    100227    2   udp   2049  nfs_acl
>>>>>>>    100227    3   udp   2049  nfs_acl
>>>>>>>    100021    1   udp  36092  nlockmgr
>>>>>>>    100021    3   udp  36092  nlockmgr
>>>>>>>    100021    4   udp  36092  nlockmgr
>>>>>>>    100021    1   tcp  52268  nlockmgr
>>>>>>>    100021    3   tcp  52268  nlockmgr
>>>>>>>    100021    4   tcp  52268  nlockmgr
>>>>>>>    100005    3   udp  41849  mountd
>>>>>>>    100005    3   tcp  46012  mountd
>>>>>> 
>>>>>> This looks weird.  NFS is available on TCP and UDP in all three versions, but MNT is available in version 3.  I wonder if this is confusing mount.nfs.  Is there any reason why your server is configured to disable MNT version 1?
>>>>>> 
>>>>>>> On Fri, Feb 11, 2011 at 7:27 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>> 
>>>>>>>> On Feb 11, 2011, at 6:13 PM, Edgar Almonte wrote:
>>>>>>>> 
>>>>>>>>> Was a ipv6 issues because i add this to the client with the problem:
>>>>>>>>> options ipv6 disable=1
>>>>>>>>> in /etc/modprobe.d/modprobe.conf
>>>>>>>>> reboot and mount without using udp option work, output:
>>>>>>>>> 
>>>>>>>>> [root@circle zen]# mount heaven.local:/STORAGE /nfs/STORAGE/ -v
>>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 19:11:53 2011
>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41849
>>>>>>>>> 
>>>>>>>>> and i think maybe is a bug of nfs-utils that can't handle in the
>>>>>>>>> proper way this because a connection using ipv4 protocol exist ( even
>>>>>>>>> it detect it )
>>>>>>>>> 
>>>>>>>>> should i need report something like this ? or and wrong ?
>>>>>>>> 
>>>>>>>> I swear this has been discussed and fixed already, but I can't find a specific fix in the bugzilla database or the git log.  nfs-utils 1.2.2 is at least a year old.  Can you update to the latest version and try again?
>>>>>>>> 
>>>>>>>> Also, please report the NFS server's transport capabilities.  "rpcinfo 192.168.1.102" should work.  You may need the "-p" option.
>>>>>>>> 
>>>>>>>>> On Fri, Feb 11, 2011 at 6:57 PM, Edgar Almonte <samudhio@gmail.com> wrote:
>>>>>>>>>> [root@circle zen]# pacman -Qs nfs-utils
>>>>>>>>>> local/nfs-utils 1.2.2-4 [0.69 MB]
>>>>>>>>>>    Support programs for Network File Systems
>>>>>>>>>> [root@circle zen]# uname -a
>>>>>>>>>> Linux circle 2.6.36-ARCH #1 SMP PREEMPT Mon Jan 24 18:34:55 UTC 2011
>>>>>>>>>> i686 Intel(R) Atom(TM) CPU D510 @ 1.66GHz GenuineIntel GNU/Linux
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Fri, Feb 11, 2011 at 1:40 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>>>>> Which nfs-utils version and kernel release are you using?  What transport protocols are available from your NFS server?  It looks like only UDP.  I recall a bug fix in this area in the past year.
>>>>>>>>>>> 
>>>>>>>>>>> On Feb 11, 2011, at 12:35 PM, Edgar Almonte wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> i get this without udp option:
>>>>>>>>>>>> 
>>>>>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:27:33 2011
>>>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>>>> 'vers=4,addr=fe80::224:21ff:fe57:368d,clientaddr=::'
>>>>>>>>>>>> mount.nfs: mount(2): Input/output error
>>>>>>>>>>>> mount.nfs: mount system call failed
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> and with udp option:
>>>>>>>>>>>> 
>>>>>>>>>>>> ount: no type was given - I'll assume nfs because of the colon
>>>>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:28:29 2011
>>>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>>>> 'udp,vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>>>>> mount.nfs: trying text-based options 'udp,addr=192.168.1.102'
>>>>>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=17
>>>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot UDP port 2049
>>>>>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>>>>>>>> heaven.local:/STORAGE on /nfs/STORAGE type nfs (rw,udp)
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> for other distro ( debian laptop ) without the udp option:
>>>>>>>>>>>> 
>>>>>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:31:37 2011
>>>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.107'
>>>>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>>>>>>>> heaven.local:/STORAGE on /srv/nfs type nfs (rw)
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> and look like is some ipv6 issues
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, Feb 10, 2011 at 11:50 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> hello list
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> like the subject say after some upgrade of my distro ( i have 2
>>>>>>>>>>>>>> machine with the same distro and only in one happne the problem ) i
>>>>>>>>>>>>>> can only mount nfs share using the option -o udp , without it i get
>>>>>>>>>>>>>> this error
>>>>>>>>>>>>>> mount.nfs: mount system call failed
>>>>>>>>>>>>> 
>>>>>>>>>>>>> What does
>>>>>>>>>>>>> 
>>>>>>>>>>>>>  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v
>>>>>>>>>>>>> 
>>>>>>>>>>>>> say?  It should tell you how the mount command is negotiating with the server.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> i am using avahi-dns ( mdns ) for hostname resolve
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> command used:
>>>>>>>>>>>>>> mount heaven.local:/STORAGE /nfs/STORAGE/
>>>>>>>>>>>>>> check dns is work right :
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ping heaven.local
>>>>>>>>>>>>>> PING heaven.local (192.168.1.102) 56(84) bytes of data.
>>>>>>>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
>>>>>>>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
>>>>>>>>>>>>>> ^C
>>>>>>>>>>>>>> --- heaven.local ping statistics ---
>>>>>>>>>>>>>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>>>>>>>>>>>>>> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> anyidea what i need check for solve this issue ?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>>>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Chuck Lever
>>>>>>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Chuck Lever
>>>>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Chuck Lever
>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Chuck Lever
>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> --
>>>> Chuck Lever
>>>> chuck[dot]lever[at]oracle[dot]com
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>> 
>> 
>> 
>> 
>> 

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: NFS only mount with -o udp option

[Edgar Almonte]

Thanks ,

i will try get update nfs-utils to the last version , already contact
the maintainer of the package.

On Mon, Feb 21, 2011 at 4:30 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>
> On Feb 15, 2011, at 5:55 PM, Edgar Almonte wrote:
>
>> yes the server is  archlinux x86-64. i mount in the server a folder
>> that i share in the client using NFSv4 setup :
>> client share setup:
>> (/etc/exports )
>> /srv/nfs4          192.168.1.1/24(rw,fsid=0,no_subtree_check,async,crossmnt)
>> /srv/nfs4/torrent_files   192.168.1.1/24(rw,no_subtree_check,async)
>>
>> i have this setup in the client ( with the problem , archlinux i686 )
>> and i mount this in the main server ( file server ) without udp option
>> and work fine ( and without the modprobe.conf ipv6 line )
>>
>> now the share setup in the server ( the X86-64 ) :
>> (/etc/exports )
>> /STORAGE/ 192.168.1.1/24(ro,fsid=0,no_subtree_check,insecure,sync,nohide)
>>
>> which i read is the way of share for NFSv3 and/or NFSv2
>> ( i do this because i am noob at nfs but i will take in the future the
>> NFSv4 way )
>> now when i mount that share in the client is where i get the error (
>> without using the udp option and without the modprobe.conf line of
>> ipv6 )
>
> I can't reproduce your mount failure on my x86 client running the latest nfs-utils.  I recommend contacting your distributor for support, as I suspect whatever problem you have hit is fixed by a later release of nfs-utils.
>
>> netconfig cat output:
>> #
>> # The network configuration file. This file is currently only used in
>> # conjunction with the TI-RPC code in the libtirpc library.
>> #
>> # Entries consist of:
>> #
>> #       <network_id> <semantics> <flags> <protofamily> <protoname> \
>> #               <device> <nametoaddr_libs>
>> #
>> # The <device> and <nametoaddr_libs> fields are always empty in this
>> # implementation.
>> #
>> udp        tpi_clts      v     inet     udp     -       -
>> tcp        tpi_cots_ord  v     inet     tcp     -       -
>> udp6       tpi_clts      v     inet6    udp     -       -
>> tcp6       tpi_cots_ord  v     inet6    tcp     -       -
>> rawip      tpi_raw       -     inet      -      -       -
>> local      tpi_cots_ord  -     loopback  -      -       -
>> unix       tpi_cots_ord  -     loopback  -      -       -
>>
>> On Tue, Feb 15, 2011 at 6:54 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>
>>> On Feb 15, 2011, at 5:31 PM, Edgar Almonte wrote:
>>>
>>>> i confirm the ipv6 things i tell you , i comment the line
>>>>
>>>> options ipv6 disable=1
>>>>
>>>> in /etc/modprobe.d/modprobe.conf
>>>>
>>>> the same error in mount without using -o udp
>>>>
>>>> but the thing is i share folder in that client and mount it in the
>>>> server normal without the upd option and work fine ( the server have
>>>> the same distro that the client with the problem "archlinux" ) and in
>>>> the server i dont have the option in the /etc/modprobe.d/modprobe.conf
>>>>
>>>> [root@heaven Desktop]# mount  circle.local:/torrent_files
>>>> /media/torrent_files/ -v
>>>> mount: no type was given - I'll assume nfs because of the colon
>>>> mount.nfs: timeout set for Tue Feb 15 18:27:24 2011
>>>> mount.nfs: trying text-based options
>>>> 'vers=4,addr=192.168.1.103,clientaddr=192.168.1.102'
>>>> circle.local:/torrent_files on /media/torrent_files type nfs (rw)
>>>>
>>>> i use nfs4 for this share in the server and using nfs3 for the share
>>>>
>>>> another thing is that the server have the version 64bit of the same
>>>> package in the client but i686 plataform
>>>
>>> Let me confirm what you said:
>>>
>>>  1.  The server is running the latest ARCH (x86-64).  Mounting the share via loopback on the server gets you an NFSv4 mount
>>>  2.  The client is running the latest ARCH (x86-32).  Mounting the share from the client gets you an NFSv3, not an NFSv4, mount, and you have to specify UDP to make the negotiation complete successfully
>>>  3.  Preventing ipv6.ko from loading on the client allows the mount to proceed without specifying extra options
>>>
>>> I tried to reproduce this this morning from an x86-64 client using the latest upstream nfs-utils source, and was able to get an NFSv4 mount immediately.  In other words, I reproduced the behavior in 1, but was not able to reproduce the behavior in 2.  I can try again with an x86-32 client soon, but I'm traveling tomorrow.
>>>
>>> Specifying "udp" forces the mount request to use IPv4.  If my theory is correct, specifying "tcp" also works, and gets you an NFSv4 mount.  I wasn't aware that ARCH had libtirpc and an IPv6-enabled nfs-utils build.  Does the failing client have a copy of /etc/netconfig, and can you send it?
>>>
>>>> rpc.mountd option:
>>>> root@heaven Desktop]# ps aux | grep rpc.mountd
>>>> root      4351  0.0  0.0  54512   660 ?        Ss   18:11   0:00
>>>> /usr/sbin/rpc.mountd --no-nfs-version 1 --no-nfs-version 2
>>>
>>> That's consistent with the "rpcinfo" output you provided, but it doesn't explain why nfsd is still providing NFSv2.  Probably not a big deal, as the mount command on your client is failing before it even tries vers=2.
>>>
>>>> On Tue, Feb 15, 2011 at 11:27 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>
>>>>> On Feb 14, 2011, at 9:09 PM, Edgar Almonte wrote:
>>>>>
>>>>>> in debian dont exist a package called nfs-utils , i get nfs-common and
>>>>>> say the same version of the nfs-utils of archlinux
>>>>>
>>>>> The same nfs-utils version should behave the same way no matter what (modulo bugs, of course).  It may be that the two packages were built with different configure options.  Not sure how we could find out how these were built.
>>>>>
>>>>> Basically, I'm trying to figure out how to reproduce the problem here.
>>>>>
>>>>>> not sure about MNT version config , i dont remember intentionally
>>>>>> changing this , where i can check it ?
>>>>>
>>>>> On the server, look at the command line options for rpc.mountd.  I'm not familiar with Ubuntu or Debian's start-up scripts, so I can't be more specific than that.
>>>>>
>>>>> Note that this is an independent issue from the mount problem, but it's incorrect and contributing to mount's misbehavior.
>>>>>
>>>>>> pd: sorry for the double email i forget press reply all
>>>>>>
>>>>>> On Mon, Feb 14, 2011 at 11:56 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>> Hi Edgar-
>>>>>>>
>>>>>>> On Feb 11, 2011, at 6:46 PM, Edgar Almonte wrote:
>>>>>>>
>>>>>>>> hmm i will try update to the last version but is the lasted in
>>>>>>>> official repository of my distro
>>>>>>>
>>>>>>> Yes, that could be a problem.  Out of curiosity, can you tell us what version of nfs-utils is running on the working Debian client you have?
>>>>>>>
>>>>>>>> the rpcinfo -p localhost output ( run at the server )
>>>>>>>>
>>>>>>>> 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
>>>>>>>>    391002    2   tcp    661  sgi_fam
>>>>>>>>    100024    1   udp  49216  status
>>>>>>>>    100024    1   tcp  42903  status
>>>>>>>>    100003    2   tcp   2049  nfs
>>>>>>>>    100003    3   tcp   2049  nfs
>>>>>>>>    100003    4   tcp   2049  nfs
>>>>>>>>    100227    2   tcp   2049  nfs_acl
>>>>>>>>    100227    3   tcp   2049  nfs_acl
>>>>>>>>    100003    2   udp   2049  nfs
>>>>>>>>    100003    3   udp   2049  nfs
>>>>>>>>    100003    4   udp   2049  nfs
>>>>>>>>    100227    2   udp   2049  nfs_acl
>>>>>>>>    100227    3   udp   2049  nfs_acl
>>>>>>>>    100021    1   udp  36092  nlockmgr
>>>>>>>>    100021    3   udp  36092  nlockmgr
>>>>>>>>    100021    4   udp  36092  nlockmgr
>>>>>>>>    100021    1   tcp  52268  nlockmgr
>>>>>>>>    100021    3   tcp  52268  nlockmgr
>>>>>>>>    100021    4   tcp  52268  nlockmgr
>>>>>>>>    100005    3   udp  41849  mountd
>>>>>>>>    100005    3   tcp  46012  mountd
>>>>>>>
>>>>>>> This looks weird.  NFS is available on TCP and UDP in all three versions, but MNT is available in version 3.  I wonder if this is confusing mount.nfs.  Is there any reason why your server is configured to disable MNT version 1?
>>>>>>>
>>>>>>>> On Fri, Feb 11, 2011 at 7:27 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> On Feb 11, 2011, at 6:13 PM, Edgar Almonte wrote:
>>>>>>>>>
>>>>>>>>>> Was a ipv6 issues because i add this to the client with the problem:
>>>>>>>>>> options ipv6 disable=1
>>>>>>>>>> in /etc/modprobe.d/modprobe.conf
>>>>>>>>>> reboot and mount without using udp option work, output:
>>>>>>>>>>
>>>>>>>>>> [root@circle zen]# mount heaven.local:/STORAGE /nfs/STORAGE/ -v
>>>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 19:11:53 2011
>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41849
>>>>>>>>>>
>>>>>>>>>> and i think maybe is a bug of nfs-utils that can't handle in the
>>>>>>>>>> proper way this because a connection using ipv4 protocol exist ( even
>>>>>>>>>> it detect it )
>>>>>>>>>>
>>>>>>>>>> should i need report something like this ? or and wrong ?
>>>>>>>>>
>>>>>>>>> I swear this has been discussed and fixed already, but I can't find a specific fix in the bugzilla database or the git log.  nfs-utils 1.2.2 is at least a year old.  Can you update to the latest version and try again?
>>>>>>>>>
>>>>>>>>> Also, please report the NFS server's transport capabilities.  "rpcinfo 192.168.1.102" should work.  You may need the "-p" option.
>>>>>>>>>
>>>>>>>>>> On Fri, Feb 11, 2011 at 6:57 PM, Edgar Almonte <samudhio@gmail.com> wrote:
>>>>>>>>>>> [root@circle zen]# pacman -Qs nfs-utils
>>>>>>>>>>> local/nfs-utils 1.2.2-4 [0.69 MB]
>>>>>>>>>>>    Support programs for Network File Systems
>>>>>>>>>>> [root@circle zen]# uname -a
>>>>>>>>>>> Linux circle 2.6.36-ARCH #1 SMP PREEMPT Mon Jan 24 18:34:55 UTC 2011
>>>>>>>>>>> i686 Intel(R) Atom(TM) CPU D510 @ 1.66GHz GenuineIntel GNU/Linux
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Feb 11, 2011 at 1:40 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>>>>>> Which nfs-utils version and kernel release are you using?  What transport protocols are available from your NFS server?  It looks like only UDP.  I recall a bug fix in this area in the past year.
>>>>>>>>>>>>
>>>>>>>>>>>> On Feb 11, 2011, at 12:35 PM, Edgar Almonte wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> i get this without udp option:
>>>>>>>>>>>>>
>>>>>>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:27:33 2011
>>>>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>>>>> 'vers=4,addr=fe80::224:21ff:fe57:368d,clientaddr=::'
>>>>>>>>>>>>> mount.nfs: mount(2): Input/output error
>>>>>>>>>>>>> mount.nfs: mount system call failed
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> and with udp option:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ount: no type was given - I'll assume nfs because of the colon
>>>>>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:28:29 2011
>>>>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>>>>> 'udp,vers=4,addr=192.168.1.102,clientaddr=192.168.1.103'
>>>>>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>>>>>> mount.nfs: trying text-based options 'udp,addr=192.168.1.102'
>>>>>>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=17
>>>>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot UDP port 2049
>>>>>>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>>>>>>>>> heaven.local:/STORAGE on /nfs/STORAGE type nfs (rw,udp)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> for other distro ( debian laptop ) without the udp option:
>>>>>>>>>>>>>
>>>>>>>>>>>>> mount: no type was given - I'll assume nfs because of the colon
>>>>>>>>>>>>> mount.nfs: timeout set for Fri Feb 11 13:31:37 2011
>>>>>>>>>>>>> mount.nfs: trying text-based options
>>>>>>>>>>>>> 'vers=4,addr=192.168.1.102,clientaddr=192.168.1.107'
>>>>>>>>>>>>> mount.nfs: mount(2): No such file or directory
>>>>>>>>>>>>> mount.nfs: trying text-based options 'addr=192.168.1.102'
>>>>>>>>>>>>> mount.nfs: prog 100003, trying vers=3, prot=6
>>>>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100003 vers 3 prot TCP port 2049
>>>>>>>>>>>>> mount.nfs: prog 100005, trying vers=3, prot=17
>>>>>>>>>>>>> mount.nfs: trying 192.168.1.102 prog 100005 vers 3 prot UDP port 41044
>>>>>>>>>>>>> heaven.local:/STORAGE on /srv/nfs type nfs (rw)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> and look like is some ipv6 issues
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Feb 10, 2011 at 11:50 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Feb 9, 2011, at 7:59 PM, Edgar Almonte wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> hello list
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> like the subject say after some upgrade of my distro ( i have 2
>>>>>>>>>>>>>>> machine with the same distro and only in one happne the problem ) i
>>>>>>>>>>>>>>> can only mount nfs share using the option -o udp , without it i get
>>>>>>>>>>>>>>> this error
>>>>>>>>>>>>>>> mount.nfs: mount system call failed
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What does
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  sudo mount.nfs heaven.local:/STORAGE /nfs/STORAGE -v
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> say?  It should tell you how the mount command is negotiating with the server.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> i am using avahi-dns ( mdns ) for hostname resolve
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> command used:
>>>>>>>>>>>>>>> mount heaven.local:/STORAGE /nfs/STORAGE/
>>>>>>>>>>>>>>> check dns is work right :
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ping heaven.local
>>>>>>>>>>>>>>> PING heaven.local (192.168.1.102) 56(84) bytes of data.
>>>>>>>>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=1 ttl=64 time=0.153 ms
>>>>>>>>>>>>>>> 64 bytes from heaven.local (192.168.1.102): icmp_seq=2 ttl=64 time=0.160 ms
>>>>>>>>>>>>>>> ^C
>>>>>>>>>>>>>>> --- heaven.local ping statistics ---
>>>>>>>>>>>>>>> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
>>>>>>>>>>>>>>> rtt min/avg/max/mdev = 0.153/0.156/0.160/0.013 ms
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> anyidea what i need check for solve this issue ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>>>>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Chuck Lever
>>>>>>>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Chuck Lever
>>>>>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Chuck Lever
>>>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Chuck Lever
>>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>> --
>>>>> Chuck Lever
>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>> --
>>> Chuck Lever
>>> chuck[dot]lever[at]oracle[dot]com
>>>
>>>
>>>
>>>
>>>
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
>