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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx >>>>>>>>>>>>>>> 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 > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
