http:///https:///api.php?action=feedcontributions&user=Jpeach&feedformat=atomSambaWiki - User contributions [en]2024-03-28T10:17:38ZUser contributionsMediaWiki 1.39.5https://wiki.samba.org/index.php?title=UNIX_Extensions&diff=3448UNIX Extensions2008-03-10T16:40:54Z<p>Jpeach: /* Extended Attribute symlinks */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x001<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x002<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x004<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x008<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x010 || All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x020<br />
|-<br />
|| CIFS_UNIX_LARGE_READ_CAP || 0x040 || We can cope with 24 bit reads in readX.<br />
|-<br />
|| CIFS_UNIX_LARGE_WRITE_CAP || 0x080 || We can cope with 24 bit writes in writeX.<br />
|-<br />
|| CIFS_UNIX_TRANSPORT_ENCRYPTION_CAP || 0x100 || We can do SPNEGO negotiations for encryption.<br />
|-<br />
||CIFS_UNIX_TRANSPORT_ENCRYPTION_MANDATORY_CAP || 0x200 || We *must* SPNEGO negotiations for encryption.<br />
|-<br />
|}<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
If the DOS readonly bit is set on the file, the unlink must fail.<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|| SMB_REQUEST_TRANSPORT_ENCRYPTION || 0x203 || Call to set up an encryption context.<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.<br />
<br />
== Samba server version information ==<br />
<br />
The data returned by the trans2 <code>SMB_FS_OBJECTID_INFORMATION</code> request contains 48 bytes of "extended information". Samba version 3.2 or later will return a <code>samba_extended_info_version</code> structure in this field.<br />
<br />
<pre><br />
/* Used in SMB_FS_OBJECTID_INFORMATION requests. Must be exactly 48 bytes. */<br />
#define SAMBA_EXTENDED_INFO_MAGIC 0x536d4261 /* "SmBa" */<br />
#define SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH 28<br />
<br />
struct smb_extended_info {<br />
uint32 samba_magic; /* Always SAMBA_EXTRA_INFO_MAGIC */<br />
uint32 samba_version; /* Major/Minor/Release/Revision */<br />
uint32 samba_subversion; /* Prerelease/RC/Vendor patch */<br />
NTTIME samba_gitcommitdate;<br />
char samba_version_string[SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH];<br />
};<br />
<br />
</pre><br />
<br />
This extension was first proposed in [http://marc.info/?t=120058872100007&r=1&w=2 this samba-technical thread].<br />
Like most (all?) SMB structures it is marshalled without any "holes" for<br />
alignment.<br />
<br />
== Storing symlinks on Windows servers ==<br />
<br />
=== Minshall+French symlinks ===<br />
Steve French and Conrad Minshall defined a file format for storing Unix symlinks on SMB volumes. This shall forever be known as the Minshall+French format.<br />
<br />
http://www.opensource.apple.com/darwinsource/10.5.1/smb-345/kernel/fs/smbfs/smbfs_vnops.c<br />
<br />
see smbfs_windows_readlink() and smbfs_create_windows_symlink_data()<br />
<br />
The Minshall+French format is a sequence of newline separated fields:<br />
<br />
<pre><br />
XSym\n<br />
char len[]\n<br />
char md5sum[32]\n<br />
char target[len]\n<br />
</pre><br />
<br />
* XSym: the literal ASCII characters 'X', 'S', 'y', 'm'<br />
* len: the length of the symlink target name as an ASCII string, with leading 0's<br />
* md5sum: The MD5 hash of the link target name<br />
* target: the link target path<br />
<br />
=== Extended Attribute symlinks ===<br />
<br />
http://marc.info/?l=samba-technical&m=120229726332475&w=2<br />
<br />
This proposal to store symlink information in extended attributes has not been implemented in any known SMB server.<br />
<br />
== SMB transport encryption ==<br />
(under construction)</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=3447UNIX Extensions2008-03-10T16:40:14Z<p>Jpeach: /* Extended Attribute symlinks */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x001<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x002<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x004<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x008<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x010 || All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x020<br />
|-<br />
|| CIFS_UNIX_LARGE_READ_CAP || 0x040 || We can cope with 24 bit reads in readX.<br />
|-<br />
|| CIFS_UNIX_LARGE_WRITE_CAP || 0x080 || We can cope with 24 bit writes in writeX.<br />
|-<br />
|| CIFS_UNIX_TRANSPORT_ENCRYPTION_CAP || 0x100 || We can do SPNEGO negotiations for encryption.<br />
|-<br />
||CIFS_UNIX_TRANSPORT_ENCRYPTION_MANDATORY_CAP || 0x200 || We *must* SPNEGO negotiations for encryption.<br />
|-<br />
|}<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
If the DOS readonly bit is set on the file, the unlink must fail.<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|| SMB_REQUEST_TRANSPORT_ENCRYPTION || 0x203 || Call to set up an encryption context.<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.<br />
<br />
== Samba server version information ==<br />
<br />
The data returned by the trans2 <code>SMB_FS_OBJECTID_INFORMATION</code> request contains 48 bytes of "extended information". Samba version 3.2 or later will return a <code>samba_extended_info_version</code> structure in this field.<br />
<br />
<pre><br />
/* Used in SMB_FS_OBJECTID_INFORMATION requests. Must be exactly 48 bytes. */<br />
#define SAMBA_EXTENDED_INFO_MAGIC 0x536d4261 /* "SmBa" */<br />
#define SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH 28<br />
<br />
struct smb_extended_info {<br />
uint32 samba_magic; /* Always SAMBA_EXTRA_INFO_MAGIC */<br />
uint32 samba_version; /* Major/Minor/Release/Revision */<br />
uint32 samba_subversion; /* Prerelease/RC/Vendor patch */<br />
NTTIME samba_gitcommitdate;<br />
char samba_version_string[SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH];<br />
};<br />
<br />
</pre><br />
<br />
This extension was first proposed in [http://marc.info/?t=120058872100007&r=1&w=2 this samba-technical thread].<br />
Like most (all?) SMB structures it is marshalled without any "holes" for<br />
alignment.<br />
<br />
== Storing symlinks on Windows servers ==<br />
<br />
=== Minshall+French symlinks ===<br />
Steve French and Conrad Minshall defined a file format for storing Unix symlinks on SMB volumes. This shall forever be known as the Minshall+French format.<br />
<br />
http://www.opensource.apple.com/darwinsource/10.5.1/smb-345/kernel/fs/smbfs/smbfs_vnops.c<br />
<br />
see smbfs_windows_readlink() and smbfs_create_windows_symlink_data()<br />
<br />
The Minshall+French format is a sequence of newline separated fields:<br />
<br />
<pre><br />
XSym\n<br />
char len[]\n<br />
char md5sum[32]\n<br />
char target[len]\n<br />
</pre><br />
<br />
* XSym: the literal ASCII characters 'X', 'S', 'y', 'm'<br />
* len: the length of the symlink target name as an ASCII string, with leading 0's<br />
* md5sum: The MD5 hash of the link target name<br />
* target: the link target path<br />
<br />
=== Extended Attribute symlinks ===<br />
<br />
http://marc.info/?l=samba-technical&m=120229726332475&w=2<br />
<br />
Extended attribute symlinks have not been implemented in any known SMB server.<br />
<br />
== SMB transport encryption ==<br />
(under construction)</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=3359UNIX Extensions2008-02-06T21:39:44Z<p>Jpeach: /* Storing symlinks on Windows servers */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x001<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x002<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x004<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x008<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x010 || All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x020<br />
|-<br />
|| CIFS_UNIX_LARGE_READ_CAP || 0x040 || We can cope with 24 bit reads in readX.<br />
|-<br />
|| CIFS_UNIX_LARGE_WRITE_CAP || 0x080 || We can cope with 24 bit writes in writeX.<br />
|-<br />
|| CIFS_UNIX_TRANSPORT_ENCRYPTION_CAP || 0x100 || We can do SPNEGO negotiations for encryption.<br />
|-<br />
||CIFS_UNIX_TRANSPORT_ENCRYPTION_MANDATORY_CAP || 0x200 || We *must* SPNEGO negotiations for encryption.<br />
|-<br />
|}<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
If the DOS readonly bit is set on the file, the unlink must fail.<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|| SMB_REQUEST_TRANSPORT_ENCRYPTION || 0x203 || Call to set up an encryption context.<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.<br />
<br />
== Samba server version information ==<br />
<br />
The data returned by the trans2 <code>SMB_FS_OBJECTID_INFORMATION</code> request contains 48 bytes of "extended information". Samba version 3.2 or later will return a <code>samba_extended_info_version</code> structure in this field.<br />
<br />
<pre><br />
/* Used in SMB_FS_OBJECTID_INFORMATION requests. Must be exactly 48 bytes. */<br />
#define SAMBA_EXTENDED_INFO_MAGIC 0x536d4261 /* "SmBa" */<br />
#define SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH 28<br />
<br />
struct smb_extended_info {<br />
uint32 samba_magic; /* Always SAMBA_EXTRA_INFO_MAGIC */<br />
uint32 samba_version; /* Major/Minor/Release/Revision */<br />
uint32 samba_subversion; /* Prerelease/RC/Vendor patch */<br />
NTTIME samba_gitcommitdate;<br />
char samba_version_string[SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH];<br />
};<br />
<br />
</pre><br />
<br />
This extension was first proposed in [http://marc.info/?t=120058872100007&r=1&w=2 this samba-technical thread].<br />
Like most (all?) SMB structures it is marshalled without any "holes" for<br />
alignment.<br />
<br />
== Storing symlinks on Windows servers ==<br />
<br />
=== Minshall+French symlinks ===<br />
Steve French and Conrad Minshall defined a file format for storing Unix symlinks on SMB volumes. This shall forever be known as the Minshall+French format.<br />
<br />
http://www.opensource.apple.com/darwinsource/10.5.1/smb-345/kernel/fs/smbfs/smbfs_vnops.c<br />
<br />
see smbfs_windows_readlink() and smbfs_create_windows_symlink_data()<br />
<br />
The Minshall+French format is a sequence of newline separated fields:<br />
<br />
<pre><br />
XSym\n<br />
char len[]\n<br />
char md5sum[32]\n<br />
char target[len]\n<br />
</pre><br />
<br />
* XSym: the literal ASCII characters 'X', 'S', 'y', 'm'<br />
* len: the length of the symlink target name as an ASCII string, with leading 0's<br />
* md5sum: The MD5 hash of the link target name<br />
* target: the link target path<br />
<br />
=== Extended Attribute symlinks ===<br />
<br />
http://marc.info/?l=samba-technical&m=120229726332475&w=2<br />
<br />
== SMB transport encryption ==<br />
(under construction)</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=3358UNIX Extensions2008-02-06T21:37:30Z<p>Jpeach: /* Storing symlinks on Windows servers */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x001<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x002<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x004<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x008<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x010 || All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x020<br />
|-<br />
|| CIFS_UNIX_LARGE_READ_CAP || 0x040 || We can cope with 24 bit reads in readX.<br />
|-<br />
|| CIFS_UNIX_LARGE_WRITE_CAP || 0x080 || We can cope with 24 bit writes in writeX.<br />
|-<br />
|| CIFS_UNIX_TRANSPORT_ENCRYPTION_CAP || 0x100 || We can do SPNEGO negotiations for encryption.<br />
|-<br />
||CIFS_UNIX_TRANSPORT_ENCRYPTION_MANDATORY_CAP || 0x200 || We *must* SPNEGO negotiations for encryption.<br />
|-<br />
|}<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
If the DOS readonly bit is set on the file, the unlink must fail.<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|| SMB_REQUEST_TRANSPORT_ENCRYPTION || 0x203 || Call to set up an encryption context.<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.<br />
<br />
== Samba server version information ==<br />
<br />
The data returned by the trans2 <code>SMB_FS_OBJECTID_INFORMATION</code> request contains 48 bytes of "extended information". Samba version 3.2 or later will return a <code>samba_extended_info_version</code> structure in this field.<br />
<br />
<pre><br />
/* Used in SMB_FS_OBJECTID_INFORMATION requests. Must be exactly 48 bytes. */<br />
#define SAMBA_EXTENDED_INFO_MAGIC 0x536d4261 /* "SmBa" */<br />
#define SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH 28<br />
<br />
struct smb_extended_info {<br />
uint32 samba_magic; /* Always SAMBA_EXTRA_INFO_MAGIC */<br />
uint32 samba_version; /* Major/Minor/Release/Revision */<br />
uint32 samba_subversion; /* Prerelease/RC/Vendor patch */<br />
NTTIME samba_gitcommitdate;<br />
char samba_version_string[SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH];<br />
};<br />
<br />
</pre><br />
<br />
This extension was first proposed in [http://marc.info/?t=120058872100007&r=1&w=2 this samba-technical thread].<br />
Like most (all?) SMB structures it is marshalled without any "holes" for<br />
alignment.<br />
<br />
== Storing symlinks on Windows servers ==<br />
<br />
=== Minshall+French symlinks ===<br />
Steve French and Conrad Minshall defined a file format for storing Unix symlinks on SMB volumes. This shall forever be known as the Minshall+French format.<br />
<br />
http://www.opensource.apple.com/darwinsource/10.5.1/smb-345/kernel/fs/smbfs/smbfs_vnops.c<br />
<br />
see smbfs_windows_readlink() and smbfs_create_windows_symlink_data()<br />
<br />
The Minshall+French format is a sequence of newline separated fields:<br />
<br />
<pre><br />
XSym\n<br />
char len[]\n<br />
char md5sum[32]\n<br />
char target[len]\n<br />
</pre><br />
<br />
* XSym: the literal ASCII characters 'X', 'S', 'y', 'm'<br />
* len: the length of the symlink target name as an ASCII string, with leading 0's<br />
* md5sum: The MD5 hash of the link target name<br />
* target: the link target path<br />
<br />
== SMB transport encryption ==<br />
(under construction)</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=3357UNIX Extensions2008-02-06T18:33:27Z<p>Jpeach: /* Storing symlinks on Windows servers */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x001<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x002<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x004<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x008<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x010 || All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x020<br />
|-<br />
|| CIFS_UNIX_LARGE_READ_CAP || 0x040 || We can cope with 24 bit reads in readX.<br />
|-<br />
|| CIFS_UNIX_LARGE_WRITE_CAP || 0x080 || We can cope with 24 bit writes in writeX.<br />
|-<br />
|| CIFS_UNIX_TRANSPORT_ENCRYPTION_CAP || 0x100 || We can do SPNEGO negotiations for encryption.<br />
|-<br />
||CIFS_UNIX_TRANSPORT_ENCRYPTION_MANDATORY_CAP || 0x200 || We *must* SPNEGO negotiations for encryption.<br />
|-<br />
|}<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
If the DOS readonly bit is set on the file, the unlink must fail.<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|| SMB_REQUEST_TRANSPORT_ENCRYPTION || 0x203 || Call to set up an encryption context.<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.<br />
<br />
== Samba server version information ==<br />
<br />
The data returned by the trans2 <code>SMB_FS_OBJECTID_INFORMATION</code> request contains 48 bytes of "extended information". Samba version 3.2 or later will return a <code>samba_extended_info_version</code> structure in this field.<br />
<br />
<pre><br />
/* Used in SMB_FS_OBJECTID_INFORMATION requests. Must be exactly 48 bytes. */<br />
#define SAMBA_EXTENDED_INFO_MAGIC 0x536d4261 /* "SmBa" */<br />
#define SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH 28<br />
<br />
struct smb_extended_info {<br />
uint32 samba_magic; /* Always SAMBA_EXTRA_INFO_MAGIC */<br />
uint32 samba_version; /* Major/Minor/Release/Revision */<br />
uint32 samba_subversion; /* Prerelease/RC/Vendor patch */<br />
NTTIME samba_gitcommitdate;<br />
char samba_version_string[SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH];<br />
};<br />
<br />
</pre><br />
<br />
This extension was first proposed in [http://marc.info/?t=120058872100007&r=1&w=2 this samba-technical thread].<br />
Like most (all?) SMB structures it is marshalled without any "holes" for<br />
alignment.<br />
<br />
== Storing symlinks on Windows servers ==<br />
<br />
Steve French and Conrad Minshall defined a file format for storing Unix symlinks on SMB volumes. This shall forever be known as the French+Minshall format.<br />
<br />
http://www.opensource.apple.com/darwinsource/10.5.1/smb-345/kernel/fs/smbfs/smbfs_vnops.c<br />
<br />
see smbfs_windows_readlink() and smbfs_create_windows_symlink_data()<br />
<br />
The French+Minshall format is a sequence of newline separated fields:<br />
<br />
<pre><br />
XSym\n<br />
char len[]\n<br />
char md5sum[32]\n<br />
char target[len]\n<br />
</pre><br />
<br />
* XSym: the literal ASCII characters 'X', 'S', 'y', 'm'<br />
* len: the length of the symlink target name as an ASCII string, with leading 0's<br />
* md5sum: The MD5 hash of the link target name<br />
* target: the link target path<br />
<br />
== SMB transport encryption ==<br />
(under construction)</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=3356UNIX Extensions2008-02-06T18:32:35Z<p>Jpeach: /* Storing symlinks on Windows servers */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x001<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x002<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x004<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x008<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x010 || All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x020<br />
|-<br />
|| CIFS_UNIX_LARGE_READ_CAP || 0x040 || We can cope with 24 bit reads in readX.<br />
|-<br />
|| CIFS_UNIX_LARGE_WRITE_CAP || 0x080 || We can cope with 24 bit writes in writeX.<br />
|-<br />
|| CIFS_UNIX_TRANSPORT_ENCRYPTION_CAP || 0x100 || We can do SPNEGO negotiations for encryption.<br />
|-<br />
||CIFS_UNIX_TRANSPORT_ENCRYPTION_MANDATORY_CAP || 0x200 || We *must* SPNEGO negotiations for encryption.<br />
|-<br />
|}<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
If the DOS readonly bit is set on the file, the unlink must fail.<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|| SMB_REQUEST_TRANSPORT_ENCRYPTION || 0x203 || Call to set up an encryption context.<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.<br />
<br />
== Samba server version information ==<br />
<br />
The data returned by the trans2 <code>SMB_FS_OBJECTID_INFORMATION</code> request contains 48 bytes of "extended information". Samba version 3.2 or later will return a <code>samba_extended_info_version</code> structure in this field.<br />
<br />
<pre><br />
/* Used in SMB_FS_OBJECTID_INFORMATION requests. Must be exactly 48 bytes. */<br />
#define SAMBA_EXTENDED_INFO_MAGIC 0x536d4261 /* "SmBa" */<br />
#define SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH 28<br />
<br />
struct smb_extended_info {<br />
uint32 samba_magic; /* Always SAMBA_EXTRA_INFO_MAGIC */<br />
uint32 samba_version; /* Major/Minor/Release/Revision */<br />
uint32 samba_subversion; /* Prerelease/RC/Vendor patch */<br />
NTTIME samba_gitcommitdate;<br />
char samba_version_string[SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH];<br />
};<br />
<br />
</pre><br />
<br />
This extension was first proposed in [http://marc.info/?t=120058872100007&r=1&w=2 this samba-technical thread].<br />
Like most (all?) SMB structures it is marshalled without any "holes" for<br />
alignment.<br />
<br />
== Storing symlinks on Windows servers ==<br />
<br />
Steve French and Conrad Minshall defined a file format for storing Unix symlinks on SMB volumes. This shall forever be known as the French+Minshall format.<br />
<br />
http://www.opensource.apple.com/darwinsource/10.5.1/smb-345/kernel/fs/smbfs/smbfs_vnops.c<br />
<br />
see smbfs_windows_readlink() and smbfs_create_windows_symlink_data()<br />
<br />
The French+Minshall format is a sequence of newline separated fields:<br />
<br />
<pre><br />
XSym\n<br />
char len[]\n<br />
char md5sum[32]\n<br />
char target[len]\n<br />
<br />
XSym: the literal ASCII characters 'X', 'S', 'y', 'm'<br />
len: the length of the symlink target name as an ASCII string, with leading 0's<br />
md5sum: The MD5 hash of the link target name<br />
target: the link target path<br />
</pre><br />
<br />
== SMB transport encryption ==<br />
(under construction)</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=3355UNIX Extensions2008-02-06T17:40:00Z<p>Jpeach: </p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x001<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x002<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x004<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x008<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x010 || All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x020<br />
|-<br />
|| CIFS_UNIX_LARGE_READ_CAP || 0x040 || We can cope with 24 bit reads in readX.<br />
|-<br />
|| CIFS_UNIX_LARGE_WRITE_CAP || 0x080 || We can cope with 24 bit writes in writeX.<br />
|-<br />
|| CIFS_UNIX_TRANSPORT_ENCRYPTION_CAP || 0x100 || We can do SPNEGO negotiations for encryption.<br />
|-<br />
||CIFS_UNIX_TRANSPORT_ENCRYPTION_MANDATORY_CAP || 0x200 || We *must* SPNEGO negotiations for encryption.<br />
|-<br />
|}<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
If the DOS readonly bit is set on the file, the unlink must fail.<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|| SMB_REQUEST_TRANSPORT_ENCRYPTION || 0x203 || Call to set up an encryption context.<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.<br />
<br />
== Samba server version information ==<br />
<br />
The data returned by the trans2 <code>SMB_FS_OBJECTID_INFORMATION</code> request contains 48 bytes of "extended information". Samba version 3.2 or later will return a <code>samba_extended_info_version</code> structure in this field.<br />
<br />
<pre><br />
/* Used in SMB_FS_OBJECTID_INFORMATION requests. Must be exactly 48 bytes. */<br />
#define SAMBA_EXTENDED_INFO_MAGIC 0x536d4261 /* "SmBa" */<br />
#define SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH 28<br />
<br />
struct smb_extended_info {<br />
uint32 samba_magic; /* Always SAMBA_EXTRA_INFO_MAGIC */<br />
uint32 samba_version; /* Major/Minor/Release/Revision */<br />
uint32 samba_subversion; /* Prerelease/RC/Vendor patch */<br />
NTTIME samba_gitcommitdate;<br />
char samba_version_string[SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH];<br />
};<br />
<br />
</pre><br />
<br />
This extension was first proposed in [http://marc.info/?t=120058872100007&r=1&w=2 this samba-technical thread].<br />
Like most (all?) SMB structures it is marshalled without any "holes" for<br />
alignment.<br />
<br />
== Storing symlinks on Windows servers ==<br />
<br />
Steve French and Conrad Minshall defined a file format for storing Unix symlinks on SMB volumes. This shall forever be known as the French+Minshall format.<br />
<br />
http://www.opensource.apple.com/darwinsource/10.5.1/smb-345/kernel/fs/smbfs/smbfs_vnops.c<br />
<br />
see smbfs_windows_readlink() and smbfs_create_windows_symlink_data()<br />
<br />
== SMB transport encryption ==<br />
(under construction)</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=3351UNIX Extensions2008-01-22T21:06:05Z<p>Jpeach: tidy hex alignment</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x001<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x002<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x004<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x008<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x010 || All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x020<br />
|-<br />
|| CIFS_UNIX_LARGE_READ_CAP || 0x040 || We can cope with 24 bit reads in readX.<br />
|-<br />
|| CIFS_UNIX_LARGE_WRITE_CAP || 0x080 || We can cope with 24 bit writes in writeX.<br />
|-<br />
|| CIFS_UNIX_TRANSPORT_ENCRYPTION_CAP || 0x100 || We can do SPNEGO negotiations for encryption.<br />
|-<br />
||CIFS_UNIX_TRANSPORT_ENCRYPTION_MANDATORY_CAP || 0x200 || We *must* SPNEGO negotiations for encryption.<br />
|-<br />
|}<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
If the DOS readonly bit is set on the file, the unlink must fail.<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|| SMB_REQUEST_TRANSPORT_ENCRYPTION || 0x203 || Call to set up an encryption context.<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.<br />
<br />
== Samba server version information ==<br />
<br />
The data returned by the trans2 <code>SMB_FS_OBJECTID_INFORMATION</code> request contains 48 bytes of "extended information". Samba version 3.2 or later will return a <code>samba_extended_info_version</code> structure in this field.<br />
<br />
<pre><br />
/* Used in SMB_FS_OBJECTID_INFORMATION requests. Must be exactly 48 bytes. */<br />
#define SAMBA_EXTENDED_INFO_MAGIC 0x536d4261 /* "SmBa" */<br />
#define SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH 28<br />
<br />
struct smb_extended_info {<br />
uint32 samba_magic; /* Always SAMBA_EXTRA_INFO_MAGIC */<br />
uint32 samba_version; /* Major/Minor/Release/Revision */<br />
uint32 samba_subversion; /* Prerelease/RC/Vendor patch */<br />
NTTIME samba_gitcommitdate;<br />
char samba_version_string[SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH];<br />
};<br />
<br />
</pre><br />
<br />
This extension was first proposed in [http://marc.info/?t=120058872100007&r=1&w=2 this samba-technical thread].<br />
<br />
== SMB transport encrpytion ==<br />
(under construction)</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=3350UNIX Extensions2008-01-22T20:47:59Z<p>Jpeach: fix typo</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x10 || All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|-<br />
|| CIFS_UNIX_LARGE_READ_CAP || 0x40 || We can cope with 24 bit reads in readX.<br />
|-<br />
|| CIFS_UNIX_LARGE_WRITE_CAP || 0x80 || We can cope with 24 bit writes in writeX.<br />
|-<br />
|| CIFS_UNIX_TRANSPORT_ENCRYPTION_CAP || 0x100 || We can do SPNEGO negotiations for encryption.<br />
|-<br />
||CIFS_UNIX_TRANSPORT_ENCRYPTION_MANDATORY_CAP || 0x200 || We *must* SPNEGO negotiations for encryption.<br />
|-<br />
|}<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
If the DOS readonly bit is set on the file, the unlink must fail.<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|| SMB_REQUEST_TRANSPORT_ENCRYPTION || 0x203 || Call to set up an encryption context.<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.<br />
<br />
== Samba server version information ==<br />
<br />
The data returned by the trans2 <code>SMB_FS_OBJECTID_INFORMATION</code> request contains 48 bytes of "extended information". Samba version 3.2 or later will return a <code>samba_extended_info_version</code> structure in this field.<br />
<br />
<pre><br />
/* Used in SMB_FS_OBJECTID_INFORMATION requests. Must be exactly 48 bytes. */<br />
#define SAMBA_EXTENDED_INFO_MAGIC 0x536d4261 /* "SmBa" */<br />
#define SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH 28<br />
<br />
struct smb_extended_info {<br />
uint32 samba_magic; /* Always SAMBA_EXTRA_INFO_MAGIC */<br />
uint32 samba_version; /* Major/Minor/Release/Revision */<br />
uint32 samba_subversion; /* Prerelease/RC/Vendor patch */<br />
NTTIME samba_gitcommitdate;<br />
char samba_version_string[SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH];<br />
};<br />
<br />
</pre><br />
<br />
This extension was first proposed in [http://marc.info/?t=120058872100007&r=1&w=2 this samba-technical thread].<br />
<br />
== SMB transport encrpytion ==<br />
(under construction)</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=3344UNIX Extensions2008-01-22T19:35:27Z<p>Jpeach: /* Samba server version information */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x10 || All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|-<br />
|| CIFS_UNIX_LARGE_READ_CAP || 0x40 || We can cope with 24 bit reads in readX.<br />
|-<br />
|| CIFS_UNIX_LARGE_WRITE_CAP || 0x80 || We can cope with 24 bit writes in writeX.<br />
|-<br />
|| CIFS_UNIX_TRANSPORT_ENCRYPTION_CAP || 0x100 || We can do SPNEGO negotiations for encryption.<br />
|-<br />
||CIFS_UNIX_TRANSPORT_ENCRYPTION_MANDATORY_CAP || 0x200 || We *must* SPNEGO negotiations for encryption.<br />
|-<br />
|}<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
If the DOS readonly bit is set on the file, the unlink must fail.<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.<br />
<br />
== Samba server version information ==<br />
<br />
The data returned by the trans2 <code>SMB_FS_OBJECTID_INFORMATION</code> request contains 48 bytes of "extended informaion". Samba version 3.2 or later will return a <code>samba_extended_info_version</code> structure in this field.<br />
<br />
<pre><br />
/* Used in SMB_FS_OBJECTID_INFORMATION requests. Must be exactly 48 bytes. */<br />
#define SAMBA_EXTENDED_INFO_MAGIC 0x536d4261 /* "SmBa" */<br />
#define SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH 28<br />
<br />
struct smb_extended_info {<br />
uint32 samba_magic; /* Always SAMBA_EXTRA_INFO_MAGIC */<br />
uint32 samba_version; /* Major/Minor/Release/Revision */<br />
uint32 samba_subversion; /* Prerelease/RC/Vendor patch */<br />
NTTIME samba_gitcommitdate;<br />
char samba_version_string[SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH];<br />
};<br />
<br />
</pre><br />
<br />
This extension was first proposed in [http://marc.info/?t=120058872100007&r=1&w=2 this samba-technical thread].</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=3343UNIX Extensions2008-01-22T19:31:39Z<p>Jpeach: /* Samba server version information */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x10 || All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|-<br />
|| CIFS_UNIX_LARGE_READ_CAP || 0x40 || We can cope with 24 bit reads in readX.<br />
|-<br />
|| CIFS_UNIX_LARGE_WRITE_CAP || 0x80 || We can cope with 24 bit writes in writeX.<br />
|-<br />
|| CIFS_UNIX_TRANSPORT_ENCRYPTION_CAP || 0x100 || We can do SPNEGO negotiations for encryption.<br />
|-<br />
||CIFS_UNIX_TRANSPORT_ENCRYPTION_MANDATORY_CAP || 0x200 || We *must* SPNEGO negotiations for encryption.<br />
|-<br />
|}<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
If the DOS readonly bit is set on the file, the unlink must fail.<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.<br />
<br />
== Samba server version information ==<br />
<br />
The data returned by the trans2 <code>SMB_FS_OBJECTID_INFORMATION</code> request contains 48 bytes of "extended informaion". Samba version 3.2 or later vill return a <code>samba_extended_info_version</code> structure in this field.<br />
<br />
<pre><br />
/* Used in SMB_FS_OBJECTID_INFORMATION requests. Must be exactly 48 bytes. */<br />
#define SAMBA_EXTENDED_INFO_MAGIC 0x536d4261 /* "SmBa" */<br />
#define SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH 28<br />
<br />
struct smb_extended_info {<br />
uint32 samba_magic; /* Always SAMBA_EXTRA_INFO_MAGIC */<br />
uint32 samba_version; /* Major/Minor/Release/Revision */<br />
uint32 samba_subversion; /* Prerelease/RC/Vendor patch */<br />
NTTIME samba_gitcommitdate;<br />
char samba_version_string[SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH];<br />
};<br />
<br />
</pre></div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=3342UNIX Extensions2008-01-22T19:31:22Z<p>Jpeach: /* Samba server version information */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x10 || All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|-<br />
|| CIFS_UNIX_LARGE_READ_CAP || 0x40 || We can cope with 24 bit reads in readX.<br />
|-<br />
|| CIFS_UNIX_LARGE_WRITE_CAP || 0x80 || We can cope with 24 bit writes in writeX.<br />
|-<br />
|| CIFS_UNIX_TRANSPORT_ENCRYPTION_CAP || 0x100 || We can do SPNEGO negotiations for encryption.<br />
|-<br />
||CIFS_UNIX_TRANSPORT_ENCRYPTION_MANDATORY_CAP || 0x200 || We *must* SPNEGO negotiations for encryption.<br />
|-<br />
|}<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
If the DOS readonly bit is set on the file, the unlink must fail.<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.<br />
<br />
== Samba server version information ==<br />
<br />
The data returned by the trans2 <code>SMB_FS_OBJECTID_INFORMATION</code> request contains 48 bytes of "extended informaion". Samba version 3.2 or later vill return a <code>samba_extended_info_version</code> structure in this field.<br />
<br />
<code><br />
/* Used in SMB_FS_OBJECTID_INFORMATION requests. Must be exactly 48 bytes. */<br />
#define SAMBA_EXTENDED_INFO_MAGIC 0x536d4261 /* "SmBa" */<br />
#define SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH 28<br />
<br />
struct smb_extended_info {<br />
uint32 samba_magic; /* Always SAMBA_EXTRA_INFO_MAGIC */<br />
uint32 samba_version; /* Major/Minor/Release/Revision */<br />
uint32 samba_subversion; /* Prerelease/RC/Vendor patch */<br />
NTTIME samba_gitcommitdate;<br />
char samba_version_string[SAMBA_EXTENDED_INFO_VERSION_STRING_LENGTH];<br />
};<br />
<br />
</code></div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=3341UNIX Extensions2008-01-22T19:26:33Z<p>Jpeach: </p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x10 || All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|-<br />
|| CIFS_UNIX_LARGE_READ_CAP || 0x40 || We can cope with 24 bit reads in readX.<br />
|-<br />
|| CIFS_UNIX_LARGE_WRITE_CAP || 0x80 || We can cope with 24 bit writes in writeX.<br />
|-<br />
|| CIFS_UNIX_TRANSPORT_ENCRYPTION_CAP || 0x100 || We can do SPNEGO negotiations for encryption.<br />
|-<br />
||CIFS_UNIX_TRANSPORT_ENCRYPTION_MANDATORY_CAP || 0x200 || We *must* SPNEGO negotiations for encryption.<br />
|-<br />
|}<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
If the DOS readonly bit is set on the file, the unlink must fail.<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.<br />
<br />
== Samba server version information ==</div>Jpeachhttps://wiki.samba.org/index.php?title=Using_Git_for_Samba_Development&diff=3293Using Git for Samba Development2007-10-15T20:19:34Z<p>Jpeach: /* FAQ */</p>
<hr />
<div>The previous pages based on the git-svn mirror can be found at [[Using Git-SVN for Samba4 Development]]<br />
<br />
<br />
<br />
== Overview ==<br />
<br />
Samba source code is now hosted in a shared git repository to which all existing Samba Team members are allow to push to. If you are a Team member and do not have an account on git.samba.org, please email the team list and let the appropriate people know. This shared repository has the same work flow as was used when the SCM of choice was Subversion. In other words, you develop in your local tree and push to the repo although is not necessary to push after every commit. This should be a familiar work flow for those who have used svk.<br />
<br />
<br />
== Git Installation ==<br />
<br />
* The git source code is available from [http://www.kernel.org/pub/software/scm/git/ http://www.kernel.org/pub/software/scm/git/].<br />
* The project home page is located at [http://git.or.cz/ http://git.or.cz/].<br />
* You should probably familiarize yourself with the [http://www.kernel.org/pub/software/scm/git/docs/tutorial.html Git tutorial].<br />
<br />
The examples in the following sections are based off of the tools and syntax used by git v1.5.3 or later which is the recommended version for Samba. Either apt-get, yum, or make install the tools. See [http://www.kernel.org/pub/software/scm/git/ Git documentation] for more details on this part.<br />
<br />
Note that under Debian or Ubuntu, git is distributed in the git-core package. The git package contains the "GNU Interactive Tools". <br />
<br />
If you are using the Ubuntu Feisty Fawn release, the version of git-core in the official repositories is woefully out of date. A more recent version can be installed by adding the feisty-backports repository to your sources.list file:<br />
<br />
deb http://archive.ubuntu.com/ubuntu feisty-backports main universe multiverse restricted<br />
<br />
If you are on OS X, both [http://macports.org/ MacPorts] and [http://finkproject.org/ Fink] contain working binary packages of Git. Building Git from source on OS X works fine, but resolving the chain of dependencies for asciidoc (which is needed to build the man pages) is very painful.<br />
<br />
== Basic Samba Git ==<br />
<br />
<br />
The master git repository is located at ''git://git.samba.org/samba.git''. There is also a [http://gitweb.samba.org/ GitWeb installation].<br />
<br />
'''WARNING:''' ''git://git.samba.org/samba.git'' was previously a git-svn mirror. The mirror has been moved to ''git://git.samba.org/samba-svnmirror.git''.<br />
<br />
Step Zero is to set your name and email address for commits:<br />
<br />
$ git config --global user.email Your.Email@domain.com<br />
$ git config --global user.name "Your Real Name"<br />
<br />
Next, clone the repository:<br />
<br />
$ git-clone git://git.samba.org/samba.git samba<br />
Initialized empty Git repository in /home/AD/gcarter/src/git/tmp/samba/.git/<br />
remote: Generating pack...<br />
remote: Done counting 440544 objects.<br />
remote: Deltifying 440544 objects...<br />
remote: 100% (440544/440544) done<br />
Indexing 440544 objects...<br />
remote: Total 440544 (delta 340808), reused 436199 (delta 336480)<br />
100% (440544/440544) done<br />
Resolving 340808 deltas...<br />
100% (340808/340808) done<br />
$ cd samba<br />
<br />
List local and remote branches:<br />
$ git-branch<br />
* v3-2-stable<br />
<br />
$ git-branch -r<br />
origin/HEAD<br />
origin/v2-2-stable<br />
origin/v2-2-test<br />
origin/v3-0-stable<br />
origin/v3-0-test<br />
origin/v3-2-stable<br />
origin/v3-2-test<br />
origin/v4-0-stable<br />
origin/v4-0-test<br />
<br />
Listing tags matching release-3-0-3*<br />
$ git-tag -l release-3-0-3*<br />
release-3-0-3<br />
release-3-0-3pre1<br />
release-3-0-3pre2<br />
release-3-0-3rc1<br />
<br />
Creating your own working branch from v3-2-test:<br />
$ git-checkout -b my_branch origin/v3-2-test<br />
Branch my_branch set up to track remote branch refs/remotes/origin/v3-2-test.<br />
Switched to a new branch "my_branch"<br />
<br />
Do your own local work:<br />
$ mkdir git-test<br />
$ echo "hello" > git-test/README<br />
<br />
View status of changes<br />
$ git-status<br />
# On branch my_branch<br />
# Untracked files:<br />
# (use "git add <file>..." to include in what will be committed)<br />
# <br />
# git-test/<br />
nothing added to commit but untracked files present (use "git add" to track)<br />
<br />
Add our new file to the local branch index:<br />
$ git add git-test<br />
$ git status<br />
# On branch my_branch<br />
# Changes to be committed:<br />
# (use "git reset HEAD <file>..." to unstage)<br />
#<br />
# new file: git-test/README<br />
#<br />
<br />
Commit changes<br />
$ git commit -m "Example file for HOWTO"<br />
Created commit ad9a1eb: Example file for HOWTO<br />
1 files changed, 1 insertions(+), 0 deletions(-)<br />
create mode 100644 git-test/README<br />
<br />
Do some more work and commit local changes....<br />
<br />
Now fetch the remote branch history:<br />
$ git-fetch <br />
<br />
Merging remote branch changes:<br />
$ git-merge origin/v3-2-test<br />
Already up-to-date.<br />
<br />
Push the changes to the shared repository<br />
$ git push ssh://git.samba.org/data/git/samba.git my_branch:v3-2-test<br />
updating 'refs/heads/v3-2-test' using 'refs/heads/my_branch'<br />
from f2252e041e075e19bf27e53ab3ed62f39bc8b3e2<br />
to ad9a1eb599c125964ac3e198d3003841edb4c54e<br />
Generating pack...<br />
Done counting 5 objects.<br />
Result has 4 objects.<br />
Deltifying 4 objects...<br />
100% (4/4) done<br />
Writing 4 objects...<br />
100% (4/4) done<br />
Total 4 (delta 1), reused 0 (delta 0)<br />
refs/heads/v3-2-test: f2252e041e075e19bf27e53ab3ed62f39bc8b3e2 -> ad9a1eb599c125964ac3e198d3003841edb4c54e<br />
<br />
== Explanation of Branches ==<br />
<br />
The simplest way to explain the existing shared branches is to associate them with the previous SVN ones.<br />
<br />
* The *-unstable tags point to the matching SAMBA_X_X branch (e.g. SAMBA_3_2 or SAMBA_4_0) at the time of the migration. These are now tags an not branches so you cannot push to them. Instead, your local work should be done in a local branch and pushed when completed. There is no need to push works-in-progress any longer unless you require some specific testing by the buildfarm.<br />
* The *-test branches correspond to the release series dev branch (e.g. SAMBA_3_2_0). Anyone may check into these branches.<br />
* The *-stable branches are used for release purposes similar tothe SAMBA_X_X_RELEASE branches in SVN. These are under the control of the currentl release manager for a given release series.<br />
<br />
<br />
== FAQ ==<br />
<br />
'''Q.''' How do I revert a commit?<br />
<br />
'''A.''' The git-reset command allows you to reset the HEAD of the branch to any given point in history. To go back one commit, run "git-reset HEAD^". This will keep your local changes and you can make any additional changes before re-commiting the new work. Also see the "git-commit --amend" command and the "git-reset" man page for other examples.<br />
<br />
<br />
'''Q.''' Is there a shorthand for git-push <URL> <local_repo:remote_repo>?<br />
<br />
'''A.''' Yes. You can define a [remote "upstream"] section in your local repos .git/config file.<br />
<br />
$ git-config remote.origin.url ssh://git.samba.org/data/git/samba.git<br />
$ git-config remote.origin.push my_branch:v3-2-test<br />
$ cat .git/config<br />
...<br />
[remote "origin"]<br />
url = ssh://git.samba.org/data/git/samba.git<br />
fetch = +refs/heads/*:refs/remotes/origin/*<br />
push = my_branch:v3-2-test<br />
[branch "my_branch"]<br />
remote = origin<br />
merge = refs/heads/v3-2-test<br />
<br />
<br />
'''Q.''' How can I have access to the old CVS and SVN imported repositories via GIT without creating additional cloned repos?<br />
<br />
'''A.''' You can add remote tracking repositories using git-remote:<br />
<br />
$ git-remote add cvs git://git.samba.org/import/samba-cvsimport.git<br />
$ git-fetch cvs<br />
remote: Generating pack...<br />
remote: Done counting 7070 objects.<br />
Result has 5004 objects.<br />
remote: Deltifying 5004 objects...<br />
remote: 100% (5004/5004) done<br />
Indexing 5004 objects...<br />
remote: Total 5004 (delta 3836), reused 4098 (delta 3044)<br />
100% (5004/5004) done<br />
Resolving 3836 deltas...<br />
100% (3836/3836) done<br />
461 objects were added to complete this thin pack.<br />
* refs/remotes/cvs/APPLIANCE_HEAD: storing branch 'APPLIANCE_HEAD' of git:// git.samba.org/import/samba-cvsimport<br />
commit: af0e201<br />
<br />
You can then see the remote branches using "git-branch -r" and work with them in the same way you did for the "origin" branches obtained in the initial git-clone.<br />
<br />
'''Q.''' How can I maintain a feature branch against the upstream Samba branches?<br />
<br />
'''A.''' You clone the Samba repository as per the instructions above. Then you make a new feature branch from v3-2-test:<br />
$ git-branch feature/foo v3-2-test<br />
<br />
Now you do your development in your feature branch. Any time the v3-2-test branch gets too different to the code in your feature branch you should rebase your feature branch. The rebase rewinds your feature branch to the point there it was branched. Then it updates you feature branch to the HEAD of the v3-2-test branch and re-applies your changes.<br />
<br />
$ git rebase v3-2-test<br />
First, rewinding head to replay your work on top of it...<br />
HEAD is now at 357f003... Add WERR_SERVICE_ALREADY_RUNNING.<br />
...<br />
Wrote tree 02299ef7c1cfa093248bfd9c6e3812805718845e<br />
Committed: e20a8c521d7860d9b7bd724ed5ea19c7306530ab<br />
<br />
Rebase works best when you use it for local branches that are never pushed to a public repository, see [http://git.or.cz/gitwiki/GitFaq#head-c1dc263aca199d347f28872249e6c1f5d519a2df Why won't "git push" work after I rebased a branch?].</div>Jpeachhttps://wiki.samba.org/index.php?title=Using_Git_for_Samba_Development&diff=3292Using Git for Samba Development2007-10-15T20:11:02Z<p>Jpeach: /* FAQ */</p>
<hr />
<div>The previous pages based on the git-svn mirror can be found at [[Using Git-SVN for Samba4 Development]]<br />
<br />
<br />
<br />
== Overview ==<br />
<br />
Samba source code is now hosted in a shared git repository to which all existing Samba Team members are allow to push to. If you are a Team member and do not have an account on git.samba.org, please email the team list and let the appropriate people know. This shared repository has the same work flow as was used when the SCM of choice was Subversion. In other words, you develop in your local tree and push to the repo although is not necessary to push after every commit. This should be a familiar work flow for those who have used svk.<br />
<br />
<br />
== Git Installation ==<br />
<br />
* The git source code is available from [http://www.kernel.org/pub/software/scm/git/ http://www.kernel.org/pub/software/scm/git/].<br />
* The project home page is located at [http://git.or.cz/ http://git.or.cz/].<br />
* You should probably familiarize yourself with the [http://www.kernel.org/pub/software/scm/git/docs/tutorial.html Git tutorial].<br />
<br />
The examples in the following sections are based off of the tools and syntax used by git v1.5.3 or later which is the recommended version for Samba. Either apt-get, yum, or make install the tools. See [http://www.kernel.org/pub/software/scm/git/ Git documentation] for more details on this part.<br />
<br />
Note that under Debian or Ubuntu, git is distributed in the git-core package. The git package contains the "GNU Interactive Tools". <br />
<br />
If you are using the Ubuntu Feisty Fawn release, the version of git-core in the official repositories is woefully out of date. A more recent version can be installed by adding the feisty-backports repository to your sources.list file:<br />
<br />
deb http://archive.ubuntu.com/ubuntu feisty-backports main universe multiverse restricted<br />
<br />
If you are on OS X, both [http://macports.org/ MacPorts] and [http://finkproject.org/ Fink] contain working binary packages of Git. Building Git from source on OS X works fine, but resolving the chain of dependencies for asciidoc (which is needed to build the man pages) is very painful.<br />
<br />
== Basic Samba Git ==<br />
<br />
<br />
The master git repository is located at ''git://git.samba.org/samba.git''. There is also a [http://gitweb.samba.org/ GitWeb installation].<br />
<br />
'''WARNING:''' ''git://git.samba.org/samba.git'' was previously a git-svn mirror. The mirror has been moved to ''git://git.samba.org/samba-svnmirror.git''.<br />
<br />
Step Zero is to set your name and email address for commits:<br />
<br />
$ git config --global user.email Your.Email@domain.com<br />
$ git config --global user.name "Your Real Name"<br />
<br />
Next, clone the repository:<br />
<br />
$ git-clone git://git.samba.org/samba.git samba<br />
Initialized empty Git repository in /home/AD/gcarter/src/git/tmp/samba/.git/<br />
remote: Generating pack...<br />
remote: Done counting 440544 objects.<br />
remote: Deltifying 440544 objects...<br />
remote: 100% (440544/440544) done<br />
Indexing 440544 objects...<br />
remote: Total 440544 (delta 340808), reused 436199 (delta 336480)<br />
100% (440544/440544) done<br />
Resolving 340808 deltas...<br />
100% (340808/340808) done<br />
$ cd samba<br />
<br />
List local and remote branches:<br />
$ git-branch<br />
* v3-2-stable<br />
<br />
$ git-branch -r<br />
origin/HEAD<br />
origin/v2-2-stable<br />
origin/v2-2-test<br />
origin/v3-0-stable<br />
origin/v3-0-test<br />
origin/v3-2-stable<br />
origin/v3-2-test<br />
origin/v4-0-stable<br />
origin/v4-0-test<br />
<br />
Listing tags matching release-3-0-3*<br />
$ git-tag -l release-3-0-3*<br />
release-3-0-3<br />
release-3-0-3pre1<br />
release-3-0-3pre2<br />
release-3-0-3rc1<br />
<br />
Creating your own working branch from v3-2-test:<br />
$ git-checkout -b my_branch origin/v3-2-test<br />
Branch my_branch set up to track remote branch refs/remotes/origin/v3-2-test.<br />
Switched to a new branch "my_branch"<br />
<br />
Do your own local work:<br />
$ mkdir git-test<br />
$ echo "hello" > git-test/README<br />
<br />
View status of changes<br />
$ git-status<br />
# On branch my_branch<br />
# Untracked files:<br />
# (use "git add <file>..." to include in what will be committed)<br />
# <br />
# git-test/<br />
nothing added to commit but untracked files present (use "git add" to track)<br />
<br />
Add our new file to the local branch index:<br />
$ git add git-test<br />
$ git status<br />
# On branch my_branch<br />
# Changes to be committed:<br />
# (use "git reset HEAD <file>..." to unstage)<br />
#<br />
# new file: git-test/README<br />
#<br />
<br />
Commit changes<br />
$ git commit -m "Example file for HOWTO"<br />
Created commit ad9a1eb: Example file for HOWTO<br />
1 files changed, 1 insertions(+), 0 deletions(-)<br />
create mode 100644 git-test/README<br />
<br />
Do some more work and commit local changes....<br />
<br />
Now fetch the remote branch history:<br />
$ git-fetch <br />
<br />
Merging remote branch changes:<br />
$ git-merge origin/v3-2-test<br />
Already up-to-date.<br />
<br />
Push the changes to the shared repository<br />
$ git push ssh://git.samba.org/data/git/samba.git my_branch:v3-2-test<br />
updating 'refs/heads/v3-2-test' using 'refs/heads/my_branch'<br />
from f2252e041e075e19bf27e53ab3ed62f39bc8b3e2<br />
to ad9a1eb599c125964ac3e198d3003841edb4c54e<br />
Generating pack...<br />
Done counting 5 objects.<br />
Result has 4 objects.<br />
Deltifying 4 objects...<br />
100% (4/4) done<br />
Writing 4 objects...<br />
100% (4/4) done<br />
Total 4 (delta 1), reused 0 (delta 0)<br />
refs/heads/v3-2-test: f2252e041e075e19bf27e53ab3ed62f39bc8b3e2 -> ad9a1eb599c125964ac3e198d3003841edb4c54e<br />
<br />
== Explanation of Branches ==<br />
<br />
The simplest way to explain the existing shared branches is to associate them with the previous SVN ones.<br />
<br />
* The *-unstable tags point to the matching SAMBA_X_X branch (e.g. SAMBA_3_2 or SAMBA_4_0) at the time of the migration. These are now tags an not branches so you cannot push to them. Instead, your local work should be done in a local branch and pushed when completed. There is no need to push works-in-progress any longer unless you require some specific testing by the buildfarm.<br />
* The *-test branches correspond to the release series dev branch (e.g. SAMBA_3_2_0). Anyone may check into these branches.<br />
* The *-stable branches are used for release purposes similar tothe SAMBA_X_X_RELEASE branches in SVN. These are under the control of the currentl release manager for a given release series.<br />
<br />
<br />
== FAQ ==<br />
<br />
'''Q.''' How do I revert a commit?<br />
<br />
'''A.''' The git-reset command allows you to reset the HEAD of the branch to any given point in history. To go back one commit, run "git-reset HEAD^". This will keep your local changes and you can make any additional changes before re-commiting the new work. Also see the "git-commit --amend" command and the "git-reset" man page for other examples.<br />
<br />
<br />
'''Q.''' Is there a shorthand for git-push <URL> <local_repo:remote_repo>?<br />
<br />
'''A.''' Yes. You can define a [remote "upstream"] section in your local repos .git/config file.<br />
<br />
$ git-config remote.origin.url ssh://git.samba.org/data/git/samba.git<br />
$ git-config remote.origin.push my_branch:v3-2-test<br />
$ cat .git/config<br />
...<br />
[remote "origin"]<br />
url = ssh://git.samba.org/data/git/samba.git<br />
fetch = +refs/heads/*:refs/remotes/origin/*<br />
push = my_branch:v3-2-test<br />
[branch "my_branch"]<br />
remote = origin<br />
merge = refs/heads/v3-2-test<br />
<br />
<br />
'''Q.''' How can I have access to the old CVS and SVN imported repositories via GIT without creating additional cloned repos?<br />
<br />
'''A.''' You can add remote tracking repositories using git-remote:<br />
<br />
$ git-remote add cvs git://git.samba.org/import/samba-cvsimport.git<br />
$ git-fetch cvs<br />
remote: Generating pack...<br />
remote: Done counting 7070 objects.<br />
Result has 5004 objects.<br />
remote: Deltifying 5004 objects...<br />
remote: 100% (5004/5004) done<br />
Indexing 5004 objects...<br />
remote: Total 5004 (delta 3836), reused 4098 (delta 3044)<br />
100% (5004/5004) done<br />
Resolving 3836 deltas...<br />
100% (3836/3836) done<br />
461 objects were added to complete this thin pack.<br />
* refs/remotes/cvs/APPLIANCE_HEAD: storing branch 'APPLIANCE_HEAD' of git:// git.samba.org/import/samba-cvsimport<br />
commit: af0e201<br />
<br />
You can then see the remote branches using "git-branch -r" and work with them in the same way you did for the "origin" branches obtained in the initial git-clone.<br />
<br />
'''Q.''' How can I maintain a feature branch against the upstream Samba branches?<br />
<br />
'''A.''' You clone the Samba repository as per the instructions above. Then you make a new feature branch from v3-2-test:<br />
$ git-branch feature/foo v3-2-test<br />
<br />
Now you do your development in your feature branch. Any time the v3-2-test branch gets too different to the code in your feature branch you should rebase your feature branch. The rebase rewinds your feature branch to the point there it was branched. Then it updates you feature branch to the HEAD of the v3-2-test branch and re-applies your changes.<br />
<br />
$ git rebase v3-2-test<br />
First, rewinding head to replay your work on top of it...<br />
HEAD is now at 357f003... Add WERR_SERVICE_ALREADY_RUNNING.<br />
...<br />
Wrote tree 02299ef7c1cfa093248bfd9c6e3812805718845e<br />
Committed: e20a8c521d7860d9b7bd724ed5ea19c7306530ab</div>Jpeachhttps://wiki.samba.org/index.php?title=Using_Git_for_Samba_Development&diff=3289Using Git for Samba Development2007-10-12T18:41:53Z<p>Jpeach: /* Git Installation */</p>
<hr />
<div>The previous pages based on the git-svn mirror can be found at [[Using Git-SVN for Samba4 Development]]<br />
<br />
<br />
<br />
== Overview ==<br />
<br />
Samba source code is now hosted in a shared git repository to which all existing Samba Team members are allow to push to. If you are a Team member and do not have an account on git.samba.org, please email the team list and let the appropriate people know. This shared repository has the same work flow as was used when the SCM of choice was Subversion. In other words, you develop in your local tree and push to the repo although is not necessary to push after every commit. This should be a familiar work flow for those who have used svk.<br />
<br />
<br />
== Git Installation ==<br />
<br />
* The git source code is available from [http://www.kernel.org/pub/software/scm/git/ http://www.kernel.org/pub/software/scm/git/].<br />
* The project home page is located at [http://git.or.cz/ http://git.or.cz/].<br />
* You should probably familiarize yourself with the [http://www.kernel.org/pub/software/scm/git/docs/tutorial.html Git tutorial].<br />
<br />
The examples in the following sections are based off of the tools and syntax used by git v1.5.3 or later which is the recommended version for Samba. Either apt-get, yum, or make install the tools. See [http://www.kernel.org/pub/software/scm/git/ Git documentation] for more details on this part.<br />
<br />
Note that under Debian or Ubuntu, git is distributed in the git-core package. The git package contains the "GNU Interactive Tools". <br />
<br />
If you are using the Ubuntu Feisty Fawn release, the version of git-core in the official repositories is woefully out of date. A more recent version can be installed by adding the feisty-backports repository to your sources.list file:<br />
<br />
deb http://archive.ubuntu.com/ubuntu feisty-backports main universe multiverse restricted<br />
<br />
If you are on OS X, both [http://macports.org/ MacPorts] and [http://finkproject.org/ Fink] contain working binary packages of Git. Building Git from source on OS X works fine, but resolving the chain of dependencies for asciidoc (which is needed to build the man pages) is very painful.<br />
<br />
== Basic Samba Git ==<br />
<br />
<br />
The master git repository is located at ''git://git.samba.org/samba.git''. There is also a [http://gitweb.samba.org/ GitWeb installation].<br />
<br />
'''WARNING:''' ''git://git.samba.org/samba.git'' was previously a git-svn mirror. The mirror has been moved to ''git://git.samba.org/samba-svnmirror.git''.<br />
<br />
Step Zero is to set your name and email address for commits:<br />
<br />
$ git config --global user.email Your.Email@domain.com<br />
$ git config --global user.name "Your Real Name"<br />
<br />
Next, clone the repository:<br />
<br />
$ git-clone git://git.samba.org/samba.git samba<br />
Initialized empty Git repository in /home/AD/gcarter/src/git/tmp/samba/.git/<br />
remote: Generating pack...<br />
remote: Done counting 440544 objects.<br />
remote: Deltifying 440544 objects...<br />
remote: 100% (440544/440544) done<br />
Indexing 440544 objects...<br />
remote: Total 440544 (delta 340808), reused 436199 (delta 336480)<br />
100% (440544/440544) done<br />
Resolving 340808 deltas...<br />
100% (340808/340808) done<br />
$ cd samba<br />
<br />
List local and remote branches:<br />
$ git-branch<br />
* v3-2-stable<br />
<br />
$ git-branch -r<br />
origin/HEAD<br />
origin/v2-2-stable<br />
origin/v2-2-test<br />
origin/v3-0-stable<br />
origin/v3-0-test<br />
origin/v3-2-stable<br />
origin/v3-2-test<br />
origin/v4-0-stable<br />
origin/v4-0-test<br />
<br />
Listing tags matching release-3-0-3*<br />
$ git-tag -l release-3-0-3*<br />
release-3-0-3<br />
release-3-0-3pre1<br />
release-3-0-3pre2<br />
release-3-0-3rc1<br />
<br />
Creating your own working branch from v3-2-test:<br />
$ git-checkout -b my_branch origin/v3-2-test<br />
Branch my_branch set up to track remote branch refs/remotes/origin/v3-2-test.<br />
Switched to a new branch "my_branch"<br />
<br />
Do your own local work:<br />
$ mkdir git-test<br />
$ echo "hello" > git-test/README<br />
<br />
View status of changes<br />
$ git-status<br />
# On branch my_branch<br />
# Untracked files:<br />
# (use "git add <file>..." to include in what will be committed)<br />
# <br />
# git-test/<br />
nothing added to commit but untracked files present (use "git add" to track)<br />
<br />
Add our new file to the local branch index:<br />
$ git add git-test<br />
$ git status<br />
# On branch my_branch<br />
# Changes to be committed:<br />
# (use "git reset HEAD <file>..." to unstage)<br />
#<br />
# new file: git-test/README<br />
#<br />
<br />
Commit changes<br />
$ git commit -m "Example file for HOWTO"<br />
Created commit ad9a1eb: Example file for HOWTO<br />
1 files changed, 1 insertions(+), 0 deletions(-)<br />
create mode 100644 git-test/README<br />
<br />
Do some more work and commit local changes....<br />
<br />
Now fetch the remote branch history:<br />
$ git-fetch <br />
<br />
Merging remote branch changes:<br />
$ git-merge origin/v3-2-test<br />
Already up-to-date.<br />
<br />
Push the changes to the shared repository<br />
$ git push ssh://git.samba.org/data/git/samba.git my_branch:v3-2-test<br />
updating 'refs/heads/v3-2-test' using 'refs/heads/my_branch'<br />
from f2252e041e075e19bf27e53ab3ed62f39bc8b3e2<br />
to ad9a1eb599c125964ac3e198d3003841edb4c54e<br />
Generating pack...<br />
Done counting 5 objects.<br />
Result has 4 objects.<br />
Deltifying 4 objects...<br />
100% (4/4) done<br />
Writing 4 objects...<br />
100% (4/4) done<br />
Total 4 (delta 1), reused 0 (delta 0)<br />
refs/heads/v3-2-test: f2252e041e075e19bf27e53ab3ed62f39bc8b3e2 -> ad9a1eb599c125964ac3e198d3003841edb4c54e<br />
<br />
== Explanation of Branches ==<br />
<br />
The simplest way to explain the existing shared branches is to associate them with the previous SVN ones.<br />
<br />
* The *-unstable tags point to the matching SAMBA_X_X branch (e.g. SAMBA_3_2 or SAMBA_4_0) at the time of the migration. These are now tags an not branches so you cannot push to them. Instead, your local work should be done in a local branch and pushed when completed. There is no need to push works-in-progress any longer unless you require some specific testing by the buildfarm.<br />
* The *-test branches correspond to the release series dev branch (e.g. SAMBA_3_2_0). Anyone may check into these branches.<br />
* The *-stable branches are used for release purposes similar tothe SAMBA_X_X_RELEASE branches in SVN. These are under the control of the currentl release manager for a given release series.<br />
<br />
<br />
== FAQ ==<br />
<br />
'''Q.''' How do I revert a commit?<br />
<br />
'''A.''' The git-reset command allows you to reset the HEAD of the branch to any given point in history. To go back one commit, run "git-reset HEAD^". This will keep your local changes and you can make any additional changes before re-commiting the new work. Also see the "git-commit --amend" command and the "git-reset" man page for other examples.<br />
<br />
<br />
'''Q.''' Is there a shorthand for git-push <URL> <local_repo:remote_repo>?<br />
<br />
'''A.''' Yes. You can define a [remote "upstream"] section in your local repos .git/config file.<br />
<br />
$ git-config remote.origin.url ssh://git.samba.org/data/git/samba.git<br />
$ git-config remote.origin.push my_branch:v3-2-test<br />
$ cat .git/config<br />
...<br />
[remote "origin"]<br />
url = ssh://git.samba.org/data/git/samba.git<br />
fetch = +refs/heads/*:refs/remotes/origin/*<br />
push = my_branch:v3-2-test<br />
[branch "my_branch"]<br />
remote = origin<br />
merge = refs/heads/v3-2-test<br />
<br />
<br />
'''Q.''' How can I have access to the old CVS and SVN imported repositories via GIT without creating additional cloned repos?<br />
<br />
'''A.''' You can add remote tracking repositories using git-remote:<br />
<br />
$ git-remote add cvs git://git.samba.org/import/samba-cvsimport.git<br />
$ git-fetch cvs<br />
remote: Generating pack...<br />
remote: Done counting 7070 objects.<br />
Result has 5004 objects.<br />
remote: Deltifying 5004 objects...<br />
remote: 100% (5004/5004) done<br />
Indexing 5004 objects...<br />
remote: Total 5004 (delta 3836), reused 4098 (delta 3044)<br />
100% (5004/5004) done<br />
Resolving 3836 deltas...<br />
100% (3836/3836) done<br />
461 objects were added to complete this thin pack.<br />
* refs/remotes/cvs/APPLIANCE_HEAD: storing branch 'APPLIANCE_HEAD' of git:// git.samba.org/import/samba-cvsimport<br />
commit: af0e201<br />
<br />
You can then see the remote branches using "git-branch -r" and work with them in the same way you did for the "origin" branches obtained in the initial git-clone.</div>Jpeachhttps://wiki.samba.org/index.php?title=Using_Git_for_Samba_Development&diff=3288Using Git for Samba Development2007-10-12T18:41:30Z<p>Jpeach: /* Git Installation */</p>
<hr />
<div>The previous pages based on the git-svn mirror can be found at [[Using Git-SVN for Samba4 Development]]<br />
<br />
<br />
<br />
== Overview ==<br />
<br />
Samba source code is now hosted in a shared git repository to which all existing Samba Team members are allow to push to. If you are a Team member and do not have an account on git.samba.org, please email the team list and let the appropriate people know. This shared repository has the same work flow as was used when the SCM of choice was Subversion. In other words, you develop in your local tree and push to the repo although is not necessary to push after every commit. This should be a familiar work flow for those who have used svk.<br />
<br />
<br />
== Git Installation ==<br />
<br />
* The git source code is available from [http://www.kernel.org/pub/software/scm/git/ http://www.kernel.org/pub/software/scm/git/].<br />
* The project home page is located at [http://git.or.cz/ http://git.or.cz/].<br />
* You should probably familiarize yourself with the [http://www.kernel.org/pub/software/scm/git/docs/tutorial.html Git tutorial].<br />
<br />
The examples in the following sections are based off of the tools and syntax used by git v1.5.3 or later which is the recommended version for Samba. Either apt-get, yum, or make install the tools. See [http://www.kernel.org/pub/software/scm/git/ Git documentation] for more details on this part.<br />
<br />
Note that under Debian or Ubuntu, git is distributed in the git-core package. The git package contains the "GNU Interactive Tools". <br />
<br />
If you are using the Ubuntu Feisty Fawn release, the version of git-core in the official repositories is woefully out of date. A more recent version can be installed by adding the feisty-backports repository to your sources.list file:<br />
<br />
deb http://archive.ubuntu.com/ubuntu feisty-backports main universe multiverse restricted<br />
<br />
If you are on OS X, both [http://macports.org/ MacPorts] and [http://finkproject.org/ Fink] contain working binary packages of Git. Building Git from source on OS X works find, but resolving the chain of dependencies for asciidoc (which is needed to build the man pages) is very painful.<br />
<br />
== Basic Samba Git ==<br />
<br />
<br />
The master git repository is located at ''git://git.samba.org/samba.git''. There is also a [http://gitweb.samba.org/ GitWeb installation].<br />
<br />
'''WARNING:''' ''git://git.samba.org/samba.git'' was previously a git-svn mirror. The mirror has been moved to ''git://git.samba.org/samba-svnmirror.git''.<br />
<br />
Step Zero is to set your name and email address for commits:<br />
<br />
$ git config --global user.email Your.Email@domain.com<br />
$ git config --global user.name "Your Real Name"<br />
<br />
Next, clone the repository:<br />
<br />
$ git-clone git://git.samba.org/samba.git samba<br />
Initialized empty Git repository in /home/AD/gcarter/src/git/tmp/samba/.git/<br />
remote: Generating pack...<br />
remote: Done counting 440544 objects.<br />
remote: Deltifying 440544 objects...<br />
remote: 100% (440544/440544) done<br />
Indexing 440544 objects...<br />
remote: Total 440544 (delta 340808), reused 436199 (delta 336480)<br />
100% (440544/440544) done<br />
Resolving 340808 deltas...<br />
100% (340808/340808) done<br />
$ cd samba<br />
<br />
List local and remote branches:<br />
$ git-branch<br />
* v3-2-stable<br />
<br />
$ git-branch -r<br />
origin/HEAD<br />
origin/v2-2-stable<br />
origin/v2-2-test<br />
origin/v3-0-stable<br />
origin/v3-0-test<br />
origin/v3-2-stable<br />
origin/v3-2-test<br />
origin/v4-0-stable<br />
origin/v4-0-test<br />
<br />
Listing tags matching release-3-0-3*<br />
$ git-tag -l release-3-0-3*<br />
release-3-0-3<br />
release-3-0-3pre1<br />
release-3-0-3pre2<br />
release-3-0-3rc1<br />
<br />
Creating your own working branch from v3-2-test:<br />
$ git-checkout -b my_branch origin/v3-2-test<br />
Branch my_branch set up to track remote branch refs/remotes/origin/v3-2-test.<br />
Switched to a new branch "my_branch"<br />
<br />
Do your own local work:<br />
$ mkdir git-test<br />
$ echo "hello" > git-test/README<br />
<br />
View status of changes<br />
$ git-status<br />
# On branch my_branch<br />
# Untracked files:<br />
# (use "git add <file>..." to include in what will be committed)<br />
# <br />
# git-test/<br />
nothing added to commit but untracked files present (use "git add" to track)<br />
<br />
Add our new file to the local branch index:<br />
$ git add git-test<br />
$ git status<br />
# On branch my_branch<br />
# Changes to be committed:<br />
# (use "git reset HEAD <file>..." to unstage)<br />
#<br />
# new file: git-test/README<br />
#<br />
<br />
Commit changes<br />
$ git commit -m "Example file for HOWTO"<br />
Created commit ad9a1eb: Example file for HOWTO<br />
1 files changed, 1 insertions(+), 0 deletions(-)<br />
create mode 100644 git-test/README<br />
<br />
Do some more work and commit local changes....<br />
<br />
Now fetch the remote branch history:<br />
$ git-fetch <br />
<br />
Merging remote branch changes:<br />
$ git-merge origin/v3-2-test<br />
Already up-to-date.<br />
<br />
Push the changes to the shared repository<br />
$ git push ssh://git.samba.org/data/git/samba.git my_branch:v3-2-test<br />
updating 'refs/heads/v3-2-test' using 'refs/heads/my_branch'<br />
from f2252e041e075e19bf27e53ab3ed62f39bc8b3e2<br />
to ad9a1eb599c125964ac3e198d3003841edb4c54e<br />
Generating pack...<br />
Done counting 5 objects.<br />
Result has 4 objects.<br />
Deltifying 4 objects...<br />
100% (4/4) done<br />
Writing 4 objects...<br />
100% (4/4) done<br />
Total 4 (delta 1), reused 0 (delta 0)<br />
refs/heads/v3-2-test: f2252e041e075e19bf27e53ab3ed62f39bc8b3e2 -> ad9a1eb599c125964ac3e198d3003841edb4c54e<br />
<br />
== Explanation of Branches ==<br />
<br />
The simplest way to explain the existing shared branches is to associate them with the previous SVN ones.<br />
<br />
* The *-unstable tags point to the matching SAMBA_X_X branch (e.g. SAMBA_3_2 or SAMBA_4_0) at the time of the migration. These are now tags an not branches so you cannot push to them. Instead, your local work should be done in a local branch and pushed when completed. There is no need to push works-in-progress any longer unless you require some specific testing by the buildfarm.<br />
* The *-test branches correspond to the release series dev branch (e.g. SAMBA_3_2_0). Anyone may check into these branches.<br />
* The *-stable branches are used for release purposes similar tothe SAMBA_X_X_RELEASE branches in SVN. These are under the control of the currentl release manager for a given release series.<br />
<br />
<br />
== FAQ ==<br />
<br />
'''Q.''' How do I revert a commit?<br />
<br />
'''A.''' The git-reset command allows you to reset the HEAD of the branch to any given point in history. To go back one commit, run "git-reset HEAD^". This will keep your local changes and you can make any additional changes before re-commiting the new work. Also see the "git-commit --amend" command and the "git-reset" man page for other examples.<br />
<br />
<br />
'''Q.''' Is there a shorthand for git-push <URL> <local_repo:remote_repo>?<br />
<br />
'''A.''' Yes. You can define a [remote "upstream"] section in your local repos .git/config file.<br />
<br />
$ git-config remote.origin.url ssh://git.samba.org/data/git/samba.git<br />
$ git-config remote.origin.push my_branch:v3-2-test<br />
$ cat .git/config<br />
...<br />
[remote "origin"]<br />
url = ssh://git.samba.org/data/git/samba.git<br />
fetch = +refs/heads/*:refs/remotes/origin/*<br />
push = my_branch:v3-2-test<br />
[branch "my_branch"]<br />
remote = origin<br />
merge = refs/heads/v3-2-test<br />
<br />
<br />
'''Q.''' How can I have access to the old CVS and SVN imported repositories via GIT without creating additional cloned repos?<br />
<br />
'''A.''' You can add remote tracking repositories using git-remote:<br />
<br />
$ git-remote add cvs git://git.samba.org/import/samba-cvsimport.git<br />
$ git-fetch cvs<br />
remote: Generating pack...<br />
remote: Done counting 7070 objects.<br />
Result has 5004 objects.<br />
remote: Deltifying 5004 objects...<br />
remote: 100% (5004/5004) done<br />
Indexing 5004 objects...<br />
remote: Total 5004 (delta 3836), reused 4098 (delta 3044)<br />
100% (5004/5004) done<br />
Resolving 3836 deltas...<br />
100% (3836/3836) done<br />
461 objects were added to complete this thin pack.<br />
* refs/remotes/cvs/APPLIANCE_HEAD: storing branch 'APPLIANCE_HEAD' of git:// git.samba.org/import/samba-cvsimport<br />
commit: af0e201<br />
<br />
You can then see the remote branches using "git-branch -r" and work with them in the same way you did for the "origin" branches obtained in the initial git-clone.</div>Jpeachhttps://wiki.samba.org/index.php?title=Using_Git_for_Samba_Development&diff=3287Using Git for Samba Development2007-10-12T16:49:07Z<p>Jpeach: /* Git Installation */</p>
<hr />
<div>The previous pages based on the git-svn mirror can be found at [[Using Git-SVN for Samba4 Development]]<br />
<br />
<br />
<br />
== Overview ==<br />
<br />
Samba source code is now hosted in a shared git repository to which all existing Samba Team members are allow to push to. If you are a Team member and do not have an account on git.samba.org, please email the team list and let the appropriate people know. This shared repository has the same work flow as was used when the SCM of choice was Subversion. In other words, you develop in your local tree and push to the repo although is not necessary to push after every commit. This should be a familiar work flow for those who have used svk.<br />
<br />
<br />
== Git Installation ==<br />
<br />
* The git source code is available from [http://www.kernel.org/pub/software/scm/git/ http://www.kernel.org/pub/software/scm/git/].<br />
* The project home page is located at [http://git.or.cz/ http://git.or.cz/].<br />
* You should probably familiarize yourself with the [http://www.kernel.org/pub/software/scm/git/docs/tutorial.html Git tutorial].<br />
<br />
The examples in the following sections are based off of the tools and syntax used by git v1.5.3 or later which is the recommended version for Samba. Either apt-get, yum, or make install the tools. See [http://www.kernel.org/pub/software/scm/git/ Git documentation] for more details on this part.<br />
<br />
Note that under Debian or Ubuntu, git is distributed in the git-core package. The git package contains the "GNU Interactive Tools". <br />
<br />
If you are using the Ubuntu Feisty Fawn release, the version of git-core in the official repositories is woefully out of date. A more recent version can be installed by adding the feisty-backports repository to your sources.list file:<br />
<br />
deb http://archive.ubuntu.com/ubuntu feisty-backports main universe multiverse restricted<br />
<br />
If you are on OS X, both [MacPorts http://macports.org/] and [Fink http://finkproject.org/] contain working binary packages of Git. Building Git from source on OS X works find, but resolving the chain of dependencies for asciidoc (which is needed to build the man pages) is very painful.<br />
<br />
== Basic Samba Git ==<br />
<br />
<br />
The master git repository is located at ''git://git.samba.org/samba.git''. There is also a [http://gitweb.samba.org/ GitWeb installation].<br />
<br />
'''WARNING:''' ''git://git.samba.org/samba.git'' was previously a git-svn mirror. The mirror has been moved to ''git://git.samba.org/samba-svnmirror.git''.<br />
<br />
Step Zero is to set your name and email address for commits:<br />
<br />
$ git config --global user.email Your.Email@domain.com<br />
$ git config --global user.name "Your Real Name"<br />
<br />
Next, clone the repository:<br />
<br />
$ git-clone git://git.samba.org/samba.git samba<br />
Initialized empty Git repository in /home/AD/gcarter/src/git/tmp/samba/.git/<br />
remote: Generating pack...<br />
remote: Done counting 440544 objects.<br />
remote: Deltifying 440544 objects...<br />
remote: 100% (440544/440544) done<br />
Indexing 440544 objects...<br />
remote: Total 440544 (delta 340808), reused 436199 (delta 336480)<br />
100% (440544/440544) done<br />
Resolving 340808 deltas...<br />
100% (340808/340808) done<br />
$ cd samba<br />
<br />
List local and remote branches:<br />
$ git-branch<br />
* v3-2-stable<br />
<br />
$ git-branch -r<br />
origin/HEAD<br />
origin/v2-2-stable<br />
origin/v2-2-test<br />
origin/v3-0-stable<br />
origin/v3-0-test<br />
origin/v3-2-stable<br />
origin/v3-2-test<br />
origin/v4-0-stable<br />
origin/v4-0-test<br />
<br />
Listing tags matching release-3-0-3*<br />
$ git-tag -l release-3-0-3*<br />
release-3-0-3<br />
release-3-0-3pre1<br />
release-3-0-3pre2<br />
release-3-0-3rc1<br />
<br />
Creating your own working branch from v3-2-test:<br />
$ git-checkout -b my_branch origin/v3-2-test<br />
Branch my_branch set up to track remote branch refs/remotes/origin/v3-2-test.<br />
Switched to a new branch "my_branch"<br />
<br />
Do your own local work:<br />
$ mkdir git-test<br />
$ echo "hello" > git-test/README<br />
<br />
View status of changes<br />
$ git-status<br />
# On branch my_branch<br />
# Untracked files:<br />
# (use "git add <file>..." to include in what will be committed)<br />
# <br />
# git-test/<br />
nothing added to commit but untracked files present (use "git add" to track)<br />
<br />
Add our new file to the local branch index:<br />
$ git add git-test<br />
$ git status<br />
# On branch my_branch<br />
# Changes to be committed:<br />
# (use "git reset HEAD <file>..." to unstage)<br />
#<br />
# new file: git-test/README<br />
#<br />
<br />
Commit changes<br />
$ git commit -m "Example file for HOWTO"<br />
Created commit ad9a1eb: Example file for HOWTO<br />
1 files changed, 1 insertions(+), 0 deletions(-)<br />
create mode 100644 git-test/README<br />
<br />
Do some more work and commit local changes....<br />
<br />
Now fetch the remote branch history:<br />
$ git-fetch <br />
<br />
Merging remote branch changes:<br />
$ git-merge origin/v3-2-test<br />
Already up-to-date.<br />
<br />
Push the changes to the shared repository<br />
$ git push ssh://git.samba.org/data/git/samba.git my_branch:v3-2-test<br />
updating 'refs/heads/v3-2-test' using 'refs/heads/my_branch'<br />
from f2252e041e075e19bf27e53ab3ed62f39bc8b3e2<br />
to ad9a1eb599c125964ac3e198d3003841edb4c54e<br />
Generating pack...<br />
Done counting 5 objects.<br />
Result has 4 objects.<br />
Deltifying 4 objects...<br />
100% (4/4) done<br />
Writing 4 objects...<br />
100% (4/4) done<br />
Total 4 (delta 1), reused 0 (delta 0)<br />
refs/heads/v3-2-test: f2252e041e075e19bf27e53ab3ed62f39bc8b3e2 -> ad9a1eb599c125964ac3e198d3003841edb4c54e<br />
<br />
== Explanation of Branches ==<br />
<br />
The simplest way to explain the existing shared branches is to associate them with the previous SVN ones.<br />
<br />
* The *-unstable tags point to the matching SAMBA_X_X branch (e.g. SAMBA_3_2 or SAMBA_4_0) at the time of the migration. These are now tags an not branches so you cannot push to them. Instead, your local work should be done in a local branch and pushed when completed. There is no need to push works-in-progress any longer unless you require some specific testing by the buildfarm.<br />
* The *-test branches correspond to the release series dev branch (e.g. SAMBA_3_2_0). Anyone may check into these branches.<br />
* The *-stable branches are used for release purposes similar tothe SAMBA_X_X_RELEASE branches in SVN. These are under the control of the currentl release manager for a given release series.<br />
<br />
<br />
== FAQ ==<br />
<br />
'''Q.''' How do I revert a commit?<br />
<br />
'''A.''' The git-reset command allows you to reset the HEAD of the branch to any given point in history. To go back one commit, run "git-reset HEAD^". This will keep your local changes and you can make any additional changes before re-commiting the new work. Also see the "git-commit --amend" command and the "git-reset" man page for other examples.<br />
<br />
<br />
'''Q.''' Is there a shorthand for git-push <URL> <local_repo:remote_repo>?<br />
<br />
'''A.''' Yes. You can define a [remote "upstream"] section in your local repos .git/config file.<br />
<br />
$ git-config remote.origin.url ssh://git.samba.org/data/git/samba.git<br />
$ git-config remote.origin.push my_branch:v3-2-test<br />
$ cat .git/config<br />
...<br />
[remote "origin"]<br />
url = ssh://git.samba.org/data/git/samba.git<br />
fetch = +refs/heads/*:refs/remotes/origin/*<br />
push = my_branch:v3-2-test<br />
[branch "my_branch"]<br />
remote = origin<br />
merge = refs/heads/v3-2-test<br />
<br />
<br />
'''Q.''' How can I have access to the old CVS and SVN imported repositories via GIT without creating additional cloned repos?<br />
<br />
'''A.''' You can add remote tracking repositories using git-remote:<br />
<br />
$ git-remote add cvs git://git.samba.org/import/samba-cvsimport.git<br />
$ git-fetch cvs<br />
remote: Generating pack...<br />
remote: Done counting 7070 objects.<br />
Result has 5004 objects.<br />
remote: Deltifying 5004 objects...<br />
remote: 100% (5004/5004) done<br />
Indexing 5004 objects...<br />
remote: Total 5004 (delta 3836), reused 4098 (delta 3044)<br />
100% (5004/5004) done<br />
Resolving 3836 deltas...<br />
100% (3836/3836) done<br />
461 objects were added to complete this thin pack.<br />
* refs/remotes/cvs/APPLIANCE_HEAD: storing branch 'APPLIANCE_HEAD' of git:// git.samba.org/import/samba-cvsimport<br />
commit: af0e201<br />
<br />
You can then see the remote branches using "git-branch -r" and work with them in the same way you did for the "origin" branches obtained in the initial git-clone.</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2935UNIX Extensions2007-04-05T22:18:32Z<p>Jpeach: /* Posix Unlink */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x10 All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
If the DOS readonly bit is set on the file, the unlink must fail.<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2917UNIX Extensions2007-03-23T19:23:33Z<p>Jpeach: /* UNIX_INFO2 */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x10 All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (not including any terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (does not include any terminating NULL)<br />
|}<br />
<br />
For FindFirst/FindNext the new UnixInfo2 structure begins (as some of the other FindFirst/FindNext levels do) with <br />
<br />
4 bytes NextEntryOffset<br />
4 bytes ResumeKey<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2912UNIX Extensions2007-03-21T20:53:09Z<p>Jpeach: add name length to UNIX_INFO2 in findfirst reply</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
was included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the capabilties which may be negotiated:<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATHNAMES_CAP || 0x10 All characters except '/' should be supported in pathnames<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value || Description<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_FILE_UNIX_LINK || 0x201 || Part of the initial Unix Extensions<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204 || Requires CIFS_UNIX_POSIX_ACL_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_XATTR || 0x205 || Requires CIFS_UNIX_XATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206 || Requires CIFS_UNIX_EXTATTR_CAP, MUST be supported if set<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208 || Requires CIFS_UNIX_FCNTL_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_OPEN || 0x209 || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, MUST be supported if set<br />
|-<br />
|| SMB_POSIX_PATH_UNLINK || 0x20a || Requires CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP, SHOULD be supported if set<br />
|-<br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20b || Requires CIFS_UNIX_EXTATTR_CAP, SHOULD be supported if set<br />
|}<br />
<br />
<br />
=== Posix Open ===<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (command 0x06) info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 18 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below). (for mkdir specify O_CREAT O_DIRECTORY)<br />
|-<br />
||8 bytes || 8 || POSIX Permissions (see below)<br />
|-<br />
||2 bytes || 16 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
{|<br />
!POSIX permissions !! Value !! Description<br />
|-<br />
|| SMB_PERM_SUID || 0004000 || set UID bit<br />
|-<br />
|| SMB_PERM_SGID || 0002000 || set-group-ID bit<br />
|-<br />
|| SMB_PERM_SVTX || 0001000 || sticky bit<br />
|-<br />
|| SMB_PERM_RUSR || 00400 || owner has read permission<br />
|-<br />
|| SMB_PERM_WUSR || 00200 || owner has write permission<br />
|-<br />
|| SMB_PERM_XUSR || 00100 || owner has execute permission<br />
|-<br />
|| SMB_PERM_RGRP || 00040 || group has read permission<br />
|-<br />
|| SMB_PERM_WGRP || 00020 || group has write permission<br />
|-<br />
|| SMB_PERM_XGRP || 00010 || group has execute permission<br />
|-<br />
|| SMB_PERM_ROTH || 00004 || others have read permission<br />
|-<br />
|| SMB_PERM_WOTH || 00002 || others have write permission<br />
|-<br />
|| SMB_PERM_XOTH || 00001 || others have execute permission<br />
|-<br />
|}<br />
<br />
The response data block varies in length depending on the level requested :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||2 bytes || 0 || Flags field (same flags in as oplock response field in SMBNTCreateX, although bigger field)<br />
|-<br />
||2 bytes || 2 || Network file handle (fid). Zero is returned in this field for mkdir case.<br />
|-<br />
||4 bytes || 4 || CreateAction (same as in NTCreateX response, might not be meaningful for directories)<br />
|-<br />
||2 bytes || 8 || Reply Information level returned (see below)<br />
|-<br />
||2 bytes || 10 || Pad (Must be zero)<br />
|-<br />
|| (sizeof reply information) || 12 || when Reply information level is not SMB_NO_INFO_LEVEL_RETURNED (ie not 0xFFFF)<br />
|}<br />
<br />
TBD: How do we return the Create Action (File Created vs. File Opened)?<br />
<br />
=== Posix Unlink ===<br />
Posix and Windows semantics for unlink of open files are different. POSIX allows deleting<br />
open files (which has the effect of removing them from the directory listing, preventing them<br />
from being opened again, but allowing existing users who have the file open to continue to<br />
read and write from the existing handle(s) until the handle(s) are closed when the inode or<br />
equivalent is deleted from the server).<br />
<br />
<br />
<br />
=== UNIX_INFO2 ===<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}<br />
<br />
Unlike the UNIX_BASIC infolevel, the UNIX_INFO2 infolevel response for FindFirst/FindNext includes a 4 byte name length field immediately before the file name field. The NULL terminator is included in the file name and counted in the name length field.<br />
<br />
SMB_FIND_FILE_UNIX_INFO2 response:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || ULONG || NextEntryOffset || <br />
|-<br />
|| 4 || 4 || ULONG || FileIndex || <br />
|-<br />
|| 116 || 8 || UNIX_INFO2 || UnixInfo2 || UNIX_INFO2 structure as defined above<br />
|-<br />
|| 4 || 124 || ULONG || FileNameLength || length of filename in bytes (including terminating NULL)<br />
|-<br />
|| ... || 128 || STRING || FileName || file name (including terminating NULL)<br />
|}<br />
<br />
=== QUERY_FILE_UNIX_BASIC ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_FILE_UNIX_LINK ===<br />
Described in the SNIA CIFS Technical Reference.<br />
<br />
=== QUERY_POSIX_ACL ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_ATTR_FLAGS ===<br />
<br />
<Under Construction><br />
<br />
For setting file attribute flags (see man page for lsattr/chflags and equivalent)<br />
<br />
Proposed format:<br />
__le64 mask; /* list of all possible attribute bits */<br />
__le64 mode; /* list of actual attribute bits on this inode */<br />
FILE_CHATTR_INFO /* ext attributes (chattr, chflags) level 0x206 */<br />
<br />
=== QUERY_XATTR ===<br />
<br />
<Under Construction><br />
<br />
xattrs (extended attributes) are of the form<br />
namespace.key = value<br />
<br />
<br />
Current xattrs in the "user" (also known as "OS2") namespace can readily map to SMB/CIFS EAs by simply stripping off the "user." in the namespace (prefix) sending only the key and value.<br />
<br />
<br />
Some operating systems define additional classes of extended attribute (name/value pairs) which may be associated with an inode, and are available to be set by administrative users. Such classes of extended attributes include the "trusted" and "security" namespaces.<br />
<br />
Proposed format:<br />
/* Do we need another field for flags? */<br />
__u32 xattr_name_len;<br />
__u32 xattr_value_len;<br />
char xattr_name[0];<br />
/* followed by xattr_value[xattr_value_len], no pad */<br />
FILE_XATTR_INFO /* extended attribute, info level 0x205 */<br />
<br />
Sending attributes in the other namespace categories requires this new trans2 info level.<br />
<br />
Note that the server may associate different default ACL permissions on xattrs in different namespaces on the same inode.<br />
<br />
== New Query/Set FS Info levels: Operations on shares/exports ==<br />
{|<br />
! Info Level Name !! Value !! Description<br />
|-<br />
||SMB_QUERY_CIFS_UNIX_INFO || 0x200 || (Part of the original Unix Extensions)<br />
|-<br />
||SMB_QUERY_POSIX_FS_INFO || 0x201 || <br />
|-<br />
||SMB_QUERY_POSIX_WHO_AM_I || 0x202 || (see below)<br />
|-<br />
|}<br />
<br />
=== QUERY_CIFS_UNIX_INFO ===<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 2 || 0 || Major Version Number<br />
|-<br />
|| 2 || 2 || Minor Version Number<br />
|-<br />
|| 8 || 4 || Capability Flags <br />
|-<br />
|}<br />
<br />
Many current servers return Major Version 1, Minor Version 0<br />
<br />
=== SET_CIFS_UNIX_INFO ===<br />
<br />
<Under Construction><br />
<br />
=== SMB_QUERY_POSIX_FS_INFO ===<br />
The statfs command on many operating systems distinguishes between the number of bytes available on the volume to regular users and the number of bytes available on the volume for administrative users. In addition, the total number of inodes (nodes, vnodes) on the volume, is often reported as well. This new QFS Info level returns sufficient information to fill in the most important fields in the common statfs call.<br />
<br />
{|<br />
! size !! Offset !! Field Description<br />
|-<br />
|| 4 || 0 || Optimal Transfer Size (bsize on some operating systems)<br />
|-<br />
|| 4 || 4 || Blocksize<br />
|-<br />
|| 8 || 8 || Total Blocks <br />
|-<br />
|| 8 || 16 || Blocks Available<br />
|-<br />
|-<br />
|| 8 || 24 || User Blocks Available<br />
|-<br />
|| 8 || 32 || Total File Nodes<br />
|-<br />
|| 8 || 40 || Free File Nodes<br />
|-<br />
|| 8 || 48 || File System Identifier (fsid)<br />
|-<br />
|}<br />
<br />
Note that the other fields in the common form of the local stat call can come from existing QFS Info levels<br />
<br />
=== SMB WHOAMI ===<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid (and optionally the tid) field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== DFS Side Effects ==<br />
The use of reserved path characters such as backslash, colon, question mark and asterisk in DFS referrals can create interoperability problems. Many common clients and servers do not permit such characters in file or directory names. In particular many Windows servers do not support either '\' or '/' in path components.<br />
<br />
Although the CIFS_UNIX_POSIX_PATHNAMES_CAP implied the ability to recognize the backslash ('\') as a valid character in a directory or file name (rather than treating backslash as a path component separator) it was not required, and some common servers also can not handle the backslash within directory names in the response processing for DFS requests (in particular for TRANS2_GET_DFS_REFERRAL, trans2 command 0x10). DFS referrals requests and responses include a pathname which may include multiple levels of subdirectories. When CIFS_UNIX_POSIX_PATHNAMES_CAP is negotiated the server MAY report DFS paths which point to certain target storage servers (those which are known to support CIFS_UNIX_POSIX_PATHNANMES_CAP) as:<br />
\<server>\<share>/directory/subdirectory/more-subdirectories<br />
<br />
If the target storage server type is not known the server MAY canonicalize paths (replacing / with \) and report DFS paths as:<br />
\<server>\<share>\directory\subdirectory\more-subdirectories<br />
since / is not a valid path separator on some target servers. The client can detect that the server has canonicalized paths because the character that immediately follows the share is a '\' rather than a '/' character. Note that share names MUST not contain either the '\' or '/' character.<br />
<br />
Paths which contain components with embedded backslash are expected to be rare in practice.</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2813UNIX Extensions2007-03-08T21:57:40Z<p>Jpeach: /* UNIX_INFO2 */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
== Introduction ==<br />
The Unix Extensions to the CIFS Protocol have been done in stages.<br />
An initial set which included various new infolevels to TRANSACT2 <br />
commands in the range from 0x200 to 0x2FF (inclusive), was available<br />
when:<br />
<br />
CAP_UNIX (0x00800000)<br />
<br />
included in the SMB negotiate protocol response.<br />
<br />
Additional POSIX extensions have been added based on<br />
negotiating individual capabilities on the tree connection<br />
(via a Unix QueryFSInfo and SetFSInfo level). Following<br />
is a list of the previous levels that were available:<br />
<br />
== New File Info (and Path Info) levels ==<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| QUERY_FILE_UNIX_BASIC || 0x200<br />
|-<br />
|| QUERY_FILE_UNIX_LINUX || 0x201<br />
|-<br />
|| QUERY_POSIX_ACL || 0x204<br />
|-<br />
|| QUERY_XATTR || 0x205<br />
|-<br />
|| QUERY_ATTR_FLAGS || 0x206<br />
|-<br />
|| QUERY_POSIX_PERMISSION || 0x207<br />
|-<br />
|| QUERY_POSIX_LOCK || 0x208<br />
|}<br />
<br />
== Negotiating per-share (tree connection) Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNTL_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFSS_UNIX_POSIX_PATHNAMES_CAP || 0x10<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
== Posix Open ==<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== SMB WHOAMI ==<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== UNIX_INFO2 ==<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
If the client is doing a set with the UNIX_INFO2 level and it does not want to alter the FileFlags, it should provide a FileFlagsMask of 0.<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2736UNIX Extensions2007-02-27T22:48:37Z<p>Jpeach: /* UNIX_INFO2 */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
== Posix Open ==<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== SMB WHOAMI ==<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== UNIX_INFO2 ==<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is below. This is deliberately defined to be the same as UNIX_BASIC except for the last 3 fields.<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 8 || 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}<br />
<br />
The defined set of file flags is<br />
<br />
{|<br />
! File Flag || Value || Interpretation<br />
|- <br />
|| EXT_SECURE_DELETE || 0x00000001 || File should be erased such that the data is not recoverable<br />
|-<br />
|| EXT_ENABLE_UNDELETE || 0x00000002 || File should opt-in to a server-specific deletion recovery scheme<br />
|-<br />
|| EXT_SYNCHRONOUS || 0x00000004 || I/O to this file should be performed synchronously<br />
|-<br />
|| EXT_IMMUTABLE || 0x00000008 || NO changes can be made to this file<br />
|-<br />
|| EXT_OPEN_APPEND_ONLY || 0x00000010 || Only appends can be made to this file<br />
|-<br />
|| EXT_DO_NOT_BACKUP || 0x00000020 || Backup programs should ignore this file<br />
|-<br />
|| EXT_NO_UPDATE_ATIME || 0x00000040 || The server is not required to update the last access time on this file<br />
|-<br />
|| EXT_HIDDEN || 0x00000080 || User interface programs may ignore this file<br />
|}</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2735UNIX Extensions2007-02-27T22:39:46Z<p>Jpeach: /* UNIX_INFO2 */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
== Posix Open ==<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== SMB WHOAMI ==<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== UNIX_INFO2 ==<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 8 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 8 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 48|| 16 || LARGE_INTEGER || ChangeTime || Attribute change time<br />
|-<br />
|| 8 || 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 8 || 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 8 || 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 8 || 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 4 || 56 || ULONG || Type || Enumeration specifying the file type<br />
|-<br />
|| 8 || 60 || LARGE_INTEGER|| DevMajor || Major device number if type is device<br />
|-<br />
|| 8 || 68 || LARGE_INTEGER || DevMinor|| Minor device number if type is device<br />
|-<br />
|| 8 || 76 || LARGE_INTEGER || UniqueId || This is a server-assigned unique id<br />
|-<br />
|| 8 || 84 || LARGE_INTEGER || Permissions || Standard UNIX permissions<br />
|-<br />
|| 8 || 92 || LARGE_INTEGER|| NumLinks || Number of hard links<br />
|-<br />
|| 8 || 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 4 || 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 4 || 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2734UNIX Extensions2007-02-27T22:35:28Z<p>Jpeach: /* UNIX_INFO2 */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
== Posix Open ==<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== SMB WHOAMI ==<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== UNIX_INFO2 ==<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level !! Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4 || 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 4 || 8 || LARGE_INTEGER || Blocks || Number of blocks used on disk<br />
|-<br />
|| 16 || LARGE_INTEGER ||ChangeTime || Attribute change time<br />
|-<br />
|| 24 || LARGE_INTEGER || LastAccessTime || Last access time<br />
|-<br />
|| 32 || LARGE_INTEGER || LastModificationTime || Last modification time<br />
|-<br />
|| 40 || LARGE_INTEGER || Uid || Numeric user id for the owner<br />
|-<br />
|| 48 || LARGE_INTEGER || Gid || Numeric group id of owner<br />
|-<br />
|| 56 || ULONG|| Type || Enumeration specifying the file type<br />
|-<br />
|| 60 || LARGE_INTEGER|| devmajor || Major device number if type is device<br />
|-<br />
|| 68 || LARGE_INTEGER ||devminor|| Minor device number if type is device<br />
|-<br />
|| 76 || LARGE_INTEGER ||uniqueid || This is a server-assigned unique id<br />
|-<br />
|| 84 || LARGE_INTEGER ||permissions || Standard UNIX permissions<br />
|-<br />
|| 92 || LARGE_INTEGER|| nlinks || Number of hard link)<br />
|-<br />
|| 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2733UNIX Extensions2007-02-27T22:33:36Z<p>Jpeach: /* UNIX_INFO2 */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
== Posix Open ==<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== SMB WHOAMI ==<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== UNIX_INFO2 ==<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level || Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is:<br />
<br />
{|<br />
! Size !! Offset !! Type !! Name !! Description<br />
|-<br />
|| 4|| 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 4 || 8 || LARGE_INTEGER ||Blocks || Number of blocks used on disk<br />
|-<br />
|| 16 || LARGE_INTEGER ||ChangeTime ||Attribute change time<br />
|-<br />
|| 24 || LARGE_INTEGER ||LastAccessTime || Last access time<br />
|-<br />
|| 32 || LARGE_INTEGER ||LastModificationTime || Last modification time<br />
|-<br />
|| 40 || LARGE_INTEGER ||Uid || Numeric user id for the owner<br />
|-<br />
|| 48 || LARGE_INTEGER ||Gid || Numeric group id of owner<br />
|-<br />
|| 56 || ULONG|| Type || Enumeration specifying the file type<br />
|-<br />
|| 60 || LARGE_INTEGER|| devmajor || Major device number if type is device<br />
|-<br />
|| 68 || LARGE_INTEGER ||devminor|| Minor device number if type is device<br />
|-<br />
|| 76 || LARGE_INTEGER ||uniqueid || This is a server-assigned unique id<br />
|-<br />
|| 84 || LARGE_INTEGER ||permissions || Standard UNIX permissions<br />
|-<br />
|| 92 || LARGE_INTEGER|| nlinks || Number of hard link)<br />
|-<br />
|| 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2732UNIX Extensions2007-02-27T22:33:10Z<p>Jpeach: /* UNIX_INFO2 */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
== Posix Open ==<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== SMB WHOAMI ==<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== UNIX_INFO2 ==<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level || Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is:<br />
<br />
{|<br />
! Size !! Offset !! || Type || Name || Description<br />
|-<br />
|| 4|| 0 || LARGE_INTEGER || EndOfFile || File size<br />
|-<br />
|| 4 || 8 || LARGE_INTEGER ||Blocks || Number of blocks used on disk<br />
|-<br />
|| 16 || LARGE_INTEGER ||ChangeTime ||Attribute change time<br />
|-<br />
|| 24 || LARGE_INTEGER ||LastAccessTime || Last access time<br />
|-<br />
|| 32 || LARGE_INTEGER ||LastModificationTime || Last modification time<br />
|-<br />
|| 40 || LARGE_INTEGER ||Uid || Numeric user id for the owner<br />
|-<br />
|| 48 || LARGE_INTEGER ||Gid || Numeric group id of owner<br />
|-<br />
|| 56 || ULONG|| Type || Enumeration specifying the file type<br />
|-<br />
|| 60 || LARGE_INTEGER|| devmajor || Major device number if type is device<br />
|-<br />
|| 68 || LARGE_INTEGER ||devminor|| Minor device number if type is device<br />
|-<br />
|| 76 || LARGE_INTEGER ||uniqueid || This is a server-assigned unique id<br />
|-<br />
|| 84 || LARGE_INTEGER ||permissions || Standard UNIX permissions<br />
|-<br />
|| 92 || LARGE_INTEGER|| nlinks || Number of hard link)<br />
|-<br />
|| 100 || LARGE_INTEGER|| CreationTime || Create/birth time<br />
|-<br />
|| 108 || ULONG|| FileFlags || File flags enumeration<br />
|-<br />
|| 112 || ULONG ||FileFlagsMask || Mask of valid flags<br />
|}</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2731UNIX Extensions2007-02-27T22:29:00Z<p>Jpeach: /* UNIX_INFO2 */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
== Posix Open ==<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== SMB WHOAMI ==<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== UNIX_INFO2 ==<br />
<br />
The UNIX_INFO2 is an extension to the UNIX_BASIC info level. This info level can be used in FindFirst/FindNext, QueryPathInfo, QueryFileInfo and PosixOpen (but is not restricted to those calls).<br />
<br />
{|<br />
! Info Level || Value<br />
|- <br />
|| SMB_QUERY_FILE_UNIX_INFO2 || 0x20B<br />
|- <br />
|| SMB_SET_FILE_UNIX_INFO2 || 0x20B<br />
|-<br />
|| SMB_FIND_FILE_UNIX_INFO2 || 0x20B<br />
|}<br />
<br />
The response block for the UNIX_INFO2 level is:<br />
<br />
{|<br />
! Size !! Offset !! Description<br />
|}</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2730UNIX Extensions2007-02-27T22:21:59Z<p>Jpeach: /* SMB WHOAMI */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
== Posix Open ==<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== SMB WHOAMI ==<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid field is implicitly used.<br />
<br />
{|<br />
! Info Level Name !! Value<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
|}<br />
<br />
The first two fields of the SMBWhoami response are a set of flags that further describe how the server has mapped the connected user. The mask is returned so that the client can distinguish which flag bits are meaningful.<br />
<br />
{|<br />
!Mapping Flag !! Value !! Interpretation<br />
|-<br />
|| SMB_WHOAMI_GUEST || 0x1 || Logged in as (or squashed to) guest <br />
|}<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
Note that the list of group IDs and DOM_SIDs are both optional. A server may choose not to return these (eg. if the information is expensive to gather). If these are not returned the corresponding count fields must be zero.<br />
<br />
== UNIX_INFO2 ==</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2729UNIX Extensions2007-02-27T22:16:00Z<p>Jpeach: /* SMB WHOAMI */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
== Posix Open ==<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== SMB WHOAMI ==<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid field is implicitly used.<br />
<br />
#define SMB_QUERY_POSIX_WHOAMI 0x202<br />
{|<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
<br />
|}<br />
<br />
<br />
+ SMB_WHOAMI_GUEST = 0x1 /* Logged in as (or squashed to) guest */<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Mapping flags<br />
|-<br />
||4 bytes || 4 || Mask of valid mapping flags<br />
|-<br />
||8 bytes || 8 || Primary user ID<br />
|-<br />
||8 bytes || 16 || Primary group ID<br />
|-<br />
|| 4 bytes || 24 || number of supplementary GIDs<br />
|-<br />
|| 4 bytes || 28 || number of SIDs<br />
|-<br />
|| 4 bytes || 32 || SID list byte count<br />
|-<br />
|| 4 bytes || 36 || Reserved (should be zero)<br />
|-<br />
|| variable || ... || list of 8 byte group IDs (may be empty)<br />
|-<br />
|| variable || ... || List of DOM_SID structures (may be empty)<br />
|}<br />
<br />
== UNIX_INFO2 ==</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2728UNIX Extensions2007-02-27T22:08:48Z<p>Jpeach: /* SMB WHOAMI */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
== Posix Open ==<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== SMB WHOAMI ==<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid field is implicitly used.<br />
<br />
#define SMB_QUERY_POSIX_WHOAMI 0x202<br />
{|<br />
|-<br />
|| SMB_QUERY_POSIX_WHOAMI || 0x202<br />
<br />
|}<br />
<br />
<br />
+ SMB_WHOAMI_GUEST = 0x1 /* Logged in as (or squashed to) guest */<br />
<br />
<br />
+ Returns:<br />
+ 4 bytes unsigned - mapping flags (smb_whoami_flags)<br />
+ 4 bytes unsigned - flags mask<br />
+<br />
+ 8 bytes unsigned - primary UID<br />
+ 8 bytes unsigned - primary GID<br />
+ 4 bytes unsigned - number of supplementary GIDs<br />
+ 4 bytes unsigned - number of SIDs<br />
+ 4 bytes unsigned - SID list byte count<br />
+ 4 bytes - pad / reserved (must be zero)<br />
+<br />
+ 8 bytes unsigned[] - list of GIDs (may be empty)<br />
+ DOM_SID[] - list of SIDs (may be empty)<br />
<br />
== UNIX_INFO2 ==</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2727UNIX Extensions2007-02-27T22:07:36Z<p>Jpeach: /* SMB WHOAMI */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
== Posix Open ==<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== SMB WHOAMI ==<br />
<br />
The SMBWhoami extension is intended to be a lightweight method for a Unix client to be able to display sensible file ownership information.<br />
<br />
SMBWhoami is performed by requesting a TRANS2_QFSINFO with an info level of SMB_QUERY_POSIX_WHOAMI. There are no parameters passed. The vuid field is implicitly used.<br />
<br />
#define SMB_QUERY_POSIX_WHOAMI 0x202<br />
<br />
<br />
+ SMB_WHOAMI_GUEST = 0x1 /* Logged in as (or squashed to) guest */<br />
<br />
<br />
+ Returns:<br />
+ 4 bytes unsigned - mapping flags (smb_whoami_flags)<br />
+ 4 bytes unsigned - flags mask<br />
+<br />
+ 8 bytes unsigned - primary UID<br />
+ 8 bytes unsigned - primary GID<br />
+ 4 bytes unsigned - number of supplementary GIDs<br />
+ 4 bytes unsigned - number of SIDs<br />
+ 4 bytes unsigned - SID list byte count<br />
+ 4 bytes - pad / reserved (must be zero)<br />
+<br />
+ 8 bytes unsigned[] - list of GIDs (may be empty)<br />
+ DOM_SID[] - list of SIDs (may be empty)<br />
<br />
== UNIX_INFO2 ==</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2726UNIX Extensions2007-02-27T20:17:59Z<p>Jpeach: </p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
== Posix Open ==<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== SMB WHOAMI ==<br />
<br />
== UNIX_INFO2 ==</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2725UNIX Extensions2007-02-27T20:17:44Z<p>Jpeach: </p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
== PosixOpen ==<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== SMB WHOAMI ==<br />
<br />
== UNIX_INFO2 ==</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2722UNIX Extensions2007-02-27T16:50:55Z<p>Jpeach: /* PosixOpen */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== PosixOpen ==<br />
<br />
The server specifies it can serve these by returning CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}</div>Jpeachhttps://wiki.samba.org/index.php?title=Bugzilla_Day&diff=2576Bugzilla Day2007-02-20T16:55:23Z<p>Jpeach: /* 22 Feb 2007 */</p>
<hr />
<div>== 22 Feb 2007 ==<br />
<br />
The first preview release of Samba 3.0.25 is scheduled for Wednesday, Feb 21st. Therefore, the theme of the next Bugzilla Day is to bash on 3.0.25pre1. We'll keep the same time from 6am - 6pm Pacific Standard Time (GMT-8) on the #samba-technical channel at irc.freenode.net. Talk to '''coffeedude''' if you need help getting starting.<br />
<br />
== 8 Feb 2007 ==<br />
<br />
The Bug bash is on from 6am - 6pm Pacific Standard Time (GMT-8) on the #samba-technical <br />
channel at irc.freenode.net. Talk to '''coffeedude''' if you need help getting starting.<br />
<br />
Today's bug day theme is Vista. There are several [https://bugzilla.samba.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=Samba+3.0&content=Vista open bugs filed against Samba and Vista clients]. it is also a good idea to have a Windows XP client setup as well to verify that whatever might be failing with Vista actually works with XP. This will also allow you to do comparative tracing using [http://www.wireshark.org/ Wireshark] between the two clients and see why one succeeds and the other fails.<br />
<br />
You can download the [http://www.samba.org/samba/patches/ current set of vista patches against Samba 3.0.24] and start testing. The patches set was generated using [http://savannah.nongnu.org/projects/quilt/ Quilt] and will will be updated throughout the day. All of these should already been in the SAMBA_3_0_25 svn tree. If you are testing against that code base, please ignore the previous link.<br />
<br />
If you don't have a Vista client to test with and would still like to help out, please spend some time <br />
testing any client and any configuration against the SAMBA_3_0_25 branch.<br />
<br />
'''Summary:''' The first bugzilla day went off pretty well. We were able to close off several bugs<br />
([https://bugzilla.samba.org/show_bug.cgi?id=4356 Bug 4356], [https://bugzilla.samba.org/show_bug.cgi?id=4093 Bug 4093] (partial fix), <br />
[https://bugzilla.samba.org/show_bug.cgi?id=4188 Bug 4188], <br />
and [http://lists.samba.org/archive/samba-technical/2007-February/051453.html several printing issues]). The final patchset from today's work will be posted at http://www.samba.org/samba/patches/.</div>Jpeachhttps://wiki.samba.org/index.php?title=Bug_Reporting&diff=2459Bug Reporting2007-02-08T19:49:50Z<p>Jpeach: </p>
<hr />
<div>If you are running a version of Samba provided by SUSE or Novell, please report the bug directly to SUSE, following the instructions here: http://en.opensuse.org/Samba#Samba_bug_reporting_and_advanced_debugging_information<br />
<br />
If you are running a version of Samba provided by Apple, please report the bug directly to Apple, following the instructions here: http://developer.apple.com/bugreporter/</div>Jpeachhttps://wiki.samba.org/index.php?title=Main_Page&diff=2458Main Page2007-02-08T19:47:49Z<p>Jpeach: /* HowTos */</p>
<hr />
<div>'''Opening Windows to a Wider World'''<br />
<br />
Samba is an [http://www.opensource.org Open Source] / [http://www.gnu.org/philosophy/free-sw.html Free Software] suite that has, [http://us4.samba.org/samba/docs/10years.html since 1992], provided file and print services to all manner of SMB/CIFS clients, including the numerous versions of Microsoft Windows operating systems. Samba is freely available under the [http://us4.samba.org/samba/docs/GPL.html GNU General Public License].<br />
<br />
The Samba project is a member of the [http://conservancy.softwarefreedom.org/ Software Freedom Conservancy].<br />
<br />
== Samba Wiki for Developers ==<br />
<br />
Internal design docs, API descriptions, TODOs, etc. for '''developers'''.<br />
<br />
===[[Samba3]]===<br />
<br />
*[[TODOs for 3.0.25]]<br />
*[[Clustered Samba]]<br />
*[[Using Bazaar for Samba Development|Using Bazaar for Samba Development]]<br />
*[[Samba3/libndr|libndr integration status]]<br />
*[[UNIX Extensions]]<br />
*[[Bugzilla Day]]<br />
<br />
===[[Samba4]]===<br />
<br />
*[[Samba4/Status|Status]]<br />
*[[Samba4/FAQ|FAQ]]<br />
*[[Samba4/HOWTO|HOWTO]]<br />
<br />
== '''Samba Wiki for Users''' ==<br />
<br />
Please participate in the wiki experience to promote an alternative reference for things that aren't required or universally necessary to be in the official samba documentation.<br />
<br />
===[[:Category:Category Configuration|Configuration]]===<br />
<br />
*[[Event Logging]]<br />
*[[Samba as a print server]]<br />
*[[Multiple Server Instances]]<br />
*[[Shadow Copies with Snapshots]]<br />
*[[Replicated Failover Domain Controller and file server using LDAP]]<br />
<br />
===[[:Category:Category Documentation|Documentation]]===<br />
<br />
*[[Samba Features added/changed (by release)]]<br />
*[[Documentation Links]]<br />
*[[Event Logging]]<br />
<br />
===[[:Category:Category FAQ|FAQ]]===<br />
<br />
*[[Frequently Asked Questions]]<br />
*[[Samba Myths]]<br />
*[[Samba Troubleshooting]]<br />
<br />
===[[:Category:Category HowTos|HowTos]]===<br />
<br />
*[[Feature Specific HOWTOs]]<br />
*[[Logon scripting]]<br />
*[[Samba & Windows Profiles]]<br />
*[[Samba and Windows Policies]]<br />
*[[Software deployment on Samba]]<br />
*[[Mounting samba shares from a unix client]]<br />
*[[Capture Packets]]<br />
*[[Bug Reporting]]<br />
<br />
===[[:Category:Category Installation|Installation]]===<br />
<br />
*[[Distribution Specific Pages]]<br />
<br />
===[[:Category:Category Integration|Integration]]===<br />
<br />
*[[Exchange Server Alternatives]]<br />
*[[Samba & LDAP]]<br />
*[[Samba & Kerberos]]<br />
*[[Samba & Active Directory]]<br />
*[[Samba & Clustering]]<br />
<br />
===[[:Category:Category Tools|Tools]]===<br />
<br />
*[[Account Management Tools]]<br />
*[[Migration Tools]]<br />
<br />
===[[:Category:Category Links to Pages in other Languages|Links to Pages in other Languages]]===<br />
<br />
*[[ SambaHK ]]</div>Jpeachhttps://wiki.samba.org/index.php?title=Capture_Packets&diff=2457Capture Packets2007-02-08T19:31:07Z<p>Jpeach: </p>
<hr />
<div>When diagnosing a problem, Samba developers are likely to request a packet capture (or trace).<br />
<br />
The best way to do this depends on the tools available on your system. If you are using a GUI-based system, you will need to run a capture tool from the command-line.<br />
<br />
In the table below, replace FILENAME with the descriptive file name. <br />
{|<br />
! Tool !! Commandline<br />
|-<br />
||wireshark || <pre>tshark -p -w FILENAME port 445 or port 139</pre><br />
|-<br />
|| ethereal || <pre>tethereal -p -w FILENAME port 445 or port 139</pre><br />
|-<br />
|| tcpdump || <pre>tcpdump -p -s 512 -w FILENAME port 445 or port 139</pre><br />
|}</div>Jpeachhttps://wiki.samba.org/index.php?title=Main_Page&diff=2456Main Page2007-02-08T19:22:39Z<p>Jpeach: /* HowTos */</p>
<hr />
<div>'''Opening Windows to a Wider World'''<br />
<br />
Samba is an [http://www.opensource.org Open Source] / [http://www.gnu.org/philosophy/free-sw.html Free Software] suite that has, [http://us4.samba.org/samba/docs/10years.html since 1992], provided file and print services to all manner of SMB/CIFS clients, including the numerous versions of Microsoft Windows operating systems. Samba is freely available under the [http://us4.samba.org/samba/docs/GPL.html GNU General Public License].<br />
<br />
The Samba project is a member of the [http://conservancy.softwarefreedom.org/ Software Freedom Conservancy].<br />
<br />
== Samba Wiki for Developers ==<br />
<br />
Internal design docs, API descriptions, TODOs, etc. for '''developers'''.<br />
<br />
===[[Samba3]]===<br />
<br />
*[[TODOs for 3.0.25]]<br />
*[[Clustered Samba]]<br />
*[[Using Bazaar for Samba Development|Using Bazaar for Samba Development]]<br />
*[[Samba3/libndr|libndr integration status]]<br />
*[[UNIX Extensions]]<br />
*[[Bugzilla Day]]<br />
<br />
===[[Samba4]]===<br />
<br />
*[[Samba4/Status|Status]]<br />
*[[Samba4/FAQ|FAQ]]<br />
*[[Samba4/HOWTO|HOWTO]]<br />
<br />
== '''Samba Wiki for Users''' ==<br />
<br />
Please participate in the wiki experience to promote an alternative reference for things that aren't required or universally necessary to be in the official samba documentation.<br />
<br />
===[[:Category:Category Configuration|Configuration]]===<br />
<br />
*[[Event Logging]]<br />
*[[Samba as a print server]]<br />
*[[Multiple Server Instances]]<br />
*[[Shadow Copies with Snapshots]]<br />
*[[Replicated Failover Domain Controller and file server using LDAP]]<br />
<br />
===[[:Category:Category Documentation|Documentation]]===<br />
<br />
*[[Samba Features added/changed (by release)]]<br />
*[[Documentation Links]]<br />
*[[Event Logging]]<br />
<br />
===[[:Category:Category FAQ|FAQ]]===<br />
<br />
*[[Frequently Asked Questions]]<br />
*[[Samba Myths]]<br />
*[[Samba Troubleshooting]]<br />
<br />
===[[:Category:Category HowTos|HowTos]]===<br />
<br />
*[[Feature Specific HOWTOs]]<br />
*[[Logon scripting]]<br />
*[[Samba & Windows Profiles]]<br />
*[[Samba and Windows Policies]]<br />
*[[Software deployment on Samba]]<br />
*[[Mounting samba shares from a unix client]]<br />
*[[Capture Packets]]<br />
<br />
===[[:Category:Category Installation|Installation]]===<br />
<br />
*[[Distribution Specific Pages]]<br />
<br />
===[[:Category:Category Integration|Integration]]===<br />
<br />
*[[Exchange Server Alternatives]]<br />
*[[Samba & LDAP]]<br />
*[[Samba & Kerberos]]<br />
*[[Samba & Active Directory]]<br />
*[[Samba & Clustering]]<br />
<br />
===[[:Category:Category Tools|Tools]]===<br />
<br />
*[[Account Management Tools]]<br />
*[[Migration Tools]]<br />
<br />
===[[:Category:Category Links to Pages in other Languages|Links to Pages in other Languages]]===<br />
<br />
*[[ SambaHK ]]</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2418UNIX Extensions2007-02-07T22:00:11Z<p>Jpeach: /* PosixOpen */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== PosixOpen ==<br />
<br />
Server specifies it can serve these by returning :<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call. All values are little endian.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
Encodings are as follows :<br />
<br />
{|<br />
!POSIX open flags !! Value<br />
|-<br />
|| SMB_O_RDONLY || 0x1<br />
|-<br />
|| SMB_O_WRONLY || 0x2<br />
|-<br />
|| SMB_O_RDWR || 0x4<br />
|- <br />
||SMB_O_CREAT || 0x10<br />
|-<br />
|| SMB_O_EXCL || 0x20<br />
|-<br />
|| SMB_O_TRUNC || 0x40<br />
|-<br />
|| SMB_O_APPEND || 0x80<br />
|-<br />
|| SMB_O_SYNC || 0x100<br />
|-<br />
|| SMB_O_DIRECTORY || 0x200<br />
|-<br />
|| SMB_O_NOFOLLOW || 0x400<br />
|-<br />
|| SMB_O_DIRECT || 0x800<br />
|}<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2417UNIX Extensions2007-02-07T21:55:31Z<p>Jpeach: /* PosixOpen */</p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== PosixOpen ==<br />
<br />
Server specifies it can serve these by returning :<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}<br />
<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of<br />
the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2416UNIX Extensions2007-02-07T21:54:35Z<p>Jpeach: </p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== PosixOpen ==<br />
<br />
Server specifies it can serve these by returning :<br />
<br />
CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP 0x20<br />
<br />
in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03) info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call.<br />
<br />
For open, call TRANSACT2_SETPATHINFO (0x06) call info level :<br />
<br />
SMB_POSIX_PATH_OPEN 0x209<br />
<br />
The request data block should be 14 bytes consisting of<br />
the following :<br />
<br />
{|<br />
!Size !! Offset !! Value<br />
|-<br />
||4 bytes || 0 || Flags field (same as smb_ntcreate_flags in SMBNTCreateX to request oplocks)<br />
|-<br />
||4 bytes || 4 || POSIX open flags (see below)<br />
|-<br />
||4 bytes || 8 || POSIX mode_t (see below)<br />
|-<br />
||2 bytes || 12 || Reply info level requested (see below)<br />
|}<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2415UNIX Extensions2007-02-07T21:50:28Z<p>Jpeach: </p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html<br />
<br />
All Unix extensions are TRANSACT2 commands in the range from 0x200 to 0x2FF (inclusive).<br />
<br />
== PosixOpen ==<br />
<br />
== Negotiating Capabilities ==<br />
<br />
{|<br />
! Capability !! Value<br />
|-<br />
|| CIFS_UNIX_FCNLT_LOCKS_CAP || 0x01<br />
|-<br />
|| CIFS_UNIX_POSIX_ACLS_CAP || 0x02<br />
|-<br />
|| CIFS_UNIX_XATTR_CAP || 0x04<br />
|-<br />
|| CIFS_UNIX_EXATTR_CAP || 0x08<br />
|-<br />
|| CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP || 0x20<br />
|}</div>Jpeachhttps://wiki.samba.org/index.php?title=UNIX_Extensions&diff=2410UNIX Extensions2007-02-06T23:45:04Z<p>Jpeach: </p>
<hr />
<div>See http://samba.org/samba/CIFS_POSIX_extensions.html</div>Jpeachhttps://wiki.samba.org/index.php?title=Main_Page&diff=2409Main Page2007-02-06T23:44:42Z<p>Jpeach: /* Samba3 */</p>
<hr />
<div>'''Opening Windows to a Wider World'''<br />
<br />
Samba is an [http://www.opensource.org Open Source] / [http://www.gnu.org/philosophy/free-sw.html Free Software] suite that has, [http://us4.samba.org/samba/docs/10years.html since 1992], provided file and print services to all manner of SMB/CIFS clients, including the numerous versions of Microsoft Windows operating systems. Samba is freely available under the [http://us4.samba.org/samba/docs/GPL.html GNU General Public License].<br />
<br />
The Samba project is a member of the [http://conservancy.softwarefreedom.org/ Software Freedom Conservancy].<br />
<br />
== Samba Wiki for Developers ==<br />
<br />
Internal design docs, API descriptions, TODOs, etc. for '''developers'''.<br />
<br />
===[[Samba3]]===<br />
<br />
*[[TODOs for 3.0.24]]<br />
*[[Clustered Samba]]<br />
*[[Using Bazaar for Samba Development|Using Bazaar for Samba Development]]<br />
*[[Samba3/libndr|libndr integration status]]<br />
*[[UNIX Extensions]]<br />
<br />
===[[Samba4]]===<br />
<br />
*[[Samba4/Status|Status]]<br />
*[[Samba4/FAQ|FAQ]]<br />
*[[Samba4/HOWTO|HOWTO]]<br />
<br />
== '''Samba Wiki for Users''' ==<br />
<br />
Please participate in the wiki experience to promote an alternative reference for things that aren't required or universally necessary to be in the official samba documentation.<br />
<br />
===[[:Category:Category Configuration|Configuration]]===<br />
<br />
*[[Event Logging]]<br />
*[[Samba as a print server]]<br />
*[[Multiple Server Instances]]<br />
*[[Shadow Copies with Snapshots]]<br />
*[[Replicated Failover Domain Controller and file server using LDAP]]<br />
<br />
===[[:Category:Category Documentation|Documentation]]===<br />
<br />
*[[Samba Features added/changed (by release)]]<br />
*[[Documentation Links]]<br />
*[[Event Logging]]<br />
<br />
===[[:Category:Category FAQ|FAQ]]===<br />
<br />
*[[Frequently Asked Questions]]<br />
*[[Samba Myths]]<br />
*[[Samba Troubleshooting]]<br />
<br />
===[[:Category:Category HowTos|HowTos]]===<br />
<br />
*[[Feature Specific HOWTOs]]<br />
*[[Logon scripting]]<br />
*[[Samba & Windows Profiles]]<br />
*[[Samba and Windows Policies]]<br />
*[[Software deployment on Samba]]<br />
*[[Mounting samba shares from a unix client]]<br />
<br />
===[[:Category:Category Installation|Installation]]===<br />
<br />
*[[Distribution Specific Pages]]<br />
<br />
===[[:Category:Category Integration|Integration]]===<br />
<br />
*[[Exchange Server Alternatives]]<br />
*[[Samba & LDAP]]<br />
*[[Samba & Kerberos]]<br />
*[[Samba & Active Directory]]<br />
*[[Samba & Clustering]]<br />
<br />
===[[:Category:Category Tools|Tools]]===<br />
<br />
*[[Account Management Tools]]<br />
*[[Migration Tools]]<br />
<br />
===[[:Category:Category Links to Pages in other Languages|Links to Pages in other Languages]]===<br />
<br />
*[[ SambaHK ]]</div>Jpeachhttps://wiki.samba.org/index.php?title=Clustered_Samba&diff=1572Clustered Samba2006-05-29T05:04:38Z<p>Jpeach: </p>
<hr />
<div>== Introduction ==<br />
<br />
Current [[Samba3]] implementations can't be used directly on<br />
[[Cluster|clustered systems]] cause they are oriented to single-server<br />
systems. The main reason is that [[smbd]] processes use [[TDB]]<br />
(local-oriented database) for [[messaging]], storing shared data, etc<br />
- there is no way to coordinate [[smbd]] processes run on different<br />
cluster nodes.<br />
<br />
A simple [[Clustered Samba]] system looks like this:<br />
<br />
[[Image:clustered_samba.png]]<br />
<br />
(you can get all images's SVG sources here - [http://samba.org/~ab/dralex/])<br />
<br />
Each node has its own [[smbd]] daemon - they should communicate with<br />
each other to avoid shared data corruption, treat [[oplock|oplocks]] and<br />
so on. So the most problem is the extending of the [[locking]] subsystem<br />
([[share mode locks|share mode locks]], [[oplock|opportunistic locks]],<br />
[[byte-range lock|byte-range locks]]) to multi-node system and cluster<br />
point of view.<br />
<br />
== Cluster Implementation Requirements ==<br />
<br />
This section lists a number of functional requirements that must be<br />
addressed byt any [[Clustered Samba]] implementation.<br />
<br />
===Data integrity===<br />
Multiple Samba servers running on different cluster members and<br />
serving the same cluster filesystem should cooperate to ensure that<br />
users' data is no less safe than a standalone configuration.<br />
<br />
===Zero configuration===<br />
The extra administration required to set up a ClusteredSamba should be<br />
minimised, to nothing if possible. This means that the administrator<br />
should not have to configure any cluster membership in addition to<br />
that already configured in the underlying cluster. The administrator<br />
should not have to configure any setting that can be derived from<br />
the underlying cluster (eg. private interfaces).<br />
<br />
===Single set of binaries===<br />
Clustering should be a runtime option. That is, vendors should not<br />
have to ship separate sets of binaries for cluster and standalone<br />
installations.<br />
<br />
===Cluster independence===<br />
The implementation should work on a variety of clustering<br />
technologies. As a guideline, the clustering implementation should<br />
have acceptable results for a set of nodes sharing a cross-mounted<br />
NFS filesystem.<br />
<br />
This also means that the implementation must not rely on a cluster<br />
implementing any special CIFS features like share modes, file change<br />
notifications, oplocks, etc. The implementation should be able to<br />
take advantage of special cluster features if they exist, however.<br />
<br />
Across the Samba community, it will be necessary to support CXFS,<br />
GFS and GPFS.<br />
<br />
===Cluster membership===<br />
The implementation should tolerate arbitrary fluctuations in cluster<br />
membership. Specifically, this means that an implementation that<br />
relies on a single special node (eg. to arbitrate share mode access)<br />
must be able to tolerate the (possibly permanent) absence of that<br />
node.<br />
<br />
===Fault tolerance===<br />
The implementation should tolerate different degrees of reliability<br />
amongst cluster members, eg. node A might be really flaky but node<br />
B is ok. This tends to imply a loosely coupled model.<br />
<br />
===Scalability===<br />
It is acknowledged that certain workloads will not scale due to the<br />
underlying cluster technology. However, the Samba cluster should be<br />
designed such that all workloads might scale, since different clusters<br />
have different scalability characteristics and the scalability of<br />
even the same cluster technology might change across versions.<br />
<br />
Workloads that must scale are:<br />
* Multiple clients doing IO to disjoint subtrees<br />
* Multiple clients all reading the same files (ie. renderwall load) <br />
<br />
===Performance===<br />
A key performance criterion for the implementation is latency. The<br />
implementation should be designed to minimise the latency of any<br />
checks that might require cross-cluster communication.<br />
<br />
When applied to a single node, the implementation should not provide<br />
substantially worse performance than a non-cluster version of Samba.<br />
<br />
== The Cluster Synchronization Problem ==<br />
<br />
The fundamental problem in implementing a clustered Samba is distributing<br />
the Samba state across the cluster.<br />
<br />
Only a portion of the state Samba associates with each file is pushed<br />
down into the filesystem. We can assume that the state that is pushed<br />
into the filesystem is distributed by the cluster itself. This leaves us<br />
with the problem of distributing information that is stored outside the<br />
filesystem.<br />
<br />
From the point of view of providing strong data integrity, the primary<br />
information we need to be concerned about is the locking state. There is an<br />
implicit requirement to ensure that any information we manually distribute<br />
across the cluster is node-independent.<br />
<br />
=== Distributing Locking State ===<br />
<br />
Here we'll gather information on how locking mechanisms are done in<br />
[[Samba3]].<br />
<br />
Locking is used in different file operations (opening, closing, deleting),<br />
but the main place is huge [[open_file_ntcreate]] function (in fact,<br />
[[open_file_ntcreate]] gives high-level interface to share access<br />
testing).<br />
<br />
Share mode information consist of two different parts: share mode info<br />
and deferred opens info. The former is a collection of file sharing<br />
parameters (file name, list of processes opened the file, oplock info,<br />
etc). The latter is the part of the deferring open calls mechanism.<br />
<br />
All locking operations are presented on the scheme<br />
[[:Image:Samba_locking_calls.png]] (based on [[Analysing source code|code<br />
analysis]] of [[get_share_mode_lock]] function).<br />
<br />
Original smbd's locking operations include:<br />
<br />
* local file operations (file renaming and deleting, posix locking, etc);<br />
* modifications of locking storage (''locking.tdb'');<br />
* sending messages to other lock holders<br />
<br />
All this actions are made under a tdb chain lock to avoid file system or<br />
''locking.tdb'' conflict.<br />
<br />
Present locking mechanism uses single ''locking.tdb'' (database with<br />
shared information - share mode entries, [[deferred open]] entries,<br />
flags, etc) for all [[smbd]] processes:<br />
<br />
[[Image:samba locking 1.png]]<br />
<br />
=== Node-Independent State Information ===<br />
<br />
The information that [[Clustered Samba]] needs to distribute across<br />
the cluster varies widely. Effectively, this means that the contents of<br />
every message type need to be carefully designed to ensure that it will<br />
be valid in a cluster context.<br />
<br />
For example,<br />
* a ''ino_t, dev_t'' tuple is not valid across a CXFS cluster because the ''dev_t'' will be different on different cluster nodes. <br />
* in Tru64 cluster, the ''pid_t'' given as an argument to ''kill(2)'' is valid across the cluster, but the same is not true for CXFS or GPFS.<br />
<br />
There are many traps of this kind, so the cluster arhitecture needs<br />
to be carefully considered, and appropriate abstractions need to be<br />
put in place (eg. the ''process_id'' type) to make sure that cluster<br />
functionality is not broken by development on the standalone server.<br />
<br />
== Clustered Samba Prototypes ==<br />
<br />
Two prototypes of a clustered Samba implementation have been developed in<br />
branches on svn.samba.org:<br />
<br />
* http://viewcvs.samba.org/cgi-bin/viewcvs.cgi/branches/tmp/jpeach-cluster/<br />
* http://viewcvs.samba.org/cgi-bin/viewcvs.cgi/branches/tmp/vl-cluster/ <br />
<br />
Both of these prototypes take a ''shared TDB'' approach to distributing<br />
locking state. In this approach, all cluster nodes access the same<br />
TDB files. The cluster filesystem takes care of ensuring the TDB<br />
contents are consistent across the cluster. Bothe prototypes include<br />
extensive modifications to Samba internal data representations to make<br />
the information stored in various TDBs node-independent.<br />
<br />
The shared TDB approach is simple in terms of the implementation<br />
effort required, but it does not meet out performance criteria. The<br />
primary reason for this is that the design fundamentally depends on<br />
''token thrashing'' behaviour as every cluster node is making updates<br />
to the same TDB file. The prototypes attempt to minimise this impact<br />
by virtualising the TDB interface and splitting each TDB into a number<br />
of separate files. This postpones, but does not alleviate, the problems<br />
caused by token thrashing.<br />
<br />
== Proposed Cluster Architecture ==<br />
<br />
On [[Cluster|clustered systems]] internal [[messaging]] can be used to<br />
interconnect [[smbd]] processes and locking databases:<br />
<br />
[[Image:samba locking 2.png]]<br />
<br />
The first problem with using the SAN as shared storage is performance. If<br />
we simply relocate the TDB files to the SAN, we force multiple cluster<br />
nodes to access the same files for both read and write. In most cluster<br />
implementations this will cause token bouncing and poor performance. There<br />
will tend to be high latency for TDB accesses and scalability will be<br />
poor for certain workloads.<br />
<br />
Fundamentally, any algorithm that involves multiple nodes synchronising<br />
on the shared filesystem will suffer from two performance drawbacks:<br />
* it unpredictably increases the liklihood of token thrashing<br />
* the performance characterisitics will differ across different cluster implementations <br />
<br />
The second problem with using the SAN for IPC is that this will tend to<br />
trigger rarely used code paths in the cluster. Depending on the cluster<br />
in question, it may make the overall system more susceptible to deadlocks.<br />
<br />
===Application-level locking===<br />
We can alleviate the problems associated with shared filesystem<br />
IPC by designating a single node to be an authoritative arbiter of<br />
locking state access. We call this node the '''locking leader'''.<br />
<br />
[[Image:samba locking 3.png]]<br />
<br />
Instead of accessing the TDBs directly, cluster nodes send a locking query<br />
directly to the locking leader. This has good latency characteristics,<br />
since the cost of setting or checking a share mode is a single network<br />
round trip, whereas accessing a shared TDB file might cause round trips<br />
for multiple tokens. A further advantage of an application-specific<br />
locking protocol is that the protocol can be specifically designed for<br />
low latency.<br />
<br />
===Relocation and Recovery===<br />
The disadvantage of this locking scheme is that we suddenly have to<br />
deal with membership fluctuations. That is, if the current locking<br />
leader loses cluster membership we need to relocate that role to a<br />
different cluster member.<br />
<br />
The key to avoiding a complicated and error-prone distributed<br />
algorithm is to notice that all types of cluster has some kind of<br />
identified to uniquely name each member node. We can take advantage<br />
of the ordering implicit in this naming to statically define a policy<br />
that can be used to determine the current locking leader.<br />
<br />
In CXFS, we could say that the MDS or the CMS leader is always the locking<br />
leader. In a cluster of peer nodes, we could say that the lowest numbered<br />
node is always the oracle. All that is necessary is that nodes must be<br />
able to determine the leadership order (and hence the current leader)<br />
without requiring the agreement of any other node. This means we don't<br />
have to maintain a separate Samba cluster membership in sync with the<br />
underlying cluster membership.<br />
<br />
If the current locking leader fails, the next cluster member in our<br />
static ordering becomes the leader. If the distributed state has a<br />
persistent backing store in the shared filesystem, the new locking<br />
leader can taked over without any interruption in service. There are<br />
few performance implications to backing the distributed state in the<br />
shared filesystem, since only the locking leader is ever updating<br />
this state. We assume that any metadata tokens will be migrated<br />
to the locking leader, allowing us to approximate the latencies of<br />
local filesystems.<br />
<br />
If a higher-order cluster member joins the cluster, we have a<br />
dilemma. Does the new member become the locking leader or does the role<br />
stay with the current leader? I propose that that the current leader<br />
should relinquish the role of locking leader as soon as it becomes aware<br />
that a better candidate is present. This complicates the implementation a<br />
little, but makes the cluster rules consistent, which is generally a win.<br />
<br />
Note that this scheme relies on all cluster members having access to<br />
accurate and timely cluster membership information. I believe that<br />
this is not a very onerous requirement, since all clusters that I am<br />
aware of already maintain their own membership state. Also note that<br />
this does not introduce any additional membership state or algorithms.<br />
<br />
Absent cluster members: There may be administrative reasons for<br />
not enabling Samba on every node of the cluster. In this case the<br />
locking leadership order might have holes.<br />
<br />
In the case of a cluster where the locking leader can be present on<br />
any node, this could mean that finding the locking leader could take<br />
up to N network probes (in the absence of a cleverer mechanism). This<br />
might be acceptable provided that the locking leader does not relocate<br />
too often.</div>Jpeachhttps://wiki.samba.org/index.php?title=Clustered_Samba&diff=1571Clustered Samba2006-05-29T03:05:49Z<p>Jpeach: </p>
<hr />
<div>Current [[Samba]] implementations can't be used directly on [[Cluster|clustered systems]] cause they are oriented to single-server systems. The main reason is that [[smbd]] processes use [[TDB]] (local-oriented database) for [[messaging]], storing shared data, etc - there is no way to coordinate [[smbd]] processes run on different cluster nodes.<br />
<br />
A simple [[Clustered Samba]] system looks like this:<br />
<br />
[[Image:clustered_samba.png]]<br />
<br />
(you can get all images's SVG sources here - [http://samba.org/~ab/dralex/])<br />
<br />
Each node has its own [[smbd]] daemon - they should communicate with<br />
each other to avoid shared data corruption, treat [[oplock|oplocks]] and<br />
so on. So the most problem is the extending of the [[locking]] subsystem<br />
([[share mode locks|share mode locks]], [[oplock|opportunistic locks]],<br />
[[byte-range lock|byte-range locks]]) to multi-node system and cluster<br />
point of view.<br />
<br />
== Clustered Samba Prototypes ==<br />
<br />
Two prototypes of a clustered Samba implementation have been developed in<br />
branches on svn.samba.org:<br />
* http://viewcvs.samba.org/cgi-bin/viewcvs.cgi/branches/tmp/jpeach-cluster/<br />
* http://viewcvs.samba.org/cgi-bin/viewcvs.cgi/branches/tmp/vl-cluster/ <br />
<br />
== The Cluster Synchronization Problem ==<br />
<br />
The fundamental problem in implementing a clustered Samba is distributing<br />
the Samba state across the cluster.<br />
<br />
Only a portion of the state Samba associates with each file is pushed<br />
down into the filesystem. We can assume that the state that is pushed<br />
into the filesystem is distributed by the cluster itself. This leaves us<br />
with the problem of distributing information that is stored outside the<br />
filesystem.<br />
<br />
From the point of view of providing strong data integrity, the primary<br />
information we need to be concerned about is the locking state. There is an<br />
implicit requirement to ensure that any information we manually distribute<br />
across the cluster is node-independent.<br />
<br />
=== Distributing Locking State ===<br />
<br />
Here we'll gather information on how locking mechanisms are done in<br />
[[Samba3]].<br />
<br />
Locking is used in different file operations (opening, closing, deleting),<br />
but the main place is huge [[open_file_ntcreate]] function (in fact,<br />
[[open_file_ntcreate]] gives high-level interface to share access<br />
testing).<br />
<br />
Share mode information consist of two different parts: share mode info<br />
and deferred opens info. The former is a collection of file sharing<br />
parameters (file name, list of processes opened the file, oplock info,<br />
etc). The latter is the part of the deferring open calls mechanism.<br />
<br />
All locking operations are presented on the scheme<br />
[[:Image:Samba_locking_calls.png]] (based on [[Analysing source code|code<br />
analysis]] of [[get_share_mode_lock]] function).<br />
<br />
Original smbd's locking operations include:<br />
<br />
* local file operations (file renaming and deleting, posix locking, etc);<br />
* modifications of locking storage (''locking.tdb'');<br />
* sending messages to other lock holders<br />
<br />
All this actions are made under a tdb chain lock to avoid file system or<br />
''locking.tdb'' conflict.<br />
<br />
Present locking mechanism uses single ''locking.tdb'' (database with<br />
shared information - share mode entries, [[deferred open]] entries,<br />
flags, etc) for all [[smbd]] processes:<br />
<br />
[[Image:samba locking 1.png]]<br />
<br />
=== Cluster-Independent State Information ===<br />
<br />
== Proposed Cluster Architecture ==<br />
<br />
On [[Cluster|clustered systems]] internal [[messaging]] can be used to<br />
interconnect [[smbd]] processes and locking databases:<br />
<br />
[[Image:samba locking 2.png]]<br />
<br />
This approach implies too many messaging opearations between [[smbd]]<br />
processes while locking/unlocking a file. They can be reduced noticeably<br />
if all locking information is stored on the one node - with the [[locking<br />
daemon]]:<br />
<br />
[[Image:samba locking 3.png]]</div>Jpeachhttps://wiki.samba.org/index.php?title=Samba3&diff=1450Samba32006-03-17T03:45:51Z<p>Jpeach: </p>
<hr />
<div>Samba 3 is the current stable production version of Samba.<br />
<br />
== Compiling Samba 3 ==<br />
<br />
Samba has a number of [[build-time configuration options]]. These control options and features that can be useful in specific environments but might not be appropriate for all installations.</div>Jpeach