toasters

toasters@lists.teaparty.net

13531 discussions

Re: Mulitple network cards
by Nick Hilliard 22 Mar '00

22 Mar '00

> I have several network cards on my filer, each with its own subnet - If I > am on a subnet that the cards are not defined for, how does the filer know > which subnet/card to send the information out on ? By referring to its routing table. Have you checked up on the "route" command? Nick

1 0

Mulitple network cards
by Mark D Fowle 22 Mar '00

22 Mar '00

I have several network cards on my filer, each with its own subnet - If I am on a subnet that the cards are not defined for, how does the filer know which subnet/card to send the information out on ? Mark Fowle Caterpillar/BCP

1 0

mini-core
by Graham C. Knight 22 Mar '00

22 Mar '00

Does anyone know if there is a way to have the mini-core files that are introduced in 5.3 mailed to a list *other* than my autosupport list - or to disable them being mailed at all? Thx, Graham

2 1

Re: Help with vif's
by Sam Cramer 21 Mar '00

21 Mar '00

>>>>> "Justin" == Justin <Justin.Acklin(a)sv.sc.philips.com> writes: Justin> I solved the problem which was what spawned my original question -- Justin> what to do on the Cisco side, whether it's trunking or channeling. Justin> One single line command enabled channeling, it didn't work at Justin> first, but I turned it on and let it sit for a while and it started Justin> working. The reason we had had trouble with another netapp in the Justin> past was not because we had used the incorrect commands but that Justin> the Catalyst had an older blade in it that did not support Justin> etherchannel. When etherchannel is not setup all traffic apppears Justin> to go through the last port of the vif. Now, I still need to know Justin> whether the vifs persist through reboots or whether I need to place Justin> the commands into my rc file. vifs don't persist past reboots. You need to put the commands in your /etc/rc file. Sam

1 0

Help with vif's
by Justin 21 Mar '00

21 Mar '00

Hello, We need to increase the network badnwidth to our 740. It has the bulitin ethernet port plus a quad card. The switch it's connected to is a catalyst 5500. My understanding is the vif on the Netapp is compatible with Etherchannel on the catalysts. We did the vif create on the Netapp (DOT 5.3.4r3) and combined all 4 quad card ports into one interface, it has an IP address, ifconfig shows them all as part of a virtual interface. But what do I need to do on the Cisco side? When testing this on a 520 in the past, we tried enabling etherchannel AND trunking on the ports, to no avail -- all data appears to be going through the 4th interface. vif stats <vifname> shows about 3 or 4 packets per second on e3a through e3c, and thousands through e3d. I figured that maybe it just counts the entire vif's packets on the e3d interface; is that correct? Even so, though, with heavy speed testing from multiples clients, all the data continued to go through the last port, and never broke 12 megabytes a second. I really suspect this is because we don't have the Catalyst set up properly. Can someone out there who's done this before tell me what we need to do on the cat? Do I need to put the vif commands into the rc file? Thanks in advance, Justin Acklin Oh, another thing is that almost every time we plug or unplug an ethernet port on the netapp, or even sometimes doing an ifconfig, the thing core dumps. Very annoying, apparently there is an open bug on that, which is not fixed yet according the netapp engineer I opened a case with the last time this happened.

4 3

RE: FilerView Usability Study for Bay Area NetApp Administrators (Vol unteers Wanted) ...
by Yee, Steven 21 Mar '00

21 Mar '00

ok, sorry, I've been duly chastised for my spelling and the fact that it is unclear that the study is intended for San Francisco Bay Area folks (sorry Tampa ;) guess we should never let an enginerd loose in a public forum ;) Also, we would like responses back by March 28th (Western Hemisphere) thanks again. steve. -----Original Message----- From: Yee, Steven [mailto:steven.yee@netapp.com] Sent: Tuesday, March 21, 2000 11:04 AM To: 'toasters(a)mathworks.com' Subject: FilerView Usability Study for Bay Area NetApp Administrators (Vol unteers Wanted) ... We are currently planning on conducting a series of usability studies on the latest version of FilerView and are looking for volunteers who would like to paricipate in the study. We are specifically looking for volunteers who match some or all of the following criteria: * Have managed 1 or more filers * Experienced UNIX System Administrators * Experienced Windows Administrators (primarily servers) * Have at least seen (or attempted use) previous incarnations of FilerView Due to logistical concerns study participants will be restricted to Bay Area residents at this time. The studies will be done the week of April 17, 2000. It is expected to take 1-2 hours to do the study. Chosen participants will be paid for their time. The studies will be done at Network Appliance (either at the San Tomas engineering site) Should you wish to considered for participation, we would like to know the following: ---------------------------------------------------------------------------- Name: Title: Company: Phone: Email: Filer Administration Experience (years): Number of Filers Administered: UNIX System Admininistration Experience (years): Windows System Administration Experience (years): Client Base (check one): ___ UNIX (NFS) only ___ Windows (CIFS) only ___ Mixed ---------------------------------------------------------------------------- Potential candidates will be contacted by a 3rd party research group for further follow-up and scheduling. Please email the above information to Steven Yee (sdy(a)netapp.com) or fax to my attention at 408-822-4457. Thanks, steve. -- Steven D. Yee is sdy(a)netapp.com Network Appliance 495 East Java Drive Sunnyvale CA 94089

1 0

FilerView Usability Study for Bay Area NetApp Administrators (Vol unteers Wanted) ...
by Yee, Steven 21 Mar '00

21 Mar '00

We are currently planning on conducting a series of usability studies on the latest version of FilerView and are looking for volunteers who would like to paricipate in the study. We are specifically looking for volunteers who match some or all of the following criteria: * Have managed 1 or more filers * Experienced UNIX System Administrators * Experienced Windows Administrators (primarily servers) * Have at least seen (or attempted use) previous incarnations of FilerView Due to logistical concerns study participants will be restricted to Bay Area residents at this time. The studies will be done the week of April 17, 2000. It is expected to take 1-2 hours to do the study. Chosen participants will be paid for their time. The studies will be done at Network Appliance (either at the San Tomas engineering site) Should you wish to considered for participation, we would like to know the following: ---------------------------------------------------------------------------- Name: Title: Company: Phone: Email: Filer Administration Experience (years): Number of Filers Administered: UNIX System Admininistration Experience (years): Windows System Administration Experience (years): Client Base (check one): ___ UNIX (NFS) only ___ Windows (CIFS) only ___ Mixed ---------------------------------------------------------------------------- Potential candidates will be contacted by a 3rd party research group for further follow-up and scheduling. Please email the above information to Steven Yee (sdy(a)netapp.com) or fax to my attention at 408-822-4457. Thanks, steve. -- Steven D. Yee is sdy(a)netapp.com Network Appliance 495 East Java Drive Sunnyvale CA 94089

1 0

Re: DLT recommendations
by James GRASMICK 21 Mar '00

21 Mar '00

We are currently using an ADIC DLT-7000 which works for us . WWW.ADIC.COM >>> Paul Mikulencak <paul.mikulencak(a)amd.com> 03/15/00 03:57PM >>> On Tue, 14 Mar 2000, Ethan Torretta wrote: > I need to buy a DLT device to backup a single F760 in an IS environment. > The DLT7000 devices I've found, though, are single-ended. Does anyone > have a favorite DLT7000 differential single- or multi-tape device? > I've seen people have good luck with minilibraries, but that's an > unnecessary expense in this case. I'm also curious about the DLT8000, > as I'm buying a new drive anyway. Can they be set to be compatible with > a filer? we've had good luck with storagetek 9740s (though their bigger libraries may be more than you need) running dlt7000 drives. the 8000s seem like not enough bang for the bucks you pay over the cost of a 7000. we currently use budtool, but are thinking of switching to workstation solutions. have heard interesting things re. ait, both with qualstar (sp?) and spectralogic, but haven't tested them yet. anyone have anything good or bad to say about ait/these changers? pablo email paul.mikulencak(a)amd.com ext. 602-2448 "the word pessimism bothers me pager 624-0929 because it is often used instead cube 3.277.042 of the word lucidity." robert bresson

2 1

Messages from cron_admin about daylight saving time
by Chris Thompson 21 Mar '00

21 Mar '00

We run a default raid scrub regime (01:00 on Sundays). Last Sunday we got a message Sun Mar 19 01:00:00 GMT [cron_admin]: Rescheduling raid_scrub_admin to run at Sun Mar 19 01:00:00 GMT 2000 because of Day Light Saving time change [Raid scrubbing itself ran at this time with no problem.] Moreover, every time timed tweaks the clock (we use ntp synchronisation) it again mutters. e.g. Tue Mar 21 16:04:33 GMT [cron_admin]: Rescheduling raid_scrub_admin to run at Tue Mar 21 16:04:33 GMT 2000 because of Day Light Saving time change Now all this is no doubt because next Sunday is clock-changing day in our timezone (GB), with 2000-03-26 01:00:00 GMT -> 02:00:00 BST. [American friends will no doubt be seeing this effect next week!] What I don't understand is a) Why ONTAP is making such a fuss about it. Nothing like this happened last October, but we were on 5.2.2 then, and 5.3.5 now. b) Why it always claims to be rescheduling for the current time. Maybe this is just a bungle in the message? I am expecting the messages to disappear after the clock change, but meanwhile I'm a bit bemused by it all. Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.

1 0

DLT8000 vs DLT7000 as F740 backup device
by Chris Thompson 21 Mar '00

21 Mar '00

We have an F740 (14x18GB discs), currently without a directly attached tape drive, and are looking to add the latter. Functional experiments with a loaned DLT8000 drive (actually part of an ADIC FastSTOR) and appropriate /etc/cloned_tapes ("QUANTUM DLT8000 EMULATES QUANTUM DLT7000") were satisfactory, so I have been looking around for a DLT7000 offering, preferably 19"-rack-mounted. I am getting a lot of responses from suppliers of the form "we haven't got any DLT7000s with HV differential SCSI available, why not buy a DLT8000 drive instead? It's only [anything from 0 to 300 pounds] more". Are other NetApp users using DLT8000 drives as backup devices in production situations? Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.

3 2

RE: nas storage
by Alvarado, Michael 21 Mar '00

21 Mar '00

Network Appliance's current customer experience is that they do get performance on par with local disk storage already. Our current plans do not include any interoperation with the SANenergy products. -----Original Message----- From: Yael Hellmann [mailto:yael_hellmann@yahoo.com] Sent: Monday, March 20, 2000 6:02 PM To: toasters(a)mathworks.com Subject: nas storage I am currently investigating the market for nas storage. What is netapp plans in providing a solution which will deliver local disk performance for nas storage? Does netapp have plans for products with SANergy functionality or performance? __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

2 1

nas storage
by Yael Hellmann 21 Mar '00

21 Mar '00

I am currently investigating the market for nas storage. What is netapp plans in providing a solution which will deliver local disk performance for nas storage? Does netapp have plans for products with SANergy functionality or performance? __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

1 0

NetApp backup recommendations
by Jeff Bryer 18 Mar '00

18 Mar '00

We are in the process of redesigning our backup system. Currently we have one NetApp F740, a variety of SUN servers and one Linux machine. The DLT 4700 jukeboxes we use are about at their limit for capacity so it's time to get some new, bigger, hardware. And the software we use is BudTool which we will soon lose support on when Legato EOL's it (we've been told we have support until at least Jan 1, 2001). So now I'm looking for both hardware and software recommendations. We use both CIFS and NFS on the filer. We want to back up the filer via NDMP with a direct SCSI attached jukebox (or jukeboxes) or via fibre and a Vixel switch (or equiv). We have been looking at AIT-2 which after some digging appears to work via direct connect although our NetApp rep keeps telling us it doesn't. We've been very happy with the reliability of the DLT drives/media and have been burned in the past with Exabyte 8mm. Some of us are reluctant to return to helical scan media. For the near future we'll be backing up to 500GBs of data/week. We have been receiving interest to expand the back ups to cover more systems on campus which could mean backing up to 3-5TB+ of data. Essentially we want hardware/software which has the growth potential. We're getting a second filer and for security reasons we need to keep it separate from our existing filer. We were looking at the SpectraLogic Gator library which would allow us to split the SCSI bus and dedicate specific drives to the individual filers. We'd prefer (need) to use 2 backup servers (one for the existing filer/SUNs, one for the new filer) so we need software that can support this. The 2 main choices for software seem to be Legato (NetWorker/Celestra) or Veritas (NetBackup). What about QuickRestore from WorkStation Solutions? That product has the advantage that the archives are compatible with tar (in the case of disaster recovery). Having software that we can roll our Netware backups into would be a plus. Thanks, Jeff -- Jeff Bryer bryer(a)sfu.ca Systems Administrator (604) 291-4935 Academic Computing, Simon Fraser University

3 3

RE: NetApp backup recommendations
by Roth, William 18 Mar '00

18 Mar '00

To test the scsi reset / filer reboot theory: I started a ndmp backup to a scsi attached tape / library. Once data was being written to tape, I disconnected the scsi cable. The backup aborted, and the scsi bus did reset. The filer (F760 ONTAP 5.3.5) did not reboot. The NFS and CIFS operations were not impacted. Thanks, Bill Roth -----Original Message----- From: Steve Kappel [mailto:steve.kappel@raistlin.min.ov.com] Sent: Thursday, March 16, 2000 8:04 AM To: bryer(a)sfu.ca Cc: toasters(a)mathworks.com Subject: Re: NetApp backup recommendations >> NetBackup (Veritas) can only dump to tape drives connected directly to an >> NDMP server (i.e. only to a locally-attached NetApp drive, or to a remote >> NetApp with attached tape). It cannot do NDMP backups to a "normal" >> NetBackup media server. I've been told that NetBackup can only restore >> NDMP dumps in place, too -- not to an alternate directory, for example >> (I haven't verified that with the vendor). >> >Hmm this could be deadly for us. Legato recommends direct attached >tape drives which I was preferring and it makes sense for performance. Directly attached drives are more efficient. Even with plenty of network bandwidth, backing up over the network still puts a significant CPU load on the boxes. If the filers are physically within reach, a large library can have some of its drives split off onto separate SCSI buses and one bus attached to each filer. "normal" NetBackup media servers can also have some of the drives. Robotic control can be anywhere in such a config. This is really the best of all worlds (IMHO) as you get direct attach performance on all boxes but you are sharing the library. If they are not physically within reach then 3-way backup to another filer can be used. Large sites may dedicate a NetApp as a "tape server". I believe there are library vendors that are looking at supporting NDMP directly in their libraries. >But we got discussing this issue, and the idea of the NetApp >spontaneously rebooting due to a SCSI bus error (from the tape drive) >came up. For our new NetApp we cannot afford to have this happen. >It's not so critical for our existing filer. Our existing filer runs >OnTap 5.2.1 and has rebooted once (in approx 7 months) due to a SCSI >bus error (a tape got stuck in the jukebox and the filer booted to >try to clear the error). Although with newer revs of OnTap and the >firmware, maybe this isn't an issue any more? I have never seen this with the NetApp's we have in NetBackup development. I see plenty of bus resets but never a reboot. __________________________________________________________________________ Steve Kappel steve.kappel(a)veritas.com VERITAS Software steve.kappel(a)iname.com (Personal)

4 3

Re: NetApp backup recommendations
by Steve Kappel 17 Mar '00

17 Mar '00

> I've been told that NetBackup can only restore >NDMP dumps in place, too -- not to an alternate directory, for example >(I haven't verified that with the vendor). NetBackup can restore to alternate directories. Prior to NetBackup 3.4 it cannot restore to a different NetApp box. __________________________________________________________________________ Steve Kappel steve.kappel(a)veritas.com VERITAS Software steve.kappel(a)iname.com (Personal)

2 1

RE: Problems integrating CIFS and NFS access control
by Muhlestein, Mark 17 Mar '00

17 Mar '00

The reason we change the security style in mixed qtrees is to guarantee correct semantics. A conservative security rule implies the permission you get should be _exactly_ what was set. Because it is not possible to map the settings exactly, we chose to replace the permissions entirely and change the security style in mixed qtrees. Going forward, that will continue to be the default behavior. However, we understand that not all sites require such strict security rules, so we have plans to relax this behavior under control of an option. As always, feedback on how you would like things to work is very welcome. On the names being identical: as I mentioned before, it is *not* necessary to have them identical. You can map them in the /etc/usermap.cfg file. But it makes administration easier if they are the same, because it's one less thing to manage. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Todd C. Merrill [mailto:tmerrill@mathworks.com] Sent: Friday, March 17, 2000 10:01 AM To: Paul Lupa Cc: toasters(a)mathworks.com Subject: Re: Problems integrating CIFS and NFS access control On Thu, 16 Mar 2000, Paul Lupa wrote: > I have a problem with the operation of a NetApp that servers up a share > both via CIFS and NFS. The goal of a group that I support was to have > a common directory for both the UNIX systems and the NT systems. A user We use common directories for home directories for both UNIX and NT users here. That filer uses mixed qtree security: file:/cdrom/534R3/html/sag/qtree2.htm#1164436 The behavior is exactly as you stated, and as the docs state: ========== Both NTFS and UNIX style permissions are permitted. The security style of a file is the style most recently used to set permissions on that file. See the information in "NTFS." Caution: Changing NTFS permissions on a file recomputes UNIX permissions on that file. Changing UNIX permissions or ownership on a file deletes any NTFS permissions on that file. ========== A slightly bizarre interpretation, I think. You might say there is loss of data here! ;) > My questions to the group: > > 1: Is anyone sharing the same directory under CIFS and NFS and found a > workaround or an acceptable way to implement permissions? We use the mixed style when we absolutely need data sharing *and* NT clients need to use the full ACL's (one filer). Otherwise, we use UNIX style security (four filers), which is a bit more straightforward for the admins and our users. > 2: Has anyone thought about what would be wrong with using UNIX > permissions > to determine access when using NFS and NT permissions when > using CIFS? I don't have an answer for you on this one. I don't know what is involved in having NFS/CIFS permissions behave as they do with UNIX style security for the owner and primary group owner of the file/directory, and only have the additional NT ACL's be applicable only to CIFS clients. Why *wipe* them out on the NFS/CIFS side if they are changed on the CIFS/NFS side? But, as someone else said, all this sharing only works when the usernames are *identical* via NFS and CIFS. Feel free to continue the thread or email me personally about how we implement/workaround stuff here. Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

1 0

Problems integrating CIFS and NFS access control
by Paul Lupa 17 Mar '00

17 Mar '00

Hi Folks, I have a problem with the operation of a NetApp that servers up a share both via CIFS and NFS. The goal of a group that I support was to have a common directory for both the UNIX systems and the NT systems. A user would be able to see all of their files under either UNIX or NT. The problem manifests itself because whatever was last used by the user to set access rights is what sets the security mode for the file or directory. For example, if a user accesses a directory from NT and gives himself and a NT group access to a file, from UNIX only he would have access. If from Unix he set a directory to rwxr-x---, someone in an NT group that he specifically want to grant access to would not have access. Generally speaking whatever was last used (NT or Unix) to set permissions works correctly, and the other one works, but not correctly. My questions to the group: 1: Is anyone sharing the same directory under CIFS and NFS and found a workaround or an acceptable way to implement permissions? 2: Has anyone thought about what would be wrong with using UNIX permissions to determine access when using NFS and NT permissions when using CIFS? Thanks, Paul Lupa

3 2

RE: Problems integrating CIFS and NFS access control
by Muhlestein, Mark 17 Mar '00

17 Mar '00

If you have a need for UNIX users to access files with ACLs it is not necessary for all UNIX users to have a unique NT account. You can use the "wafl.default_nt_user" to supply a default mapping. Or you can create a default mapping in the /etc/usermap.cfg file. This is all assuming 5.3 or later ONTAP, of course. Anyone using multiprotocol security on a filer should definitely consider an upgrade to a 5.3x release ASAP, since things work so much better. In particular, NFS access to files with ACLs is extremely limited in pre-5.3 releases. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: ZANGA, Michael, GCM [mailto:Michael.Zanga@gcm.com] Sent: Friday, March 17, 2000 5:38 AM To: 'Paul Lupa'; toasters(a)mathworks.com Subject: RE: Problems integrating CIFS and NFS access control What kind of security mode is the volume in question? Mixed mode can be problematic as NT rights supersede the Unix rights and basically lock a Unix user out THAT doesnt have a equivalent NT id. I would recommend using id that match on both side and not use mixed mode. I have a 200 gb volume with mixed clients and mixed mode was a problem at first. We changed the security style to Unix and all is well. -----Original Message----- From: Paul Lupa [mailto:Paul.Lupa@motorola.com] Sent: Friday, March 17, 2000 12:24 AM To: toasters(a)mathworks.com Subject: Problems integrating CIFS and NFS access control Hi Folks, I have a problem with the operation of a NetApp that servers up a share both via CIFS and NFS. The goal of a group that I support was to have a common directory for both the UNIX systems and the NT systems. A user would be able to see all of their files under either UNIX or NT. The problem manifests itself because whatever was last used by the user to set access rights is what sets the security mode for the file or directory. For example, if a user accesses a directory from NT and gives himself and a NT group access to a file, from UNIX only he would have access. If from Unix he set a directory to rwxr-x---, someone in an NT group that he specifically want to grant access to would not have access. Generally speaking whatever was last used (NT or Unix) to set permissions works correctly, and the other one works, but not correctly. My questions to the group: 1: Is anyone sharing the same directory under CIFS and NFS and found a workaround or an acceptable way to implement permissions? 2: Has anyone thought about what would be wrong with using UNIX permissions to determine access when using NFS and NT permissions when using CIFS? Thanks, Paul Lupa ********************************************************************** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. ************************************************************************

1 0

RE: Problems integrating CIFS and NFS access control
by Muhlestein, Mark 17 Mar '00

17 Mar '00

On your "root" problem: is your NT user by chance a member of BUILTIN\Administrators? If so, you may want to turn off the "wafl.nt_admin_priv_map_to_root" option. (Of course, if you do that you should make sure that you still have an administrative account mapped to "root" that you can use). See http://now.netapp.com/NOW/knowledge/docs/olio/guides/53_troubleshooting/faq. shtml#anchor1392387 (Why is the UNIX owner of files I create set to "root"?) As to the problems you had using mixed qtrees, feedback on this would be very very valuable. We have found mixed mode to be quite usable, once people understand how to put it to best use. In general, please let us know when you have problems so we can address them, either in documentation or by changing the functionality. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: johnj.sasso(a)ps.ge.com [mailto:johnj.sasso@ps.ge.com] Sent: Friday, March 17, 2000 4:48 AM To: Paul.Lupa(a)motorola.com; toasters(a)mathworks.com Subject: RE: Problems integrating CIFS and NFS access control The area that the NT and UNIX users access on the NetApp, is that a MIXED-style qtree (as opposed to an NTFS- or UNIX-style qtree)? I had many problems using MIXED-style qtrees between UNIX and NT, with the behavior being inconsistent and confusing. I ended up using a UNIX-style qtree instead, sacrificing the NT ACLs the NTFS-style qtree offers. On that note, my login name for both UNIX and NT is identical. However, when I modify and save a file via NT (e.g. through Excel, Word) in a UNIX-style qtree, the file gets saved as root, thereby preventing me from accessing the file via UNIX. Very, very annoying. --john -----Original Message----- From: Paul Lupa [mailto:Paul.Lupa@motorola.com] Sent: Friday, March 17, 2000 12:24 AM To: toasters(a)mathworks.com Subject: Problems integrating CIFS and NFS access control Hi Folks, I have a problem with the operation of a NetApp that servers up a share both via CIFS and NFS. The goal of a group that I support was to have a common directory for both the UNIX systems and the NT systems. A user would be able to see all of their files under either UNIX or NT. The problem manifests itself because whatever was last used by the user to set access rights is what sets the security mode for the file or directory. For example, if a user accesses a directory from NT and gives himself and a NT group access to a file, from UNIX only he would have access. If from Unix he set a directory to rwxr-x---, someone in an NT group that he specifically want to grant access to would not have access. Generally speaking whatever was last used (NT or Unix) to set permissions works correctly, and the other one works, but not correctly. My questions to the group: 1: Is anyone sharing the same directory under CIFS and NFS and found a workaround or an acceptable way to implement permissions? 2: Has anyone thought about what would be wrong with using UNIX permissions to determine access when using NFS and NT permissions when using CIFS? Thanks, Paul Lupa

1 0

RE: Problems integrating CIFS and NFS access control
by Muhlestein, Mark 17 Mar '00

17 Mar '00

Make sure you are running 5.3 or greater. Once you are, determining access is pretty straightforward: * If the file has an NT ACL, the ACL is used to check permissions. NFS requests use the mapped NT identity of the requesting user. * If the file does not have an ACL, UNIX permissions are used. CIFS users use the mapped UNIX identity of the requesting user. In-house at NetApp we use the mixed mode a lot, because it gives the most flexibility. There is a web site on NOW than explains all about how to use the multi-protocol security on the filer: http://now.netapp.com/knowledge/docs/olio/guides/53_troubleshooting/index.sh tml About your suggestion about having the access check based on the client type: we considered that approach but we decided it results in even more confusing behavior as seen by non-native clients, as well as being less secure. The motivation for our approach is in the "Basic Concepts" section of the above document. If you still have questions, or you can't make your environment work the way you want it to, please let us know. Multi-protocol security can be confusing, but we are very interested in making it work as well as possible in as many situations as possible. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Paul Lupa [mailto:Paul.Lupa@motorola.com] Sent: Thursday, March 16, 2000 9:24 PM To: toasters(a)mathworks.com Subject: Problems integrating CIFS and NFS access control Hi Folks, I have a problem with the operation of a NetApp that servers up a share both via CIFS and NFS. The goal of a group that I support was to have a common directory for both the UNIX systems and the NT systems. A user would be able to see all of their files under either UNIX or NT. The problem manifests itself because whatever was last used by the user to set access rights is what sets the security mode for the file or directory. For example, if a user accesses a directory from NT and gives himself and a NT group access to a file, from UNIX only he would have access. If from Unix he set a directory to rwxr-x---, someone in an NT group that he specifically want to grant access to would not have access. Generally speaking whatever was last used (NT or Unix) to set permissions works correctly, and the other one works, but not correctly. My questions to the group: 1: Is anyone sharing the same directory under CIFS and NFS and found a workaround or an acceptable way to implement permissions? 2: Has anyone thought about what would be wrong with using UNIX permissions to determine access when using NFS and NT permissions when using CIFS? Thanks, Paul Lupa

1 0

RE: Problems integrating CIFS and NFS access control
by ZANGA, Michael, GCM 17 Mar '00

17 Mar '00

What kind of security mode is the volume in question? Mixed mode can be problematic as NT rights supersede the Unix rights and basically lock a Unix user out THAT doesnt have a equivalent NT id. I would recommend using id that match on both side and not use mixed mode. I have a 200 gb volume with mixed clients and mixed mode was a problem at first. We changed the security style to Unix and all is well. -----Original Message----- From: Paul Lupa [mailto:Paul.Lupa@motorola.com] Sent: Friday, March 17, 2000 12:24 AM To: toasters(a)mathworks.com Subject: Problems integrating CIFS and NFS access control Hi Folks, I have a problem with the operation of a NetApp that servers up a share both via CIFS and NFS. The goal of a group that I support was to have a common directory for both the UNIX systems and the NT systems. A user would be able to see all of their files under either UNIX or NT. The problem manifests itself because whatever was last used by the user to set access rights is what sets the security mode for the file or directory. For example, if a user accesses a directory from NT and gives himself and a NT group access to a file, from UNIX only he would have access. If from Unix he set a directory to rwxr-x---, someone in an NT group that he specifically want to grant access to would not have access. Generally speaking whatever was last used (NT or Unix) to set permissions works correctly, and the other one works, but not correctly. My questions to the group: 1: Is anyone sharing the same directory under CIFS and NFS and found a workaround or an acceptable way to implement permissions? 2: Has anyone thought about what would be wrong with using UNIX permissions to determine access when using NFS and NT permissions when using CIFS? Thanks, Paul Lupa ********************************************************************** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. ************************************************************************

1 0

RE: Problems integrating CIFS and NFS access control
by johnj.sasso＠ps.ge.com 17 Mar '00

17 Mar '00

The area that the NT and UNIX users access on the NetApp, is that a MIXED-style qtree (as opposed to an NTFS- or UNIX-style qtree)? I had many problems using MIXED-style qtrees between UNIX and NT, with the behavior being inconsistent and confusing. I ended up using a UNIX-style qtree instead, sacrificing the NT ACLs the NTFS-style qtree offers. On that note, my login name for both UNIX and NT is identical. However, when I modify and save a file via NT (e.g. through Excel, Word) in a UNIX-style qtree, the file gets saved as root, thereby preventing me from accessing the file via UNIX. Very, very annoying. --john -----Original Message----- From: Paul Lupa [mailto:Paul.Lupa@motorola.com] Sent: Friday, March 17, 2000 12:24 AM To: toasters(a)mathworks.com Subject: Problems integrating CIFS and NFS access control Hi Folks, I have a problem with the operation of a NetApp that servers up a share both via CIFS and NFS. The goal of a group that I support was to have a common directory for both the UNIX systems and the NT systems. A user would be able to see all of their files under either UNIX or NT. The problem manifests itself because whatever was last used by the user to set access rights is what sets the security mode for the file or directory. For example, if a user accesses a directory from NT and gives himself and a NT group access to a file, from UNIX only he would have access. If from Unix he set a directory to rwxr-x---, someone in an NT group that he specifically want to grant access to would not have access. Generally speaking whatever was last used (NT or Unix) to set permissions works correctly, and the other one works, but not correctly. My questions to the group: 1: Is anyone sharing the same directory under CIFS and NFS and found a workaround or an acceptable way to implement permissions? 2: Has anyone thought about what would be wrong with using UNIX permissions to determine access when using NFS and NT permissions when using CIFS? Thanks, Paul Lupa

1 0

RE: Help with vif's
by johnj.sasso＠ps.ge.com 16 Mar '00

16 Mar '00

The latest version of DataONTAP, 5.3.5, mentioned something about doing load-balancing across the links of a VIF. I have not delved into it any further, but can a NetApp person tell me if the new version indeed does load balancing across the VIF links (of course, on sending data from the NetApp to the client)? --john -----Original Message----- From: Michael S. Keller [mailto:mkeller@mail.wcg.net] Sent: Thursday, March 16, 2000 11:01 AM To: toasters(a)mathworks.com Subject: Re: Help with vif's Arthur Darren Dunham wrote: > > have the Catalyst set up properly. Can someone out there who's done > > this before tell me what we need to do on the cat? > > Do I need to put the vif commands into the rc file? > > Thanks in advance, > > The cisco (unless they've changed something recently) has a limitation > on how it sends packets across the links. Packets destined for the > truck will be hashed onto a link by the last two bits of the hardware > source address. That means if most of your traffic is coming from a > single router port, it's all going to get hashed down to only one link. The answer I received from NetApp, with a similar situation, was that the switch XORs the last two bits of source and destination MAC addresses, then uses that to choose the outgoing port within an EtherChannel trunk. With only four clients making heavy use of the VIFs, MACs clustered. With hundreds of clients, you should see a more even distribution. I built a truth table that showed then-current and desired states, then altered client MAC addresses. Does that answer the question? -- Michael S. Keller, Technical Solutions Consultant, Sprint Enterprise Network Services On loan to Williams Communications Group Voice 918-574-6094, Amateur Radio N5RDV

1 0

Re: NetApp backup recommendations
by Steve Kappel 16 Mar '00

16 Mar '00

>> NetBackup (Veritas) can only dump to tape drives connected directly to an >> NDMP server (i.e. only to a locally-attached NetApp drive, or to a remote >> NetApp with attached tape). It cannot do NDMP backups to a "normal" >> NetBackup media server. I've been told that NetBackup can only restore >> NDMP dumps in place, too -- not to an alternate directory, for example >> (I haven't verified that with the vendor). >> >Hmm this could be deadly for us. Legato recommends direct attached >tape drives which I was preferring and it makes sense for performance. Directly attached drives are more efficient. Even with plenty of network bandwidth, backing up over the network still puts a significant CPU load on the boxes. If the filers are physically within reach, a large library can have some of its drives split off onto separate SCSI buses and one bus attached to each filer. "normal" NetBackup media servers can also have some of the drives. Robotic control can be anywhere in such a config. This is really the best of all worlds (IMHO) as you get direct attach performance on all boxes but you are sharing the library. If they are not physically within reach then 3-way backup to another filer can be used. Large sites may dedicate a NetApp as a "tape server". I believe there are library vendors that are looking at supporting NDMP directly in their libraries. >But we got discussing this issue, and the idea of the NetApp >spontaneously rebooting due to a SCSI bus error (from the tape drive) >came up. For our new NetApp we cannot afford to have this happen. >It's not so critical for our existing filer. Our existing filer runs >OnTap 5.2.1 and has rebooted once (in approx 7 months) due to a SCSI >bus error (a tape got stuck in the jukebox and the filer booted to >try to clear the error). Although with newer revs of OnTap and the >firmware, maybe this isn't an issue any more? I have never seen this with the NetApp's we have in NetBackup development. I see plenty of bus resets but never a reboot. __________________________________________________________________________ Steve Kappel steve.kappel(a)veritas.com VERITAS Software steve.kappel(a)iname.com (Personal)

1 0

Subscription
by Donna Spitz 16 Mar '00

16 Mar '00

Hello, I would like to subscribe to your group: Donna Spitz DonnaS(a)Worksta.com Thank you for your help. Donna

1 0

Jump to page:

2026

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