[linux-cifs-client] w2k server "unix extensions"?

Steven French sfrench at us.ibm.com
Fri Oct 22 15:12:39 GMT 2004

> problem: when the deb box mounts the w2k share the dirs have allways 
> same permissions. i found out, that unix extensions have to be enabled 
> on the server which shares to have not default uid:gid and masks. so, i 
> ask my self if it is possible to mount by using mount.cifs a w2k share 
> and have original permissions? maybe this is the wrong list to ask cos 
> w2k specific, but i dont know where to look in the win world because i 
> think 'unix extensions' is just a phrase from the samba config, isn't 
> it? my concern is to know how to enable 'unix extenions' on the w2k 

The Unix Extensions parm in smb.conf refers to support for CIFS network 
protocol Unix Extensions, documented by HP and others and included in the 
official SNIA (Storage Network Industry Association) CIFS Technical 
Samba is not the only server to support it, and there are multiple clients 

which support it including of course the Linux cifs vfs. 

Windows does not support the CIFS Unix Extensions.  We can though get
adequate behavior to Windows servers from POSIX clients though but it will
require a few additional enhancements and hopefully agreement from some
of the other client writers.  There are three key issues to handle which 
will greatly help support for POSIX clients to Windows in the absence 
of support the Unix Extensions in the MS server code:

1) mapping of symlinks on files to a client only symlink format (Conrad's 
client calls them xsymlinks and a definition for them is in the Linux
cifs client header fs/cifs/cifspdu.h, but not implemented in 
Linux's cifs_symlink function yet).  This is a bit awkward because it
relies on a "magic file size" but it does have a signature to make
misinterpreations unlikely.  Reparse points will likely work for directory
symlinks although investigation is needed whether relative paths are 
(all junction reparse points that I have seen have Windows local server 
paths with drive_letter:\path)
2) mapping of the Windows file owner (in the SID) to its equivalent of 
Unix UID so the correct owner shows up on the POSIX client side.
3) mapping of file permissions - either from the Windows ACL to an 
mode that it would represent or simply storing them in an extended 
or alternate data stream.
4) extensions for higher performance and possibly alternate transport 

jra and I and a few others have done some initial work exploring what 
would be 
needed for a version 2 of the CIFS Unix Extensions, perhaps called "CIFS 
POSIX Extensions" (a better name would be welcome) whose highlights would 
include a slightly improved form of CreateX  and an alternative for POSIX 
byte range locking and support for "POSIX ACLs" on the wire (among other 
features).   Feedback on this (what protocol extensions would be needed)
would be welcome, as would advice/help on formatting the precise language
of protocol documents (IETF style terminology aids in precision, the lack 
which was a flaw in early SMB and CIFS standards documentation).  We have
been flooded with work so work on the protocol extensions has gone
slowly over the past year.  Now that I have started fixing up the
webpage, I will post a draft of what we have so far 
to the project page (linux-cifs.samba.org) this weekend. 

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

More information about the samba-technical mailing list