we found that the key things to check are -
groups - You must have the same primary NT group as UNIX group - the same group name. clearcase_aldb - This user must exist in both realms. root=<hostname> - This must be set on the nfs share for all unix systems that will have root access to the vobs and views. access=<hostname> - This must be set on the nfs share for all unix systems that will have access to the shares.
There is a great white paper on this at http://www.netapp.com/tech_library/311.html?fmt=print
Simon
-----Original Message----- From: Marion Hakanson [mailto:hakanson@cse.ogi.edu] Sent: 11 March 2003 21:26 To: John Stoffel Cc: toasters@mathworks.com Subject: Re: ClearCase 5.x on NetApp, mixed NFS/CIFS setup issues
. . . mixed security settings. The problem is that running as root on one of the ClearCase servers, we cannot remove a file that was created by a user running on a PC with CC client software.
Our infrastructure is pretty simple, with just one NIS domain and one NT domain to work with. But because our corporate IT group won't give us a short group name in the Win2K domain, we're forced to use the unix username of 'mss-vobadm' with an NT username of NA05\sa106068ccalbd. We've got a usermap.cfg as shown below.
Does anyone have any hints on how we can fix this up, or track down the proper setup for this environment?
NA05\sa106068ccalbd => mss-vobadm NA05\sa106068ccalbd <= root
Unencumbered by experience with ClearCase (:-), I'll say that I would try the following in usermap.cfg (assuming that NA05* refers to local users on the filer, or to your single NT domain):
NA05\sa106068ccalbd == mss-vobadm NA05\Administrator == root
And we've tried to use the following cifs options: . . . cifs.nfs_root_ignore_acl on . . .
With the above, NFS root users (which are now equivalent to Windows admin users) should be able to override any Windows permissions. It _may_ be necessary to "chown root" the problem files/directories before you'll be able to remove them, depending on what Windows ACL's are in effect.
Of course, for root to have this type of access, your NFS partition must be exported with "root=" access to the NFS clients which will be trying to remove this stuff.
This type of arrangement works for us here, though without the issue of ClearCase involved. It may be overkill for your situation, but it's a decent place to start.
And as I've said before, in case you haven't already done so:
There's an excellent article on NOW, with a title something like "Security Troubleshooting Guide", which describes all these issues in great detail. Definitely read through this before converting.
Oh yes: I think that if a Windows client has a file open, you won't be able to delete it from the Unix side. You also can't delete a directory which has a Windows share pointing at it.
Regards,
After working with Rational and our local ClearCase admins, it turns out to be a problem with having ClearCase (CC) v4.x clients on NT which talk to our CC 5.x servers. The clients have a cache which keeps pointers to recently used files. The cache doesn't purge itself, and it also keeps the file open, so the NetApp won't allow it to be deleted until the client flushes the cache.
So we'll be implementing a weekly flushing of the cache (I think, they're still looking into this) but for now we're just going to ignore the issue, since it only happens when we're purging the ClearText pools weekly.
Thanks for the suggestions and help.
John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies stoffel@lucent.com - http://www.lucent.com - 978-399-0479