toasters

toasters@lists.teaparty.net

13531 discussions

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