Thanks for the information, but what if I am using unix type permissions only (not mixed). What do I gain by running in mixed mode?
Thanks.
-----Original Message----- From: Nail, Larry [mailto:lnail@ti.com] Sent: Wednesday, March 28, 2001 6:32 PM To: 'neil lehrer' Cc: 'Tim Longo'; toasters@mathworks.com Subject: RE: W2k profile and Netapp
Purely administrative relief...
MS preferred method---------- Create a share, give every one FULL Control access at the share level ACL the files in the root to EVERYONE:READ, Admins:Full, System:Full Load usrmgr, in the profile area, enter \filer01\share%username% Usrmgr will create a new directory in the share for the username and set file acls to username:Full You're done
Issue 1 - It sets the \username directory to user:Full only, if you as an admin need access, you have to take ownership & push permissions down the tree... more work down the line when you have to troubleshoot. Issue 2 - 1 single share with EVERYONE FULL control as access... first off, this opens the root to EVERYONE on the network with a valid domain account & when you make/have a mistake with the file level ACL's, you've opened up the customer's data to EVERYONE. In this event, it also opens it up to the dummy who launched EXPLORE.WORM.KAK and starts to zero out files. Issue 3 - This setup is required to store W2K profiles/home directories on filers... the user must have FULL control as the OS impersonates the user when it downloads the profile.
Other Method-------------- Use a script to create shares... you eliminate having to deal with ACL's as the root of .../users is set for EVERYONE:Full which is inherited when a new directory is created. We never give our user's FULL control b/c that enables them to mess with permissions (which overwrites UNIX permissions if you're running mixed). I can't say this creates any overhead for me. I have seen no performance issues between either method & we're running over 700 user shares at this point.
Sample Script: : Create user share on \filer01\d$\users : Required : rmtshare from NT (or W2K) Resource Kit in path : rsh access to filer
: Create directory mkdir \filer01\d$\users%1
: Create Share rsh filer01 cifs shares -add %1 /vol/vol1/users/%1
: Comment Share rsh filer01 cifs shares -change %1 -comment "%1 Home Directory"
: rmtshare used to set permissions : This is a hold over from early filer maintenance where cifs shares comment : didn't work correctly... never check it afterward to see if they fixed it
rmtshare \filer01%1 /grant DOMAIN%1:c /grant "deskside":c /grant filer01\administrators:f /remove everyone
: Send email to server team that share was created echo User Share \filer01%1 Created |postmail -Hsomewhere.usa.com serverteam@somewhere.usa.com
To unshare-------- rmtshare \filer01\sharename\ /d rd \filer01\d$\users\username /q/s
Hope this helps... Larry
-----Original Message----- From: neil lehrer [mailto:nlehrer@ibb.gov] Sent: Wednesday, March 28, 2001 4:19 PM To: Nail, Larry Cc: 'Tim Longo'; toasters@mathworks.com Subject: Re: W2k profile and Netapp
what's the overhead for having 1 share per person?
"Nail, Larry" wrote:
You can map the share anyway you'd like. The preferred &
taught method is
to create 1 single share and then let the OS create
subdirectories on that
share. All our PC home directories are individual shares. 1 reason is
that
we control all access at the share level if at all possible...
don't have to
mess with file level ACL's. This also relieves most of the
issues of Unix
file permisssions vs. NTFS permissions.
-----Original Message----- From: Tim Longo [mailto:tlongo@avaya.com] Sent: Wednesday, March 28, 2001 2:25 PM To: toasters@mathworks.com Subject: W2k profile and Netapp
Greetings:
Currently on my NT 4 domain, we map a user share on the netapp,(also the unix home), to a drive letter in the NT account profile. This is in the form of: Z: \toaster\share
We have noticed that with Windows 2000, they want this share to
be mapped in
the form of: Z: \toaster\share\folder
This makes migrating people from the old convention to the new
convention
quite a bit of work.
Has anyone else encountered this, and how do you work around
this problem?
Needless to say, we are extremely angry with Microsoft.
Thanks
--
regards