toasters

toasters@lists.teaparty.net

2 participants
13522 discussions

network troubleshooting
by Pazder, Steve B 25 Apr '07

25 Apr '07

Hello World! Our Network admin has been working with Cisco to troubleshoot some issues (limited to 1 switch on 1 particular floor). While our Filers are not involved in this issue, fingers are generally pointed in that direction just because they exist....on the network. Our network admin is looking for information from the Filers that would be akin to a TCP dump. Ifstat, netstat and statit output are not providing the information being looked for (handshake info, etc). I haven't run across this particular issue before and don't recall ever seeing it presented to Toasters. Does anyone know of a way to get the actual communication dumps (again, a TCP dump) from a Filer? Thanks! Steve

9 10

NetApp ESX Host Utilities?
by John Sellens 24 Apr '07

24 Apr '07

There was a recent mention of "NetApp ESX Host Utilities" on the list, and (apparently) a config_mpath command included therein. I've looked on the net and on now.netapp.com and I'm having no luck in locating these tools. If someone could provide a pointer, I would be much obliged. Thanks! John jsellens(a)generalconcepts.com

2 1

Re: network troubleshooting
by Davies,Matt 24 Apr '07

24 Apr '07

Steve, Could you expand on what the problem is ? What model of Cisco switches are involved, and is qos enabled on the network ? Cheers Matt -----Original Message----- From: owner-toasters(a)mathworks.com <owner-toasters(a)mathworks.com> To: toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Tue Apr 24 17:37:53 2007 Subject: network troubleshooting Hello World! Our Network admin has been working with Cisco to troubleshoot some issues (limited to 1 switch on 1 particular floor). While our Filers are not involved in this issue, fingers are generally pointed in that direction just because they exist....on the network. Our network admin is looking for information from the Filers that would be akin to a TCP dump. Ifstat, netstat and statit output are not providing the information being looked for (handshake info, etc). I haven't run across this particular issue before and don't recall ever seeing it presented to Toasters. Does anyone know of a way to get the actual communication dumps (again, a TCP dump) from a Filer? Thanks! Steve _____________________________________________________________ This e-mail (including all attachments) is confidential and may be privileged. It is for the exclusive use of the addressee only. If you are not the addressee, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately at help(a)generalatlantic.com <mailto:help@generalatlantic.com>. Thank You.

1 0

OT: EMC mailing list
by Jeff Mery 24 Apr '07

24 Apr '07

Anyone know of an EMC mailing list? Ideally one that leans towards Clariion/CX kit? Jeff Mery - MCSE, MCP National Instruments ------------------------------------------------------------------------- "Allow me to extol the virtues of the Net Fairy, and of all the fantastic dorks that make the nice packets go from here to there. Amen." TB - Penny Arcade -------------------------------------------------------------------------

2 1

Re: inconsistent mount attributes (ro/rw), RHEL5 / Netapp]
by Gregory Baker 23 Apr '07

23 Apr '07

Trond Myklebust wrote: > On Thu, 2007-04-19 at 15:37 -0500, Gregory Baker wrote: > >> ---+ BAD RHEL 5 64 system > ... >> [root@adcgar04 mnt2]# cat /proc/mounts | grep mnt2 >> eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 nfs >> ro,vers=3,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=eng >> 0 0 > > That would be your problem right there. Is the same volume perhaps > mounted read-only somewhere else on the same client? That is no longer > allowed. > > Cheers > Trond > Ah, news to me! So if you mount a volume ro at one mount point /mnt1 and then try to mount the same volume rw at a second mount point /mnt2 you'll run into problems? Apologies, didn't catch this in release notes. --Greg ---+ A New Beginning [root@adcgar04 /]# umount -a -t nfs [root@adcgar04 /]# mount -v | grep pandora [root@adcgar04 /]# cat /proc/mounts | grep pandora [root@adcgar04 /]# mount eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 [root@adcgar04 /]# mount -v | grep pandora eng:/vol/vol4/pandora/pandora-k26_g25_64-2 on /mnt2 type nfs (rw,addr=163.181.34.137) [root@adcgar04 /]# cat /proc/mounts | grep pandora eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 nfs rw,vers=3,rsize=65536,wsize=65536,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=eng 0 0 [root@adcgar04 /]# touch /mnt2/asdf ---+ The ro Strikes Back [root@adcgar04 /]# mount -o ro eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt1 [root@adcgar04 /]# mount -o rw eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 [root@adcgar04 /]# mount -v | grep mnt eng:/vol/vol4/pandora/pandora-k26_g25_64-2 on /mnt1 type nfs (ro,addr=163.181.34.137) eng:/vol/vol4/pandora/pandora-k26_g25_64-2 on /mnt2 type nfs (rw,addr=163.181.34.137) [root@adcgar04 /]# cat /proc/mounts | grep mnt eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt1 nfs ro,vers=3,rsize=65536,wsize=65536,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=eng 0 0 eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 nfs ro,vers=3,rsize=65536,wsize=65536,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=eng 0 0 [root@adcgar04 /]# touch /mnt2/asdf touch: cannot touch `/mnt2/asdf': Read-only file system Choudhury, Bikash wrote: > There are two different things happening here. > > 1) The ro/rw rule in the filer exports file > > 2) The mount -v and cat/proc/mounts > > 1) Regarding the ro/rw rule that you have in the export file, I run a > small test in my lab. I have tried to replicate the problem with the > same rule as you have sent in your exports but I have not used the > netgroups instead used the ip subnets. I ran these tests on 7.2.2 filer. > > fas960c-svl04*> exportfs > > /vol/test_vol > -sec=sys,ro=172.17.39.0/22,rw=172.17.39.0/29,root=172.17.39.72,nosuid > > /vol/vol0/home -sec=sys,rw,nosuid > > /vol/vol0 -sec=sys,rw,anon=0,nosuid > > This is what you noticed on the Linux client: > > [root@ibmx335-svl14 mnt]# mount fas960c-svl04:/vol/test_vol /mnt/b1 > > [root@ibmx335-svl14 mnt]# ls -al > > total 20 > > drwxr-xr-x 3 root root 4096 Feb 28 03:12 . > > drwxr-xr-x 25 root root 4096 Feb 24 09:27 .. > > drwxr-xr-x 3 root root 4096 Nov 20 11:11 b1 > > [root@ibmx335-svl14 mnt]# cd /etc > > [root@ibmx335-svl14 etc]# touch /mnt/b1/testfile1 > > touch: cannot touch `/mnt/bik/testfile1': Permission denied > > On the filer I checked the permission for that file system. You can > probably run the same command on your filer to check the exact > permissions for /vol/vol4/Pandora. Replace the ip address with the one > for your RHEl5 client. > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol rw > > exportfs: 172.17.39.72 does not have rw access to /vol/test_vol (Access > reduced) > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol ro > > exportfs: 172.17.39.72 has ro access to /vol/test_vol > > > > This is definitely going to happen BECAUSE; take a look at the > /etc/exports file. The –ro is set on /22 subnet. This means 22 bits out > 32 are used as network address and the remaining 10 bits determine the > number of host i.e: 2^10. This indicates that the /22 with 255.255.252.0 > subnet has more number of clients that /29 with subnet 255.255.255.248. > When –ro is specified on a bigger network (/22) and –rw is listed with > the (/29) network, the more restricted one takes precedence, i.e ‘-ro’. > In my example the linux client had ip address 172.17.39.72 which falls > in the bigger network (/22) and is not in the (/29) network. Therefore > the client gets ‘-ro’ access instead of ‘rw’. When you try you a ‘touch’ > a file as ‘root’ from this client, you get ‘permission denied’ which is > legitimate because this client has ‘ro’ access. > > In your case you have -ro set on /vol/vol4/Pandora to every one and then > have -rw set to @volexport-pandora,root=@volexport-pandora which is part > of the wide spectrum that has '-ro' set. > > Then I switched the ‘ro’ to the (/29) network and ‘rw’ to (/22) network. > This is what it looks now. > > On the filer after the switch > > fas960c-svl04*> exportfs > > /vol/test_vol > -sec=sys,ro=172.17.39.0/29,rw=172.17.39.0/22,root=172.17.39.72,nosuid > > /vol/vol0/home -sec=sys,rw,nosuid > > /vol/vol0 -sec=sys,rw,anon=0,nosuid > > On the client after the switch: > > [root@ibmx335-svl14 etc]# touch /mnt/b1/testfile1 > > [root@ibmx335-svl14 etc]# ls -l /mnt/b1 > > total 0 > > -rw-r--r-- 1 root root 0 Feb 27 10:46 testfile1 > > > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol ro > > exportfs: 172.17.39.72 has ro access to /vol/test_vol > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol rw > > exportfs: 172.17.39.72 has rw access to /vol/test_vol > > > > Now I am able to touch the file w/o any problems. In your case > adcgar04.amd.com is part of the bigger network that has ‘ro’ access. As > suggested in the man page ‘ro’ will take precedence over ‘rw’ and > touching a file from a host in the /22 network will end up with a > ‘permission denied’. Currently this is by design. However, there is an > RFE 237892 open for this configuration to work. If you decide to upgrade > then you may consider 7.2.2 but this release does not fix this RFE. > > 2) I was currently running the above test from a RHEL5 client. But I did > not notice any difference in the mount options between 'mount -v' and > 'cat /proc/mounts'. > > [root@ibmx335-svl47 etc]# uname -a > > Linux ibmx335-svl47 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:21 EST 2007 > i686 i686 i386 GNU/Linux > > [root@ibmx335-svl47 ~]# rpm -qa |grep nfs-utils > > nfs-utils-1.0.9-16.el5 > > nfs-utils-lib-1.0.8-7.2 > > [root@ibmx335-svl47 ~]# mount -v|grep b1 > > 172.17.44.44:/vol/test_vol on /mnt/b1 type nfs4 > (*rw*,vers=4,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,retrans=3,sec=sys,addr=172.17.44.44) > > [root@ibmx335-svl47 ~]# cat /proc/mounts|grep b1 > > 172.17.44.44:/vol/test_vol /mnt/b1 nfs4* > rw*,vers=4,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,retrans=3,sec=sys,add > > Bikash R.Choudhury > > -----Original Message----- > From: Gregory Baker [mailto:gregory.baker@amd.com] > Sent: Wednesday, April 18, 2007 3:23 PM > To: toasters(a)mathworks.com > Cc: julia bauer > Subject: inconsistent mount attributes (ro/rw), RHEL5 / Netapp] > > Note I have cases open with Redhat and Netapp, but was curious if other > > people have also seen inconsistent mount attributes (ro/rw) when > > mounting RHEL5 client vs. Netapp 7.2 Ontap. > > ---+ System environment > > [greg@adcgar04 greg]$ uname -a > > Linux adcgar04 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 > > unknown unknown GNU/Linux > > [greg@adcgar04 greg]$ rpm -qa | grep nfs-utils > > nfs-utils-1.0.9-16.el5 > > nfs-utils-lib-1.0.8-7.2 > > nfs-utils-lib-devel-1.0.8-7.2 > > nfs-utils-lib-1.0.8-7.2 > > nfs-utils-lib-devel-1.0.8-7.2 > > [greg@adcgar04 greg]$ mount -V > > mount (util-linux 2.13-pre7) > > ---+ NFS server (Netapp) environment > > [greg@apathy greg]$ sudo rsh eng version > > NetApp Release 7.2P4: Tue Nov 28 02:55:54 PST 2006 > > ---++ NFS export file entry > > [greg@apathy greg]$ sudo rsh eng exportfs | grep pandora > > /vol/vol4/pandora > > -sec=sys,ro,rw=@volexport-pandora,root=@volexport-pandora,anon=4058 > > ---++ netgroup member (for export file entry above) > > [greg@apathy greg]$ show_netgroup volexport-pandora | grep adcgar > > adcgar04.amd.com > > ---+ Demonstration of inconsistent ro/rw mount reporting > > [root@adcgar04 /]# mount eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 > > [root@adcgar04 /]# mount -v | grep mnt2 > > eng:/vol/vol4/pandora/pandora-k26_g25_64-2 on /mnt2 type nfs > > (rw,addr=163.181.34.137) > > [root@adcgar04 /]# cat /proc/mounts | grep mnt2 > > eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 nfs > > ro,vers=3,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=eng > > > 0 0 > > [root@adcgar04 /]# cd /mnt2/ > > [root@adcgar04 mnt2]# touch asdf > > touch: cannot touch `asdf': Read-only file system > > ---+ Discussion > > ---++Linux (RHEL3/4) NFS servers that have similiar exportfs options > > /tmp *(ro,anonuid=4058) @volexport-pandora(rw,no_root_squash) > > do not cause the inconsistent behavior between mount -v and /proc/mounts > > (and it is mounted rw as expected on the client). > > ---++ A reply from NetApp had this info: > > Starting with ONTAP 7.2.1 onward, ONTAP will display the "most > > pessimistic" permissions to NFSv3 and NFSv4 clients. NFSv2 clients will > > see permissions the same way as in previous releases of ONTAP, i.e. the > > "most optimistic" permissions. > > And mounting using NFS v2 (instead of v3) does give us the expected > > rw/rw consistency and ability. > > ---++ So now what? > > Should the linux mount -v and cat /proc/mounts be consistent with what > > is actually happening? > > Should netapp exports syntax handle a wildcard ro and a netgroup rw? > > Comments and feedback welcome. > > Thanks, > > --Greg > > -- > > ---------------------------------------------------------------------- > > Greg Baker 512-602-3287 (work) > > gregory.baker(a)amd.com 512-602-6970 (fax) > > 5204 E. Ben White Blvd MS 625 512-555-1212 (info) > > Austin, TX 78741 > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > NFS maillist - NFS(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nfs > > > -- > > ---------------------------------------------------------------------- > > Greg Baker 512-602-3287 (work) > > gregory.baker(a)amd.com 512-602-6970 (fax) > > 5204 E. Ben White Blvd MS 625 512-555-1212 (info) > > Austin, TX 78741 > -- ---------------------------------------------------------------------- Greg Baker 512-602-3287 (work) gregory.baker(a)amd.com 512-602-6970 (fax) 5204 E. Ben White Blvd MS 625 512-555-1212 (info) Austin, TX 78741

1 1

ndmpcopy and the newb Part II
by Brian Dunbar 20 Apr '07

20 Apr '07

Me again. When last we met I had a question about ndmpcopy - the copy went over well - files moved, the application that needs those files had a brief outage and all is well. I'm cleaning up the source volume - 'best practice' here is to remove files, remove snapshots and shrink the volume to 10g should we need a place to stash files. Removed the files, done. Removed the snapshots, done. Except for one guy that is being stubborn. The fellow with just a bit more experience with these than I do claims it must be because a server is still has that volume mounted and if I showmount that appears to be the case .. except the remote host in question no longer has that mounted - going by 'df -k' and /etc/vfstab. Now - a very long time ago - back in November of 06 - this volume was cloned and mounted so that an application under development could see the contents of the file store there. Is there something special - clearly there might be - about clones and mirrors that require an extra effort to delete a snapshot? Or am I doing something fundamentally wrong? I would not ordinarily go the newb well twice in a fortnight but I've been looking at this since early this morning and I'm no closer to figuring out WHY than when I started. Thanks. HOST:/:# rsh co-dsk-007 snap list aprod4 Volume aprod4 working... %/used %/total date name ---------- ---------- ------------ -------- 28% (28%) 0% ( 0%) Nov 16 15:30 clone_aprod4_cln_aglif.1 (busy,vclone) "Busy? Surely the OS isn't going to let me blow away something that is marked as busy .." HOST:/:# rsh co-dsk-007 snap delete aprod4 clone_aprod4_cln_aglif.1 Snapshot clone_aprod4_cln_aglif.1 is busy because of "How bout that. What about the nfs mounts?" LOCALHOST:/sbin:showmount -a co-dsk-007 | grep aprod4 206.209.246.192:/vol/aprod4 co-ap-103v.plexus.com:/vol/aprod4 co-ap-930v.plexus.com:/vol/aprod4_cln_aglifs "Both hosts have been vi /etc/vfstab 'd and umounted and even rebooted to death at this point .." Brian Dunbar Systems Administrator II Plexus brian.dunbar(a)plexus.com Desk: (920) 751-3364 Cell: (920) 716-2027

3 5

FAS3020 + FC LTO Gen 3.
by Ken Williams 20 Apr '07

20 Apr '07

Toasters! I have been trying for a couple weeks now to get my 3020 to properly see an LTO Gen 3 FC Tape drive. Environment: FAS3020, attached to Cisco MDS Fabric with ISL between two MDS9509s attached to HP Ultrium 3 LTO3 Drive. The LTO3 drive is installed in a StorageTek L700 Library which fiber channel robotic control. The backup environment is Symantec Netbackup. There is no extra HBA cards in the FAS3020, so we are using the onboard card. The Good: I can manually load a tape, the Filer sees the drive/tape. The Bad: The system always reports back that the tape is a LTO1 200GB read only. Naturally I tried several other tape drives and tape media, all with the same problem. I have 2 FAS940s that do not have any issue talking to LTO3 Tape drives. I've downloaded the latest device configuration files from now, I've been working with the technical support at netapp. My best assumption is that the drives are in the wrong block mode. Has anyone seen anything like this? __________________________________________________________ Ken Williams Storage Administrator, Business Technology Operations Sacramento Municipal Utility District E-Mail: kwillia(a)smud.org Phone: (916) 732-6744 Cell: (916) 240-4213

4 5

Add two disks to an aggregate and reallocate
by Willeke, Jochen 20 Apr '07

20 Apr '07

Hi toasters, can we rise aggr-size from e.g. 14 to 16 add two disks and do an reallocate without having to much performance impact because of "hot-disks"?!?! Has anybody made experiences with this? rdgs Jochen

1 0

Re: inconsistent mount attributes (ro/rw), RHEL5 / Netapp]
by Gregory Baker 19 Apr '07

19 Apr '07

It becomes more interesting (well, to me anyways) when you compare the behavior of RHEL3/4 (ro,rw netgroup export from filer works) with RHEL 5 (ro,rw netgroup export from filer no works). ---+ System environment [root@build-el3-64 greg]# uname -a Linux build-el3-64 2.4.21-47.ELsmp #1 SMP Wed Jul 5 20:30:30 EDT 2006 x86_64 unknown unknown GNU/Linux [root@build-el3-64 greg]# rpm -qa | grep nfs-utils nfs-utils-1.0.6-44EL [root@build-el3-64 mnt2]# mount -V mount: mount-2.11y ---+ NFS server (Netapp) environment [greg@apathy greg]$ sudo rsh eng version NetApp Release 7.2P4: Tue Nov 28 02:55:54 PST 2006 ---++ NFS export file entry [greg@apathy greg]$ sudo rsh eng exportfs | grep pandora /vol/vol4/pandora -sec=sys,ro,rw=@volexport-pandora,root=@volexport-pandora,anon=4058 ---++ netgroup member (for export file entry above) [root@build-el3-64 mnt2]# show_netgroup volexport-pandora | grep build-el3-64 build-el3-64.amd.com ---+ Demonstration of ro/rw mount reporting and working [root@build-el3-64 greg]# mount eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 [root@build-el3-64 greg]# mount -v | grep mnt2 eng:/vol/vol4/pandora/pandora-k26_g25_64-2 on /mnt2 type nfs (rw,addr=163.181.34 .137) [root@build-el3-64 greg]# cat /proc/mounts | grep mnt2 eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 nfs rw,v3,rsize=32768,wsize=327 68,hard,udp,lock,addr=eng 0 0 [root@build-el3-64 greg]# cd /mnt2 [root@build-el3-64 mnt2]# touch asdf [root@build-el3-64 mnt2]# ls -la asdf -rw-r--r-- 1 root root 0 Apr 19 13:18 asdf Ideas? Thanks, --Greg Choudhury, Bikash wrote: > There are two different things happening here. > > 1) The ro/rw rule in the filer exports file > > 2) The mount -v and cat/proc/mounts > > 1) Regarding the ro/rw rule that you have in the export file, I run a > small test in my lab. I have tried to replicate the problem with the > same rule as you have sent in your exports but I have not used the > netgroups instead used the ip subnets. I ran these tests on 7.2.2 filer. > > fas960c-svl04*> exportfs > > /vol/test_vol > -sec=sys,ro=172.17.39.0/22,rw=172.17.39.0/29,root=172.17.39.72,nosuid > > /vol/vol0/home -sec=sys,rw,nosuid > > /vol/vol0 -sec=sys,rw,anon=0,nosuid > > This is what you noticed on the Linux client: > > [root@ibmx335-svl14 mnt]# mount fas960c-svl04:/vol/test_vol /mnt/b1 > > [root@ibmx335-svl14 mnt]# ls -al > > total 20 > > drwxr-xr-x 3 root root 4096 Feb 28 03:12 . > > drwxr-xr-x 25 root root 4096 Feb 24 09:27 .. > > drwxr-xr-x 3 root root 4096 Nov 20 11:11 b1 > > [root@ibmx335-svl14 mnt]# cd /etc > > [root@ibmx335-svl14 etc]# touch /mnt/b1/testfile1 > > touch: cannot touch `/mnt/bik/testfile1': Permission denied > > On the filer I checked the permission for that file system. You can > probably run the same command on your filer to check the exact > permissions for /vol/vol4/Pandora. Replace the ip address with the one > for your RHEl5 client. > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol rw > > exportfs: 172.17.39.72 does not have rw access to /vol/test_vol (Access > reduced) > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol ro > > exportfs: 172.17.39.72 has ro access to /vol/test_vol > > > > This is definitely going to happen BECAUSE; take a look at the > /etc/exports file. The –ro is set on /22 subnet. This means 22 bits out > 32 are used as network address and the remaining 10 bits determine the > number of host i.e: 2^10. This indicates that the /22 with 255.255.252.0 > subnet has more number of clients that /29 with subnet 255.255.255.248. > When –ro is specified on a bigger network (/22) and –rw is listed with > the (/29) network, the more restricted one takes precedence, i.e ‘-ro’. > In my example the linux client had ip address 172.17.39.72 which falls > in the bigger network (/22) and is not in the (/29) network. Therefore > the client gets ‘-ro’ access instead of ‘rw’. When you try you a ‘touch’ > a file as ‘root’ from this client, you get ‘permission denied’ which is > legitimate because this client has ‘ro’ access. > > In your case you have -ro set on /vol/vol4/Pandora to every one and then > have -rw set to @volexport-pandora,root=@volexport-pandora which is part > of the wide spectrum that has '-ro' set. > > Then I switched the ‘ro’ to the (/29) network and ‘rw’ to (/22) network. > This is what it looks now. > > On the filer after the switch > > fas960c-svl04*> exportfs > > /vol/test_vol > -sec=sys,ro=172.17.39.0/29,rw=172.17.39.0/22,root=172.17.39.72,nosuid > > /vol/vol0/home -sec=sys,rw,nosuid > > /vol/vol0 -sec=sys,rw,anon=0,nosuid > > On the client after the switch: > > [root@ibmx335-svl14 etc]# touch /mnt/b1/testfile1 > > [root@ibmx335-svl14 etc]# ls -l /mnt/b1 > > total 0 > > -rw-r--r-- 1 root root 0 Feb 27 10:46 testfile1 > > > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol ro > > exportfs: 172.17.39.72 has ro access to /vol/test_vol > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol rw > > exportfs: 172.17.39.72 has rw access to /vol/test_vol > > > > Now I am able to touch the file w/o any problems. In your case > adcgar04.amd.com is part of the bigger network that has ‘ro’ access. As > suggested in the man page ‘ro’ will take precedence over ‘rw’ and > touching a file from a host in the /22 network will end up with a > ‘permission denied’. Currently this is by design. However, there is an > RFE 237892 open for this configuration to work. If you decide to upgrade > then you may consider 7.2.2 but this release does not fix this RFE. > > 2) I was currently running the above test from a RHEL5 client. But I did > not notice any difference in the mount options between 'mount -v' and > 'cat /proc/mounts'. > > [root@ibmx335-svl47 etc]# uname -a > > Linux ibmx335-svl47 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:21 EST 2007 > i686 i686 i386 GNU/Linux > > [root@ibmx335-svl47 ~]# rpm -qa |grep nfs-utils > > nfs-utils-1.0.9-16.el5 > > nfs-utils-lib-1.0.8-7.2 > > [root@ibmx335-svl47 ~]# mount -v|grep b1 > > 172.17.44.44:/vol/test_vol on /mnt/b1 type nfs4 > (*rw*,vers=4,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,retrans=3,sec=sys,addr=172.17.44.44) > > [root@ibmx335-svl47 ~]# cat /proc/mounts|grep b1 > > 172.17.44.44:/vol/test_vol /mnt/b1 nfs4* > rw*,vers=4,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,retrans=3,sec=sys,add > > Bikash R.Choudhury > > -----Original Message----- > From: Gregory Baker [mailto:gregory.baker@amd.com] > Sent: Wednesday, April 18, 2007 3:23 PM > To: toasters(a)mathworks.com > Cc: julia bauer > Subject: inconsistent mount attributes (ro/rw), RHEL5 / Netapp] > > Note I have cases open with Redhat and Netapp, but was curious if other > > people have also seen inconsistent mount attributes (ro/rw) when > > mounting RHEL5 client vs. Netapp 7.2 Ontap. > > ---+ System environment > > [greg@adcgar04 greg]$ uname -a > > Linux adcgar04 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 > > unknown unknown GNU/Linux > > [greg@adcgar04 greg]$ rpm -qa | grep nfs-utils > > nfs-utils-1.0.9-16.el5 > > nfs-utils-lib-1.0.8-7.2 > > nfs-utils-lib-devel-1.0.8-7.2 > > nfs-utils-lib-1.0.8-7.2 > > nfs-utils-lib-devel-1.0.8-7.2 > > [greg@adcgar04 greg]$ mount -V > > mount (util-linux 2.13-pre7) > > ---+ NFS server (Netapp) environment > > [greg@apathy greg]$ sudo rsh eng version > > NetApp Release 7.2P4: Tue Nov 28 02:55:54 PST 2006 > > ---++ NFS export file entry > > [greg@apathy greg]$ sudo rsh eng exportfs | grep pandora > > /vol/vol4/pandora > > -sec=sys,ro,rw=@volexport-pandora,root=@volexport-pandora,anon=4058 > > ---++ netgroup member (for export file entry above) > > [greg@apathy greg]$ show_netgroup volexport-pandora | grep adcgar > > adcgar04.amd.com > > ---+ Demonstration of inconsistent ro/rw mount reporting > > [root@adcgar04 /]# mount eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 > > [root@adcgar04 /]# mount -v | grep mnt2 > > eng:/vol/vol4/pandora/pandora-k26_g25_64-2 on /mnt2 type nfs > > (rw,addr=163.181.34.137) > > [root@adcgar04 /]# cat /proc/mounts | grep mnt2 > > eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 nfs > > ro,vers=3,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=eng > > > 0 0 > > [root@adcgar04 /]# cd /mnt2/ > > [root@adcgar04 mnt2]# touch asdf > > touch: cannot touch `asdf': Read-only file system > > ---+ Discussion > > ---++Linux (RHEL3/4) NFS servers that have similiar exportfs options > > /tmp *(ro,anonuid=4058) @volexport-pandora(rw,no_root_squash) > > do not cause the inconsistent behavior between mount -v and /proc/mounts > > (and it is mounted rw as expected on the client). > > ---++ A reply from NetApp had this info: > > Starting with ONTAP 7.2.1 onward, ONTAP will display the "most > > pessimistic" permissions to NFSv3 and NFSv4 clients. NFSv2 clients will > > see permissions the same way as in previous releases of ONTAP, i.e. the > > "most optimistic" permissions. > > And mounting using NFS v2 (instead of v3) does give us the expected > > rw/rw consistency and ability. > > ---++ So now what? > > Should the linux mount -v and cat /proc/mounts be consistent with what > > is actually happening? > > Should netapp exports syntax handle a wildcard ro and a netgroup rw? > > Comments and feedback welcome. > > Thanks, > > --Greg > > -- > > ---------------------------------------------------------------------- > > Greg Baker 512-602-3287 (work) > > gregory.baker(a)amd.com 512-602-6970 (fax) > > 5204 E. Ben White Blvd MS 625 512-555-1212 (info) > > Austin, TX 78741 > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > NFS maillist - NFS(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nfs > > > -- > > ---------------------------------------------------------------------- > > Greg Baker 512-602-3287 (work) > > gregory.baker(a)amd.com 512-602-6970 (fax) > > 5204 E. Ben White Blvd MS 625 512-555-1212 (info) > > Austin, TX 78741 > -- ---------------------------------------------------------------------- Greg Baker 512-602-3287 (work) gregory.baker(a)amd.com 512-602-6970 (fax) 5204 E. Ben White Blvd MS 625 512-555-1212 (info) Austin, TX 78741

1 0

inconsistent mount attributes (ro/rw), RHEL5 / Netapp]
by Gregory Baker 19 Apr '07

19 Apr '07

Note I have cases open with Redhat and Netapp, but was curious if other people have also seen inconsistent mount attributes (ro/rw) when mounting RHEL5 client vs. Netapp 7.2 Ontap. ---+ System environment [greg@adcgar04 greg]$ uname -a Linux adcgar04 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64 unknown unknown GNU/Linux [greg@adcgar04 greg]$ rpm -qa | grep nfs-utils nfs-utils-1.0.9-16.el5 nfs-utils-lib-1.0.8-7.2 nfs-utils-lib-devel-1.0.8-7.2 nfs-utils-lib-1.0.8-7.2 nfs-utils-lib-devel-1.0.8-7.2 [greg@adcgar04 greg]$ mount -V mount (util-linux 2.13-pre7) ---+ NFS server (Netapp) environment [greg@apathy greg]$ sudo rsh eng version NetApp Release 7.2P4: Tue Nov 28 02:55:54 PST 2006 ---++ NFS export file entry [greg@apathy greg]$ sudo rsh eng exportfs | grep pandora /vol/vol4/pandora -sec=sys,ro,rw=@volexport-pandora,root=@volexport-pandora,anon=4058 ---++ netgroup member (for export file entry above) [greg@apathy greg]$ show_netgroup volexport-pandora | grep adcgar adcgar04.amd.com ---+ Demonstration of inconsistent ro/rw mount reporting [root@adcgar04 /]# mount eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 [root@adcgar04 /]# mount -v | grep mnt2 eng:/vol/vol4/pandora/pandora-k26_g25_64-2 on /mnt2 type nfs (rw,addr=163.181.34.137) [root@adcgar04 /]# cat /proc/mounts | grep mnt2 eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 nfs ro,vers=3,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=eng 0 0 [root@adcgar04 /]# cd /mnt2/ [root@adcgar04 mnt2]# touch asdf touch: cannot touch `asdf': Read-only file system ---+ Discussion ---++Linux (RHEL3/4) NFS servers that have similiar exportfs options /tmp *(ro,anonuid=4058) @volexport-pandora(rw,no_root_squash) do not cause the inconsistent behavior between mount -v and /proc/mounts (and it is mounted rw as expected on the client). ---++ A reply from NetApp had this info: Starting with ONTAP 7.2.1 onward, ONTAP will display the "most pessimistic" permissions to NFSv3 and NFSv4 clients. NFSv2 clients will see permissions the same way as in previous releases of ONTAP, i.e. the "most optimistic" permissions. And mounting using NFS v2 (instead of v3) does give us the expected rw/rw consistency and ability. ---++ So now what? Should the linux mount -v and cat /proc/mounts be consistent with what is actually happening? Should netapp exports syntax handle a wildcard ro and a netgroup rw? Comments and feedback welcome. Thanks, --Greg -- ---------------------------------------------------------------------- Greg Baker 512-602-3287 (work) gregory.baker(a)amd.com 512-602-6970 (fax) 5204 E. Ben White Blvd MS 625 512-555-1212 (info) Austin, TX 78741 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ NFS maillist - NFS(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs -- ---------------------------------------------------------------------- Greg Baker 512-602-3287 (work) gregory.baker(a)amd.com 512-602-6970 (fax) 5204 E. Ben White Blvd MS 625 512-555-1212 (info) Austin, TX 78741

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters