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