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@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 > > > > > -- 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