SMB3-Linux

From SambaWiki
Revision as of 13:20, 21 January 2015 by Slowfranklin (talk | contribs) (POSIX vs Windows directory rename behaviour)

Jump to: navigation, search

There are various requirements for full POSIX compatibility, and other requirements which although not strictly POSIX (such as support for symlinks and the fallocate system call) are common in Linux and various Unix variants and useful to applications. The goal is to implement emulation strategies and extensions to the SMB3 protocol which are as small as reasonably possible but implement the most important of these missing features, allowing the network file system to appear nearly identical to a local file system to users and the applications they run, without creating unacceptable performance or configuration problems.

The general requirements for SMB3 POSIX extensions include the following:

  1. POSIX mode bits (the primitive 0777 bits used to control who can access a file)
  2. POSIX file ownership (UID and GID owners. Windows typically only has one or the other, and expresses them as global "SIDs" with longer UUIDs rather than locally defined UIDs)
  3. symlinks
  4. case sensitivity
  5. mapping 7 reserved characters (not allowed in SMB3/CIFS/NTFS/Windows but allowed in POSIX). They include: * ? < > : | \
  6. mkfifo and mknod
  7. POSIX unlink and rename behavior:
    1. unlink: deleting an open file, removing it from the namespace, occurs in POSIX but not Windows
    2. rename: renaming a directories that has open files, perfectly legal in POSIX but not in Windows (even recursivley)
  8. POSIX "advisory" byte range locks (SMB3 allows Windows style "mandatory" byte range locks). POSIX locks are also merged when they overlap, and all locks are released on file close making them both confusing to use (locally on Linux file systems, and even more so over network file systems) and more difficult to emulate. Although many dislike the POSIX byte range lock behavior, their implementation in SMB3 would help some applications.
  9. Slight differences in "stat" system call (and the mode/ownership information noted above)
  10. Additional information returned on the statfs" system call: f_files; /* total file nodes in file system */ and f_ffree; /* free file nodes in fs */
  11. "POSIX ACL" support. Linux implements an ACL model for local file systems which is less complex than the more common "RichACLs" (ie NFSv4 or NTFS/SMB/SMB3 ACLs) but easier to understand.
  12. fallocate: many fallocate options are available, most but not all are mappable to various existing SMB3 ioctls.


Current status:

  1. POSIX mode bits: emulatable via the "cifsacl" (cifs.ko mount option for cifs which pulls them from the server's "RichACL" (NTFS/SMB3/NFSv4). Using an approach similar to the "NFSv4 mode ACE" may be helpful as well. Prototype not complete. SMB3_SetACL and SMB3_GetACL worker functions for Linux's cifs.ko have been prototyped but not reviewed yet.
  2. POSIX file ownership (see above)
  3. symlinks: use the "mfsymlinks" approach used by Apple among others. Implemented in cifs.ko. Will be in kernel 3.18 and later. Should be backportable to earlier kernels.
  4. case sensitivity: Not available yet, requires extension to SMB3 OpenCreate call - a new "POSIX Create Context" has been proposed.
  5. mapping 7 reserved characters: There are three ways to do this: "POSIX Create Context" and Microsoft's "SFU" (SUA) mapping and Apple's "SFM" mapping. The SFU mapping is available in CIFS (and SMB3 in 3.18) with the "mapchars" mount option but we plan to use the Apple ("SFM") mapping approach by default in 3.18 kernel and later (Samba requires the "vfs_fruit" module to implement the Apple mapping of the seven reserved characters).
  6. mkfifo and mknod: are emulated using the same approach that Microsoft SFU and others did. Uses the "sfu" mount option (available in 3.18 kernel or later)
  7. POSIX unlink and rename behavior. Emulatable over SMB3 for most cases (using "delete on close" and using an approach like "nfs silly rename"). 3.18 kernel will better handle these but "POSIX Create Context" are still likely to be required for a few use cases.
  8. POSIX Advisory byte range locks: emulated via mandatory locks today, and can also be "local only" (with a cifs.ko mount option "nobrl"). Requires "POSIX Create Context"
  9. stat (see above)
  10. statfs: For the two fields which are not retrievable other ways (minor issue). "POSIX Create Context" can be used
  11. POSIX ACLs: Could be mapped to SMB3/NTFS RichACLs which are a superset of POSIX ACLs. Also could be handled via "POSIX Create Context"
  12. fallocate (partially implemented already) and also a few other new Linux syscalls which are not broadly implemented: more research needed