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!
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!
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@mathworks.com on behalf of Fox, Adam Sent: Wed 23/04/2008 18:24 To: David Lee; toasters@mathworks.com 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!
--
: 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. :
To report this email as spam click https://www.mailcontrol.com/sr/jyzagqhhjiNWreyqttw94F4h0CU5HMRv0uwXPMoWD!qbg... .
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.
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!
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@netapp.com mailto:Stetson.Webster@netapp.com www.netapp.com http://www.netapp.com/
-----Original Message----- From: David Lee [mailto:t.d.lee@durham.ac.uk 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!
--
: 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/ http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :
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@durham.ac.uk 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.
- Is the above reasoning towards understanding the problem more or less
correct?
- 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: +44 191 334 2752 U.K. :
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_n...
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@gmail.com To: "David Lee" t.d.lee@durham.ac.uk Cc: toasters@mathworks.com 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@durham.ac.uk 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.
- Is the above reasoning towards understanding the problem more or
less
correct?
- 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: +44 191 334 2752 U.K. :
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@gmail.com To: t.d.lee@durham.ac.uk Subject: Re: mount.cifs; NetApp; owner/mode appearance CC: toasters@mathworks.com
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@durham.ac.uk 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.
- Is the above reasoning towards understanding the problem more or less
correct?
- 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: +44 191 334 2752 U.K. :
-- --tmac
RedHat Certified Engineer #804006984323821 (RHEL4) RedHat Certified Engineer #805007643429572 (RHEL5)
Principal Consultant
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
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.
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.
- Is the above reasoning towards understanding the problem more or less
correct?
- 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: +44 191 334 2752 U.K. :
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
-
A Darren Dunham -
Darren Sykes -
David Lee -
Fox, Adam -
jeff.mery＠ni.com -
Kenneth Heal -
Stephen C. Losen -
tmac -
Webster, Stetson