« Return to Thread: mount.cifs; NetApp; owner/mode appearance
Re: mount.cifs; NetApp; owner/mode appearance
by Stephen C. Losen
::
Rate this Message:
> 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: +44 191 334 2752 U.K. :
>
Steve Losen scl@... phone: 434-924-0640
University of Virginia ITC Unix Support
>
> 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: +44 191 334 2752 U.K. :
>
Steve Losen scl@... phone: 434-924-0640
University of Virginia ITC Unix Support
« Return to Thread: mount.cifs; NetApp; owner/mode appearance
| Free embeddable forum powered by Nabble | Forum Help |
