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
-------------------------------------------------------------------------
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?
: David Lee
I.T. Service
:
: Senior Systems Programmer
Computer Centre :
: UNIX Team Leader
Durham University :
:
South Road :
: http://www.dur.ac.uk/t.d.lee/
Durham DH1 3LE
:
: Phone: +44 191 334 2752
U.K.
: