While the short-version says a Unix-derived qtree, in the long explanation you say the qtree is mixed.
This may have been corrected in later version so ONTAP, but generally speaking mixed mode qtrees cause more problems than they solve. The effective permissions on the files/directories in the qtree are actually "last in wins". Meaning that whatever system most recently set permissions are the permissions the directory structure will have.
If someone goes in and chowns something from *nix then any nice and neat CIFS ACL's will get blown away and the only permissions will be uid/gid based. Likewise is true for CIFS. If a CIFS user goes in and changes permissions on a Unix qtree the uid/gid permissions are replaced with an ACL.
We do a fair amount of multi-protocol access and 99% of the time it's an NTFS qtree exported via NFS with some form of user mapping (mostly simple here). This gets us the granular ACL controls we often need without trying to force it via Unix uid/gid (or NFS v4 <shudders>).
Jeff Mery - MCSE, MCP National Instruments
------------------------------------------------------------------------- "Allow me to extol the virtues of the Net Fairy, and of all the fantastic dorks that make the nice packets go from here to there. Amen." TB - Penny Arcade -------------------------------------------------------------------------
From: "Fox, Adam" Adam.Fox@netapp.com To: "David Lee" t.d.lee@durham.ac.uk, toasters@mathworks.com Date: 04/23/2008 12:35 PM Subject: RE: mount.cifs; NetApp; owner/mode appearance
If you have a Windows ACL on a given file and you view it with UNIX ls which displays UNIX permissions, they tend to look bad since the UNIX bits cannot properly represent Windows ACLs. But the ACL will be enforced as set for the file, but it cannot be displayed properly.
-- Adam Fox adamfox@netapp.com
-----Original Message----- From: David Lee [mailto:t.d.lee@durham.ac.uk] Sent: Wednesday, April 23, 2008 12:24 PM To: toasters@mathworks.com Subject: mount.cifs; NetApp; owner/mode appearance
If this is an FAQ, feel free to point me in the right direction...
Short-form: o UNIX-derived filesystem (qtree) on filer; o Linux client using "mount.cifs" to access qtree via CIFS; o File ownerships look wrong; mode always shows as 777.
Detail:
We run a central fileserver on behalf of many users. A particular new qtree is a fresh copy of a filesystem (on which many users each have their own, self-owned subdirectory). It was previously hosted on UNIX, and is still intended to be used solely in a UNIX context.
But we (service providers) don't own the Linux machines which will be connecting to this, therefore we are not exporting it as NFS (host-based security) as this would compromise security. (User-A on their Linux box could 'su' to root and then 'su' again to User-B and see User-B files... this would be bad.)
So we are trying to set things up so that the users can use CIFS (which is user-based security). So we have set the qtree mixed mode and made it a CIFS share on the filer. So far, so good.
Overall: UNIX users on UNIX clients to UNIX-filesystems on filer, but having to use CIFS rather than NFS as the protocol.
When a user on their Linux client does: /sbin/mount.cifs //filer/qtree /local/mountpoint
what they see is that all file ownerships are apparently their own (even though this level shows the directory of self-owned subdirectories) and that all permissions appear as 777 (rwxrwxrwx). The actual workings seem to be OK, but the appearance is less than desirable.
Presumably this is because the SMB/CIFS protocol cannot carry the UNIX permissions and ownerships.
1. Is the above reasoning towards understanding the problem more or less correct?
2. Is there any way around it? I understand that more recent definitions of CIFS have UNIX extensions. Is this implemented in ONTAP?
Our versions: filer: "NetApp Release 7.2.2" mount.cifs: 1.10
Apologies if the question is poorly expressed!