mount.cifs; NetApp; owner/mode appearance

[David Lee-2]

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!



--

:  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: [phone]                  U.K.                  :

[Fox, Adam]

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@...


-----Original Message-----
From: David Lee [mailto:t.d.lee@...]
Sent: Wednesday, April 23, 2008 12:24 PM
To: toasters@...
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!



--

:  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: [phone]                  U.K.                  :

[Darren Sykes]

If it's viable in your environment you could use Kerberos rather than sysauth as authentication and offer your customer NFS access.

ONTap doesn't support the Unix extensions for CIFS so that's a non-starter.  

 

Darren.

 

---

From: owner-toasters@... on behalf of Fox, Adam
Sent: Wed 23/04/2008 18:24
To: David Lee; toasters@...
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@...


-----Original Message-----
From: David Lee [t.d.lee@...]
Sent: Wednesday, April 23, 2008 12:24 PM
To: toasters@...
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!



--

:  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: [phone]                  U.K.                  :



 To report this email as spam click https://www.mailcontrol.com/sr/jyzagqhhjiNWreyqttw94F4h0CU5HMRv0uwXPMoWD!qbgatU!RZyHkzXPQ3KA+5sDCKDei1vClk2r!FHq9alb72tF!slsczTMsBzGn+3LttOBYtv6qplgEIAhTh4p2WGP6d7OItOYUI0G8EFUinOFbdPDg32qzeOt0ET3f6KOqhgHbPZ8woLFg3w97Qo3SJ6zkltB!+NVGhfUM8oaZZFh62gE20VSCsy .

[Darren Dunham]

On Wed, Apr 23, 2008 at 01:24:14PM -0400, Fox, Adam wrote:
> 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.

But since this is a unix qtree, it doesn't have an ACL....  There's loss
at both sides of the link.

--
Darren Dunham                                           ddunham@...
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

[Webster, Stetson]

There are some points about ntfs/unix qtree styles that can be easliy overlooked or mis-interpreted:

• A mixed security style only means that there can be unix and ntfs files in that qtree
• It DOES NOT mean that the files are mixed mode; be sure to understand the difference.
• The files can switch security styles at any time, thus causing CIFS ACL's to get dropped when switching to unix, etc.

Since the CIFS ACL's are so much more detailed and harder to match in unix than unix ACL's are to match in CIFS, in a mixed environment, I usually recommend an NTFS security style and then use user mapping (usermap.cfg) to equate users.

 

Additional documentation of this same theme while you're at it:

 

Unix group permissions on directory not enforced on CIFS users:

http://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb16326

 

Unified Windows and UNIX Authorization Using Microsoft Active Directory LDAP as a Directory Store:

http://www.netapp.com/us/library/technical-reports/tr-3458.html

Unified Windows and UNIX Authentication Using Microsoft Active Directory Kerberos

http://www.netapp.com/us/library/technical-reports/tr-3457.html

Good luck !

 

Cheers ...................

 

Stetson M. Webster
Onsite Professional Services Engineer
PS - North Amer. - East

NetApp
919.250.0052 Mobile
Stetson.Webster@...

 


-----Original Message-----
From: David Lee [t.d.lee@...]
Sent: Wednesday, April 23, 2008 12:24 PM
To: toasters@...
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!



--

:  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: [phone]                  U.K.                  :

[tmac-3]

Problem with MIXED mode:

If you do a chown/chmod/chgroup, the ACL is wiped out and defaults
back to UNIX secuity.

Use NTFS or use UNIX. Mixed leaves too many holes you can run into.

What about NFSv4? This provides ACL mechanisms and is supported on
many common platforms.

--tmac

On Wed, Apr 23, 2008 at 12:24 PM, David Lee <t.d.lee@...> wrote:

> 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!
>
>
>
>  --
>
>  :  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: [phone]                  U.K.                  :
>

--
--tmac

RedHat Certified Engineer #804006984323821 (RHEL4)
RedHat Certified Engineer #805007643429572 (RHEL5)

Principal Consultant

[Jeff Mery]

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@...>
To:	"David Lee" <t.d.lee@...>, <toasters@...>
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@...


-----Original Message-----
From: David Lee [mailto:t.d.lee@...]
Sent: Wednesday, April 23, 2008 12:24 PM
To: toasters@...
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!



--

:  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: [phone]                  U.K.                  :

[Jeff Mery]

From the 7.2.4 release notes:

"The upcoming Data ONTAP 7.3 release will address some important NFSv4 issues. These enhancements in the 7.3 release will also focus on the stability of the NFSv4 protocol. Therefore you are advised to run NFSv4 with Data ONTAP 7.2.x releases in test environments only. For production environments, wait to use NFSv4 with Data ONTAP 7.3."

http://now.netapp.com/NOW/knowledge/docs/ontap/rel724/html/ontap/rnote/rel_notes/concept/c_oc_rn_lim-nas-nfsv4-test.html#c_oc_rn_lim-nas-nfsv4-test


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:	tmac <tmacmd@...>
To:	"David Lee" <t.d.lee@...>
Cc:	toasters@...
Date:	04/23/2008 02:00 PM
Subject:	Re: mount.cifs; NetApp; owner/mode appearance

---

Problem with MIXED mode:

If you do a chown/chmod/chgroup, the ACL is wiped out and defaults
back to UNIX secuity.

Use NTFS or use UNIX. Mixed leaves too many holes you can run into.

What about NFSv4? This provides ACL mechanisms and is supported on
many common platforms.

--tmac

On Wed, Apr 23, 2008 at 12:24 PM, David Lee <t.d.lee@...> wrote:
> 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!
>
>
>
>  --
>
>  :  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: [phone]                  U.K.                  :
>



--
--tmac

RedHat Certified Engineer #804006984323821 (RHEL4)
RedHat Certified Engineer #805007643429572 (RHEL5)

Principal Consultant

[Stephen C. Losen]

> 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.

When you access a Unix security style qtree via CIFS the netapp presents it
as a "vfat" filesystem (not NTFS) i.e., there are no file owners, no ACLS
and certainly no Unix permissions visible via the CIFS protocol in the case
of "vfat".  You do get a "hidden" bit and a "read only" bit, and an
"archive" bit but that's about it for permissions.

On Linux, the CIFS filesystem driver fills in the missing Unix user,
group, and permissions with fictitious values.  There is no way to chown or
chmod "vfat" files from the Linux box.  You can, however, read, write,
create and delete files, depending on the permssions of the user who logged
in to the netapp via mount.cifs.

There is one other gotcha with mount.cifs.  All file accesses appear to the
netapp as coming from the user who logged in to the filer via mount.cifs,
no matter who the user is on Linux.  So if Linux user "john" runs
mount.cifs and logs in to the netapp as "jsmith" and then Linux user "sue"
access the mounted files, both "john" and "sue" are user "jsmith" on the
netapp.  So "sue" may have unintended write access to the files.

I think what you are doing is quite reasonable, but you may need
to also provide a NFS client for folks to use for running chmod
since they can't do it from Linux and mount.cifs.  Or else just
fix problems yourself by hand.  About 0.0001 % of users care about,
let alone understand file permissions anyway.

By the way, you can configure the filer to use a "umask" or you can
have the filer give newly created files and directories the same
permissions as the parent directory (works pretty well in most
cases).

>
>
> 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!
>
>
>
> --
>
> :  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: [phone]                  U.K.                  :
>

Steve Losen   scl@...    phone: [phone]

University of Virginia               ITC Unix Support

[Kenneth Heal]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi

I am inclined to agree with Tim, my experience has been that mixed mode can lead to a lot of chaos and sadness.  One tech report which might be relevant here is called Security in NFS Storage Networks:
http://media.netapp.com/documents/tr_3387.pdf

As Tim suggests NFSv4 might be an option and provides a lot of nice features.  Another choice could be Kerberos authentication, and this might be the way to go, though this will depend on your exact setup.

Let us know how it goes; this is indeed a fairly common issue caused by design deficiencies of standard NFSv3/NIS without any easy out of the box solution.

cheers
Kenneth

---

> Date: Wed, 23 Apr 2008 14:45:24 -0400

> From: tmacmd@...
> To: t.d.lee@...
> Subject: Re: mount.cifs; NetApp; owner/mode appearance
> CC: toasters@...
>
> Problem with MIXED mode:
>
> If you do a chown/chmod/chgroup, the ACL is wiped out and defaults
> back to UNIX secuity.
>
> Use NTFS or use UNIX. Mixed leaves too many holes you can run into.
>
> What about NFSv4? This provides ACL mechanisms and is supported on
> many common platforms.
>
> --tmac
>
> On Wed, Apr 23, 2008 at 12:24 PM, David Lee <t.d.lee@...> wrote:
> > 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!
> >
> >
> >
> > --
> >
> > : 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: [phone] U.K. :
> >
>
>
>
> --
> --tmac
>
> RedHat Certified Engineer #804006984323821 (RHEL4)
> RedHat Certified Engineer #805007643429572 (RHEL5)
>
> Principal Consultant

---

Express yourself instantly with MSN Messenger! MSN Messenger

[David Lee-2]

On Wed, 23 Apr 2008, Kenneth Heal wrote:

> I am inclined to agree with Tim, my experience has been that mixed mode
> can lead to a lot of chaos and sadness.  One tech report which might be
> relevant here is called Security in NFS Storage Networks:
> http://media.netapp.com/documents/tr_3387.pdf
>
> As Tim suggests NFSv4 might be an option and provides a lot of nice
> features.  Another choice could be Kerberos authentication, and this
> might be the way to go, though this will depend on your exact setup.

Thanks to all for their input.

Quick re-cap: We basically have UNIX (Linux) clients wishing to access
data that was previously on a UNIX (Solaris) server now migrating to
NetAPP (and still intended to look like UNIX data).  For other (but
related "general tidy up") reasons we are wanting to tighten up the
previous simple NFS access, to prevent undesirable (but previously
possible) "su root; su other" activity.

NFS was nice (UNIX preservation) but weak on user-based control.  CIFS
would give us the possibility of user-based control, but wrecks the
appearance of ownership and filemodes.

Ken's reply suggests that Kerberos authentication (our NetApp is already
in an Active Directory domain) might give us the hooks to keep NFS and
introduce user-based control.  It sounds well worth exploring.  Thanks.

> Let us know how it goes; this is indeed a fairly common issue caused by
> design deficiencies of standard NFSv3/NIS without any easy out of the
> box solution.

I'll try to remember to do that.

Thanks again.


--

:  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: [phone]                  U.K.                  :