toasters March 2000

toasters@lists.teaparty.net

125 participants
147 discussions

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

DLT recommendations
by Ethan Torretta 15 Mar '00

15 Mar '00

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? ejt

3 2

NetApp Reseller
by TTSG 15 Mar '00

15 Mar '00

Hi, Can anyone suggest a good NetApp reseller? (In the North East is extra points, able to ship to Germany for even more extra points) (New or used) Also, wondering what the general availability/delivery of one is... Private replies please. Tuc/TTSG

1 0

RE: Incremental backup of snapshots
by Anders Ljungberg S (QDT) 15 Mar '00

15 Mar '00

Hi! I think your problem is the way Legato is handling archive bits in NT. On the readonly snapshot area archive bits cant be reseted. On the NT frontend set the variable NSR_AVIODE_ARCHIVE to YES ( i think ). This will take archive bits out of play and you'll be using mtime. Unfortunally NT is'nt always that consekvent about modifying mtime. Good Luck Anders Ljungberg -----Original Message----- From: Christopher Algar [mailto:christopher.algar@s1.com] Sent: Tuesday, March 14, 2000 5:02 PM To: toasters Subject: Incremental backup of snapshots Have a backup problem using Solstice backup 5.1.1 - Legato networker in drag. I'm backing up the ntfs qtrees of an F760 by adding \\filer\share\.snapshot\nightly.0 to the client save sets on an nt server running the solstice backup client. We have 3 qtrees backed up in this way, all within the same volume, ntfs security style and oplocks enabled. Share Qtree \\filer\home\.snapshot\nightly.0 vol0/home \\filer\fs04_bak\.snapshot\nightly.0 vol0/be01fs04 \\filer\fs02_bak\.snapshot vol0/be01fs02 All of them are copied to tape, but only home has incremental smaller than full backups. Any ideas what to check, or why one should work and not the others. Obviously this using a lot more taps and bandwidth than required. Thanks, Chris Algar

1 0

RE: Incremental backup of snapshots
by Muhlestein, Mark 14 Mar '00

14 Mar '00

Snapshots are read only. That means the backup app can't clear the DOS archive bit. It sounds like the solstice backup app is using the archive bit. If they were using the times on the files it would work. Incremental mode should work on the live filesystem. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Christopher Algar [mailto:christopher.algar@s1.com] Sent: Tuesday, March 14, 2000 9:02 AM To: toasters Subject: Incremental backup of snapshots Have a backup problem using Solstice backup 5.1.1 - Legato networker in drag. I'm backing up the ntfs qtrees of an F760 by adding \\filer\share\.snapshot\nightly.0 to the client save sets on an nt server running the solstice backup client. We have 3 qtrees backed up in this way, all within the same volume, ntfs security style and oplocks enabled. Share Qtree \\filer\home\.snapshot\nightly.0 vol0/home \\filer\fs04_bak\.snapshot\nightly.0 vol0/be01fs04 \\filer\fs02_bak\.snapshot vol0/be01fs02 All of them are copied to tape, but only home has incremental smaller than full backups. Any ideas what to check, or why one should work and not the others. Obviously this using a lot more taps and bandwidth than required. Thanks, Chris Algar

1 0

← Newer
1
...
7
8
9
10
11
12
13
14
15
Older →

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 March 2000