From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050226 Firefox/1.0.1 Description of problem: When trying to export a Veritas Filesystem (SF 4.1.00) via NFS on a 32Bit i386 kernel, mounting works fine (MOUNTD) but nfsd does not answer at all. Exporting other filesystem types like ext3, reiserfs and so on works as expected. This might be a VxFS problem and not a knfsd one since the same problem seems to exist in Suse SLES 9.0. Further analysis of the problem seems to be difficult. Enabling nfsd debugging up to 0x7fff did reveal: Nov 28 18:23:54 veritas kernel: nfsd: FSINFO(3) 12: 00030001 0ff0c7fe 00000002 00000000 00000000 00000000 Nov 28 18:23:54 veritas kernel: nfsd: fh_verify(12: 00030001 0ff0c7fe 00000002 00000000 00000000 00000000) Nov 28 18:23:54 veritas kernel: Want update, refage=120, age=0 Nov 28 18:23:54 veritas kernel: exp_find_key: cache_check failed: -11 Nov 28 18:23:54 veritas kernel: nfsd: fh_verify failed: nfserr_dropit Nov 28 18:23:54 veritas kernel: nfsd: Dropping request due to malloc failure! Although after reading nfsfh.c I doubt very much its a malloc problem here. Just if it might be helpfull some more debug output: Nov 28 18:23:50 veritas rpc.mountd: authenticated mount request from fidji.sitb.de:877 for /testvol (/testvol) Nov 28 18:23:50 veritas kernel: svc: socket e0e04080 served by daemon c16e3600 Nov 28 18:23:50 veritas kernel: svc: got len=0 Nov 28 18:23:50 veritas kernel: svc: socket e0e04080 busy, not enqueued Nov 28 18:23:50 veritas kernel: svc: server c16e2200 waiting for data (to = 3600000) Nov 28 18:23:50 veritas kernel: svc: server c16e3a00, socket d4bd6080, inuse=1 Nov 28 18:23:50 veritas kernel: svc: tcp_recv d4bd6080 data 1 conn 0 close 0 Nov 28 18:23:50 veritas kernel: svc: socket d4bd6080 recvfrom(d4bd60f0, 0) = 4 Nov 28 18:23:50 veritas kernel: svc: TCP record, 40 bytes Nov 28 18:23:50 veritas kernel: svc: socket d4bd6080 recvfrom(d4bca028, 4056) = 40 Nov 28 18:23:50 veritas kernel: svc: TCP complete record (40 bytes) Nov 28 18:23:50 veritas kernel: svc: socket d84c2580 served by daemon c16e2200 Nov 28 18:23:50 veritas kernel: svc: got len=40 Nov 28 18:23:50 veritas kernel: svc: svc_authenticate (0) Nov 28 18:23:50 veritas kernel: svc: svc_authenticate: accept 0xe91186fe: status 5 Nov 28 18:23:50 veritas kernel: svc: socket d84c2580 busy, not enqueued Nov 28 18:23:50 veritas kernel: svc: calling dispatcher Nov 28 18:23:50 veritas kernel: nfsd_dispatch: vers 3 proc 0 Nov 28 18:23:50 veritas kernel: svc: socket d4bd6080 sendto([d4bcc000 28... ], 28) = 28 (addr 420d1fac) Nov 28 18:23:50 veritas kernel: svc: socket d84c2580 busy, not enqueued Nov 28 18:23:50 veritas kernel: svc: server c16e3a00 waiting for data (to = 3600000) Nov 28 18:23:50 veritas kernel: svc: server c16e3600, socket d4bd6380, inuse=1 Nov 28 18:23:50 veritas kernel: svc: tcp_recv d4bd6380 data 0 conn 1 close 0 Nov 28 18:23:50 veritas kernel: svc: tcp_accept d4bd6380 sock d440dd80 Nov 28 18:23:50 veritas kernel: svc: tcp_accept e7784580 allocated Nov 28 18:23:50 veritas kernel: svc: got len=0 Nov 28 18:23:50 veritas kernel: svc: server c16e3600 waiting for data (to = 3600000) Nov 28 18:23:50 veritas kernel: svc: socket d84c2580 TCP (connected) state change 8 (svsk d4bd6080) Nov 28 18:23:50 veritas kernel: svc: socket d84c2580 busy, not enqueued Nov 28 18:23:50 veritas kernel: svc: socket d84c2580 TCP data ready (svsk d4bd6080) Nov 28 18:23:50 veritas kernel: svc: socket d84c2580 busy, not enqueued Nov 28 18:23:50 veritas kernel: svc: server c16e2200, socket d4bd6080, inuse=1 Nov 28 18:23:50 veritas kernel: svc: tcp_recv d4bd6080 data 1 conn 0 close 1 Nov 28 18:23:50 veritas kernel: svc: svc_delete_socket(d4bd6080) Nov 28 18:23:50 veritas kernel: svc: server socket destroy delayed Nov 28 18:23:50 veritas kernel: svc: got len=0 Nov 28 18:23:50 veritas kernel: svc: releasing dead socket Nov 28 18:23:50 veritas kernel: svc: server c16e2200 waiting for data (to = 3600000) Nov 28 18:23:50 veritas kernel: nfsd: exp_rootfh(/testvol [e2497588] *:VxVM65534/2) Nov 28 18:23:50 veritas kernel: nfsd: fh_compose(exp c7:fffe/2 ///, ino=2) Version-Release number of selected component (if applicable): kernel-2.6.9-22.EL, SF 4.1.00.10-GA_RHEL4 How reproducible: Always Steps to Reproduce: 1. Install Veritas Storage Foundation 4.1.00 2. Create a VxVM Volume and export it via NFS 3. Try to mount this volume from a remote machine Actual Results: nfsd did not answer to FSINFO call, client retransmits call over and over Expected Results: nfsd should answer FSINFO and all other calls or at least should drop an error back to the client. Additional info: What has been the clue behind http://support.veritas.com/docs/243789 ?
Solution (thanks to Miguel from Veritas/Symantec Support): This is basicaly a duplicate of #143897 and a documentation problem. Deep down in the SF 4.1 Release Notes there is something about: NFS Cannot Handle Minor Numbers Greater Than 255 > > The NFS implementation in Linux does not support minor numbers greater > than 255 (see the description of Red HAT Bugzilla Bug 143897 or SUSE > Bugzilla Bug 49552 for details). As a result, volume devices with large > minor numbers cannot be remotely mounted via NFS. The workaround is to > use the vxdg command to change the base minor number of the disk group > that contains the volumes. Which I red (of course). What this note does not state is, that VxVM uses high minor numbers by default. So mine was 65534: [root@veritas ~]# ls -l /dev/vx/dsk/testdg/testvol brw------- 1 root root 199, 65534 Nov 28 15:12 /dev/vx/dsk/testdg/testvol doing: [root@veritas ~]# umount /testvol [root@veritas ~]# vxdg -g testdg reminor 100 [root@veritas ~]# ls -l /dev/vx/dsk/testdg/ total 0 brw------- 1 root root 199, 100 Nov 30 16:05 testvol [root@veritas ~]# mount /testvol resolved the problem: [root@fidji ~]# df -k /mnt/t Filesystem 1K-blocks Used Available Use% Mounted on veritas:/testvol 12582912 95008 12172608 1% /mnt/t So this needs to be stated more clearly in the Release Notes. And maybe this limitation should be removed from knfsd, or at least the error messages should be changed to reveal a clear clue of the underlying problem.
*** This bug has been marked as a duplicate of 143897 ***