2010-07-12 09:23 AM
We have a NetApp file server running Data ONTAP Release 7.2.7. Most of the files that it serves are stored in mixed qtrees and served to both end-user desktop PCs and servers. Our NFSv3 (Linux) and CIFS (Windows) users frequently collaborate by creating and accessing the same files and folders using both protocols.
What causes regular confusion and frustration is that (in particular) the Linux file-system API provides no full access to the state of a file. As far as I know (correct me if I'm wrong), there is no mechanism in Data ONTAP for a Linux/NFS client user to
- reliably recognize whether a given file is managed under POSIX/NFS or CIFS permissions
- read/write the CIFS ACL (if there is one)
- find out who has locked a file using CIFS (e.g., when NFSv3 access to it is currently blocked because a files is being read by a Windows application)
Adding NFSv4 to the mix appears to make the state just even more complex.
I understand that there used to be a shell extension that allows one to see the full access-control status of a file under Windows Explorer. Is there anything equivalent under Linux?
What I *really* would like to see (as a new feature in future releases) is a means for both NFS and CIFS users to query the full status of each file without requiring the installation of any additional tools on the client operating system.
The most practical way of implementing this, that I can think of, is to create in each subdirectory another invisible file (similar to the existing invisible .snapshot directories) that lists the full ACL and/or locking status of each file in that directory.
So if I wanted to see while files under /home/mydir currently have a POSIX/NFS or CIFS personality, and what their full ACLs are, then all I would have to type is something like
$ cat /homes/mydir/.netapp_dirstat
and I would then get a human-readable (and hopefully also reasonably easily machine parseable) directory listing: similar to what "ls -la" gives me, but with the full ACL status of each file. Or at least of each file that currently has a non-POSIX/NFSv3 personality. A similar .netapp_locks file could provide the end-user information about who has locked what.
Providing access to the full status of a file via proc-filesystem-like server-generated invisible pseudo-files in each directory would have many advantages:
- very convenient to use
- no new protocols or protocol-extensions needed
- no new kernel drivers or other special tools need to be installed.
It would give users who live on mixed qtrees finally the feeling that "what I see is what I get", rather than never knowing for sure whether a file's permission bits and ACL status are currently real or fake.
Dr Markus Kuhn
Computer Laboratory, University of Cambridge
2010-07-13 01:34 AM
The "mixed" security style is something that should be very rarely used. The "problem " with mixed is, that every client accessing the data is setting the access right which makes most sense for his world (Windows or Unix), which can (and most often does) relate in access issues...
Use the the NTFS Security Style when the data in the qtree/volume is managed by Windows Admins.
Use the the UNIX Security Style when the data in the qtree/volume is managed by Unix Admins.
WAFL will do the right thing in "emulating/presenting" the correct ACL to the clients. At least more often then with MIXED.
To find out who locks what (at least from windows clients) you can use the "cifs sessions -c" command.
I hope this helps,