Do you have the log? If not, could you re-run the gluster nfs server process with TRACE log level and send it to me?
I set up NFS with the following config: volume nfsxlator type nfs/server subvolumes se # option rpc-auth.auth-unix off #Enabled by default # option rpc-auth.auth-null off #Enabled by default # By default all addresses are rejected until allowed. # option rpc-auth.addr.reject 127.* # option rpc-auth.addr.allow localhost option rpc-auth.addr.se.allow * option rpc-auth.addr.namelookup off # By default insecure ports are not allowed. # option rpc-auth.ports.insecure on option rpc-auth.ports.se.insecure on # By default all access is read-write. # option nfs3.<volume>.volume-access read-only # option nfs3.<volume>.volume-access read-only # option nfs3.read-size 128Kb # option nfs3.write-size 32Kb # option nfs3.readdir-size 64Kb # option nfs3.<volume>.read-size 64Kb # option nfs3.<volume>.write-size 64Kb # option nfs3.posix1.readdir-size 128Kb end-volume I can mount this to a Linux system, but when I try to mount it to a Windows 7 via NFS I get: Network Error - 53 Which is: The network path was not found I am able to mount regular uNFS just fine...
Created attachment 313
I attached a TRACE log created using the following steps: 1. Started glusterfs with trace. 2. Attempted to mount the FS using NFS on my Win7 system using the command: mount 10.1.10.15:/test x: 3. I killed the glusterfs process to keep the log file down. I received the same results. Just a note about this particular system, if I create a regular directory called /test and export it using knfs, it works fine. If the Gluster volume is mounted at /test and I try to export that usinf knfs it fails with the same message.
gnfs is receiving the NFS requests from windows 7 client alright. There are a couple of things that could be happening. o The log contains errors like "Transport endpoint is not connected" for brick5-1. glusterfsd must not be running on that node. o Use nfs beta rc14, it has fixes that will report errors through showmount when a distribute's subvolume hasnt connected. This will help avoid the problem above where nfs starts even though a brick wasnt online. o If this still doesnt fix it, lets try doing what we did here in Blr last time around. Install tcpdump on the windows 7 machine. Then, in one command window, run the following command: tcpdump -s 0 -w mount.dump In another window, run the mount command. Send me the mount.dump file. It will tell me what network request was being sent by the windows machine and why it fails.
So, I created a gnfs share using rc14. I can mount it to the Windows system. I get all sorts of errors and then it crashed when I umount it: [2010-09-24 10:09:46] E [nfs3.c:4311:nfs3svc_fsinfo] nfs-nfsv3: Error decoding arguments [2010-09-24 10:09:46] E [nfs3.c:4170:nfs3svc_fsstat] nfs-nfsv3: Error decoding args [2010-09-24 10:09:46] E [rpcsvc.c:1243:rpcsvc_program_actor] rpc-service: RPC program version not available [2010-09-24 10:09:46] E [rpcsvc.c:1243:rpcsvc_program_actor] rpc-service: RPC program version not available [2010-09-24 10:09:46] E [nfs3.c:1092:nfs3svc_lookup] nfs-nfsv3: Error decoding args [2010-09-24 10:09:46] E [nfs3.c:1092:nfs3svc_lookup] nfs-nfsv3: Error decoding args [2010-09-24 10:09:46] E [nfs3.c:1092:nfs3svc_lookup] nfs-nfsv3: Error decoding args [2010-09-24 10:10:10] E [nfs3.c:4311:nfs3svc_fsinfo] nfs-nfsv3: Error decoding arguments [2010-09-24 10:10:10] E [nfs3.c:4170:nfs3svc_fsstat] nfs-nfsv3: Error decoding args [2010-09-24 10:10:10] E [rpcsvc.c:1243:rpcsvc_program_actor] rpc-service: RPC program version not available [2010-09-24 10:10:10] E [rpcsvc.c:1243:rpcsvc_program_actor] rpc-service: RPC program version not available pending frames: patchset: v3.0.0-274-g599f77b signal received: 11 time of crash: 2010-09-24 10:11:28 configuration details: argp 1 backtrace 1 dlfcn 1 fdatasync 1 libpthread 1 llistxattr 1 setfsid 1 spinlock 1 epoll.h 1 xattr.h 1 st_atim.tv_nsec 1 package-string: glusterfs nfs_beta_rc14 /lib64/libc.so.6[0x333a6302d0] /usr/lib64/glusterfs/nfs_beta_rc14/xlator/nfs/server.so(__mnt3svc_umountall+0x53)[0x2ae2d4b8c903] /usr/lib64/glusterfs/nfs_beta_rc14/xlator/nfs/server.so(mnt3svc_umountall+0x35)[0x2ae2d4b8c955] /usr/lib64/glusterfs/nfs_beta_rc14/xlator/nfs/server.so(mnt3svc_umntall+0x2d)[0x2ae2d4b8c9ad] /usr/lib64/libglrpcsvc.so.0(rpcsvc_handle_rpc_call+0x9b)[0x2ae2d4dcacdb] /usr/lib64/libglrpcsvc.so.0(rpcsvc_record_update_state+0xcf)[0x2ae2d4dcadbf] /usr/lib64/libglrpcsvc.so.0(rpcsvc_conn_data_handler+0x78)[0x2ae2d4dcb088] /usr/lib64/libglusterfs.so.0[0x2ae2d3885615] /usr/lib64/libglrpcsvc.so.0(rpcsvc_stage_proc+0x12)[0x2ae2d4dc9672] /lib64/libpthread.so.0[0x333ae0673d] /lib64/libc.so.6(clone+0x6d)[0x333a6d3d1d] ---------
(In reply to comment #5) > So, I created a gnfs share using rc14. I can mount it to the Windows system. > I get all sorts of errors and then it crashed when I umount it: > Two problems here: > [2010-09-24 10:09:46] E [nfs3.c:4311:nfs3svc_fsinfo] nfs-nfsv3: Error decoding > arguments Why is gnfs not able to decode messages coming from the client? > /usr/lib64/glusterfs/nfs_beta_rc14/xlator/nfs/server.so(mnt3svc_umountall+0x35)[0x2ae2d4b8c955] "unmount all" request was never tested because with linux there is no way to generate this request from the umount command. I could really use the tcpdump trace to figure out what bytes we're receiving on the wire.
What command should I be using to collect this for you? The environment has been disabled and I already told the customer it doesn't work, so I would have to rebuild it. It was very easily reproducible from any Windows system(7, 2008) to any Gluster NFS server.
(In reply to comment #7) > What command should I be using to collect this for you? The environment has > been disabled and I already told the customer it doesn't work, so I would have > to rebuild it. It was very easily reproducible from any Windows system(7, > 2008) to any Gluster NFS server. yeah, no problems. This is not hard to reproduce here. Thanks.
heres whats going on: Windows client has a very short timeout for the mount request. so either because my machine's disk is not responding fast enough or the name server is not replying to gnfs fast enough, the replies from gnfs to windows nfs client are being sent after the timeout expires on the nfs client. After retransmitting it for a few times, the nfs client, and this is completely new behaviour for me, sends a UMNTALL request to gnfs. Because this request is sent only by windows, which hasnt been tested that well, gnfs crashes.
PATCH: http://patches.gluster.com/patch/5628 in master (mnt3: Fix UMNTALL crash with Windows clients)
Need to say that we have some issues with Window's client. Please check with Shehjar on what to update, and where.
(In reply to comment #11) > Need to say that we have some issues with Window's client. Please check with > Shehjar on what to update, and where. Just a crash in NFS. No more issues with this particular mount request from the windows client. No documentation needed.