1This module supports the SMB3 family of advanced network protocols (as well 2as older dialects, originally called "CIFS" or SMB1). 3 4The CIFS VFS module for Linux supports many advanced network filesystem 5features such as hierarchical DFS like namespace, hardlinks, locking and more. 6It was designed to comply with the SNIA CIFS Technical Reference (which 7supersedes the 1992 X/Open SMB Standard) as well as to perform best practice 8practical interoperability with Windows 2000, Windows XP, Samba and equivalent 9servers. This code was developed in participation with the Protocol Freedom 10Information Foundation. CIFS and now SMB3 has now become a defacto 11standard for interoperating between Macs and Windows and major NAS appliances. 12 13Please see 14 MS-SMB2 (for detailed SMB2/SMB3/SMB3.1.1 protocol specification) 15 http://protocolfreedom.org/ and 16 http://samba.org/samba/PFIF/ 17for more details. 18 19 20For questions or bug reports please contact: 21 smfrench@gmail.com 22 23See the project page at: https://wiki.samba.org/index.php/LinuxCIFS_utils 24 25Build instructions: 26================== 27For Linux: 281) Download the kernel (e.g. from http://www.kernel.org) 29and change directory into the top of the kernel directory tree 30(e.g. /usr/src/linux-2.5.73) 312) make menuconfig (or make xconfig) 323) select cifs from within the network filesystem choices 334) save and exit 345) make 35 36 37Installation instructions: 38========================= 39If you have built the CIFS vfs as module (successfully) simply 40type "make modules_install" (or if you prefer, manually copy the file to 41the modules directory e.g. /lib/modules/2.4.10-4GB/kernel/fs/cifs/cifs.ko). 42 43If you have built the CIFS vfs into the kernel itself, follow the instructions 44for your distribution on how to install a new kernel (usually you 45would simply type "make install"). 46 47If you do not have the utility mount.cifs (in the Samba 4.x source tree and on 48the CIFS VFS web site) copy it to the same directory in which mount helpers 49reside (usually /sbin). Although the helper software is not 50required, mount.cifs is recommended. Most distros include a "cifs-utils" 51package that includes this utility so it is recommended to install this. 52 53Note that running the Winbind pam/nss module (logon service) on all of your 54Linux clients is useful in mapping Uids and Gids consistently across the 55domain to the proper network user. The mount.cifs mount helper can be 56found at cifs-utils.git on git.samba.org 57 58If cifs is built as a module, then the size and number of network buffers 59and maximum number of simultaneous requests to one server can be configured. 60Changing these from their defaults is not recommended. By executing modinfo 61 modinfo kernel/fs/cifs/cifs.ko 62on kernel/fs/cifs/cifs.ko the list of configuration changes that can be made 63at module initialization time (by running insmod cifs.ko) can be seen. 64 65Recommendations 66=============== 67To improve security the SMB2.1 dialect or later (usually will get SMB3) is now 68the new default. To use old dialects (e.g. to mount Windows XP) use "vers=1.0" 69on mount (or vers=2.0 for Windows Vista). Note that the CIFS (vers=1.0) is 70much older and less secure than the default dialect SMB3 which includes 71many advanced security features such as downgrade attack detection 72and encrypted shares and stronger signing and authentication algorithms. 73There are additional mount options that may be helpful for SMB3 to get 74improved POSIX behavior (NB: can use vers=3.0 to force only SMB3, never 2.1): 75 "mfsymlinks" and "cifsacl" and "idsfromsid" 76 77Allowing User Mounts 78==================== 79To permit users to mount and unmount over directories they own is possible 80with the cifs vfs. A way to enable such mounting is to mark the mount.cifs 81utility as suid (e.g. "chmod +s /sbin/mount.cifs). To enable users to 82umount shares they mount requires 831) mount.cifs version 1.4 or later 842) an entry for the share in /etc/fstab indicating that a user may 85unmount it e.g. 86//server/usersharename /mnt/username cifs user 0 0 87 88Note that when the mount.cifs utility is run suid (allowing user mounts), 89in order to reduce risks, the "nosuid" mount flag is passed in on mount to 90disallow execution of an suid program mounted on the remote target. 91When mount is executed as root, nosuid is not passed in by default, 92and execution of suid programs on the remote target would be enabled 93by default. This can be changed, as with nfs and other filesystems, 94by simply specifying "nosuid" among the mount options. For user mounts 95though to be able to pass the suid flag to mount requires rebuilding 96mount.cifs with the following flag: CIFS_ALLOW_USR_SUID 97 98There is a corresponding manual page for cifs mounting in the Samba 3.0 and 99later source tree in docs/manpages/mount.cifs.8 100 101Allowing User Unmounts 102====================== 103To permit users to ummount directories that they have user mounted (see above), 104the utility umount.cifs may be used. It may be invoked directly, or if 105umount.cifs is placed in /sbin, umount can invoke the cifs umount helper 106(at least for most versions of the umount utility) for umount of cifs 107mounts, unless umount is invoked with -i (which will avoid invoking a umount 108helper). As with mount.cifs, to enable user unmounts umount.cifs must be marked 109as suid (e.g. "chmod +s /sbin/umount.cifs") or equivalent (some distributions 110allow adding entries to a file to the /etc/permissions file to achieve the 111equivalent suid effect). For this utility to succeed the target path 112must be a cifs mount, and the uid of the current user must match the uid 113of the user who mounted the resource. 114 115Also note that the customary way of allowing user mounts and unmounts is 116(instead of using mount.cifs and unmount.cifs as suid) to add a line 117to the file /etc/fstab for each //server/share you wish to mount, but 118this can become unwieldy when potential mount targets include many 119or unpredictable UNC names. 120 121Samba Considerations 122==================== 123Most current servers support SMB2.1 and SMB3 which are more secure, 124but there are useful protocol extensions for the older less secure CIFS 125dialect, so to get the maximum benefit if mounting using the older dialect 126(CIFS/SMB1), we recommend using a server that supports the SNIA CIFS 127Unix Extensions standard (e.g. almost any version of Samba ie version 1282.2.5 or later) but the CIFS vfs works fine with a wide variety of CIFS servers. 129Note that uid, gid and file permissions will display default values if you do 130not have a server that supports the Unix extensions for CIFS (such as Samba 1312.2.5 or later). To enable the Unix CIFS Extensions in the Samba server, add 132the line: 133 134 unix extensions = yes 135 136to your smb.conf file on the server. Note that the following smb.conf settings 137are also useful (on the Samba server) when the majority of clients are Unix or 138Linux: 139 140 case sensitive = yes 141 delete readonly = yes 142 ea support = yes 143 144Note that server ea support is required for supporting xattrs from the Linux 145cifs client, and that EA support is present in later versions of Samba (e.g. 1463.0.6 and later (also EA support works in all versions of Windows, at least to 147shares on NTFS filesystems). Extended Attribute (xattr) support is an optional 148feature of most Linux filesystems which may require enabling via 149make menuconfig. Client support for extended attributes (user xattr) can be 150disabled on a per-mount basis by specifying "nouser_xattr" on mount. 151 152The CIFS client can get and set POSIX ACLs (getfacl, setfacl) to Samba servers 153version 3.10 and later. Setting POSIX ACLs requires enabling both XATTR and 154then POSIX support in the CIFS configuration options when building the cifs 155module. POSIX ACL support can be disabled on a per mount basic by specifying 156"noacl" on mount. 157 158Some administrators may want to change Samba's smb.conf "map archive" and 159"create mask" parameters from the default. Unless the create mask is changed 160newly created files can end up with an unnecessarily restrictive default mode, 161which may not be what you want, although if the CIFS Unix extensions are 162enabled on the server and client, subsequent setattr calls (e.g. chmod) can 163fix the mode. Note that creating special devices (mknod) remotely 164may require specifying a mkdev function to Samba if you are not using 165Samba 3.0.6 or later. For more information on these see the manual pages 166("man smb.conf") on the Samba server system. Note that the cifs vfs, 167unlike the smbfs vfs, does not read the smb.conf on the client system 168(the few optional settings are passed in on mount via -o parameters instead). 169Note that Samba 2.2.7 or later includes a fix that allows the CIFS VFS to delete 170open files (required for strict POSIX compliance). Windows Servers already 171supported this feature. Samba server does not allow symlinks that refer to files 172outside of the share, so in Samba versions prior to 3.0.6, most symlinks to 173files with absolute paths (ie beginning with slash) such as: 174 ln -s /mnt/foo bar 175would be forbidden. Samba 3.0.6 server or later includes the ability to create 176such symlinks safely by converting unsafe symlinks (ie symlinks to server 177files that are outside of the share) to a samba specific format on the server 178that is ignored by local server applications and non-cifs clients and that will 179not be traversed by the Samba server). This is opaque to the Linux client 180application using the cifs vfs. Absolute symlinks will work to Samba 3.0.5 or 181later, but only for remote clients using the CIFS Unix extensions, and will 182be invisbile to Windows clients and typically will not affect local 183applications running on the same server as Samba. 184 185Use instructions: 186================ 187Once the CIFS VFS support is built into the kernel or installed as a module 188(cifs.ko), you can use mount syntax like the following to access Samba or 189Mac or Windows servers: 190 191 mount -t cifs //9.53.216.11/e$ /mnt -o username=myname,password=mypassword 192 193Before -o the option -v may be specified to make the mount.cifs 194mount helper display the mount steps more verbosely. 195After -o the following commonly used cifs vfs specific options 196are supported: 197 198 username=<username> 199 password=<password> 200 domain=<domain name> 201 202Other cifs mount options are described below. Use of TCP names (in addition to 203ip addresses) is available if the mount helper (mount.cifs) is installed. If 204you do not trust the server to which are mounted, or if you do not have 205cifs signing enabled (and the physical network is insecure), consider use 206of the standard mount options "noexec" and "nosuid" to reduce the risk of 207running an altered binary on your local system (downloaded from a hostile server 208or altered by a hostile router). 209 210Although mounting using format corresponding to the CIFS URL specification is 211not possible in mount.cifs yet, it is possible to use an alternate format 212for the server and sharename (which is somewhat similar to NFS style mount 213syntax) instead of the more widely used UNC format (i.e. \\server\share): 214 mount -t cifs tcp_name_of_server:share_name /mnt -o user=myname,pass=mypasswd 215 216When using the mount helper mount.cifs, passwords may be specified via alternate 217mechanisms, instead of specifying it after -o using the normal "pass=" syntax 218on the command line: 2191) By including it in a credential file. Specify credentials=filename as one 220of the mount options. Credential files contain two lines 221 username=someuser 222 password=your_password 2232) By specifying the password in the PASSWD environment variable (similarly 224the user name can be taken from the USER environment variable). 2253) By specifying the password in a file by name via PASSWD_FILE 2264) By specifying the password in a file by file descriptor via PASSWD_FD 227 228If no password is provided, mount.cifs will prompt for password entry 229 230Restrictions 231============ 232Servers must support either "pure-TCP" (port 445 TCP/IP CIFS connections) or RFC 2331001/1002 support for "Netbios-Over-TCP/IP." This is not likely to be a 234problem as most servers support this. 235 236Valid filenames differ between Windows and Linux. Windows typically restricts 237filenames which contain certain reserved characters (e.g.the character : 238which is used to delimit the beginning of a stream name by Windows), while 239Linux allows a slightly wider set of valid characters in filenames. Windows 240servers can remap such characters when an explicit mapping is specified in 241the Server's registry. Samba starting with version 3.10 will allow such 242filenames (ie those which contain valid Linux characters, which normally 243would be forbidden for Windows/CIFS semantics) as long as the server is 244configured for Unix Extensions (and the client has not disabled 245/proc/fs/cifs/LinuxExtensionsEnabled). In addition the mount option 246"mapposix" can be used on CIFS (vers=1.0) to force the mapping of 247illegal Windows/NTFS/SMB characters to a remap range (this mount parm 248is the default for SMB3). This remap ("mapposix") range is also 249compatible with Mac (and "Services for Mac" on some older Windows). 250 251CIFS VFS Mount Options 252====================== 253A partial list of the supported mount options follows: 254 username The user name to use when trying to establish 255 the CIFS session. 256 password The user password. If the mount helper is 257 installed, the user will be prompted for password 258 if not supplied. 259 ip The ip address of the target server 260 unc The target server Universal Network Name (export) to 261 mount. 262 domain Set the SMB/CIFS workgroup name prepended to the 263 username during CIFS session establishment 264 forceuid Set the default uid for inodes to the uid 265 passed in on mount. For mounts to servers 266 which do support the CIFS Unix extensions, such as a 267 properly configured Samba server, the server provides 268 the uid, gid and mode so this parameter should not be 269 specified unless the server and clients uid and gid 270 numbering differ. If the server and client are in the 271 same domain (e.g. running winbind or nss_ldap) and 272 the server supports the Unix Extensions then the uid 273 and gid can be retrieved from the server (and uid 274 and gid would not have to be specified on the mount. 275 For servers which do not support the CIFS Unix 276 extensions, the default uid (and gid) returned on lookup 277 of existing files will be the uid (gid) of the person 278 who executed the mount (root, except when mount.cifs 279 is configured setuid for user mounts) unless the "uid=" 280 (gid) mount option is specified. Also note that permission 281 checks (authorization checks) on accesses to a file occur 282 at the server, but there are cases in which an administrator 283 may want to restrict at the client as well. For those 284 servers which do not report a uid/gid owner 285 (such as Windows), permissions can also be checked at the 286 client, and a crude form of client side permission checking 287 can be enabled by specifying file_mode and dir_mode on 288 the client. (default) 289 forcegid (similar to above but for the groupid instead of uid) (default) 290 noforceuid Fill in file owner information (uid) by requesting it from 291 the server if possible. With this option, the value given in 292 the uid= option (on mount) will only be used if the server 293 can not support returning uids on inodes. 294 noforcegid (similar to above but for the group owner, gid, instead of uid) 295 uid Set the default uid for inodes, and indicate to the 296 cifs kernel driver which local user mounted. If the server 297 supports the unix extensions the default uid is 298 not used to fill in the owner fields of inodes (files) 299 unless the "forceuid" parameter is specified. 300 gid Set the default gid for inodes (similar to above). 301 file_mode If CIFS Unix extensions are not supported by the server 302 this overrides the default mode for file inodes. 303 fsc Enable local disk caching using FS-Cache (off by default). This 304 option could be useful to improve performance on a slow link, 305 heavily loaded server and/or network where reading from the 306 disk is faster than reading from the server (over the network). 307 This could also impact scalability positively as the 308 number of calls to the server are reduced. However, local 309 caching is not suitable for all workloads for e.g. read-once 310 type workloads. So, you need to consider carefully your 311 workload/scenario before using this option. Currently, local 312 disk caching is functional for CIFS files opened as read-only. 313 dir_mode If CIFS Unix extensions are not supported by the server 314 this overrides the default mode for directory inodes. 315 port attempt to contact the server on this tcp port, before 316 trying the usual ports (port 445, then 139). 317 iocharset Codepage used to convert local path names to and from 318 Unicode. Unicode is used by default for network path 319 names if the server supports it. If iocharset is 320 not specified then the nls_default specified 321 during the local client kernel build will be used. 322 If server does not support Unicode, this parameter is 323 unused. 324 rsize default read size (usually 16K). The client currently 325 can not use rsize larger than CIFSMaxBufSize. CIFSMaxBufSize 326 defaults to 16K and may be changed (from 8K to the maximum 327 kmalloc size allowed by your kernel) at module install time 328 for cifs.ko. Setting CIFSMaxBufSize to a very large value 329 will cause cifs to use more memory and may reduce performance 330 in some cases. To use rsize greater than 127K (the original 331 cifs protocol maximum) also requires that the server support 332 a new Unix Capability flag (for very large read) which some 333 newer servers (e.g. Samba 3.0.26 or later) do. rsize can be 334 set from a minimum of 2048 to a maximum of 130048 (127K or 335 CIFSMaxBufSize, whichever is smaller) 336 wsize default write size (default 57344) 337 maximum wsize currently allowed by CIFS is 57344 (fourteen 338 4096 byte pages) 339 actimeo=n attribute cache timeout in seconds (default 1 second). 340 After this timeout, the cifs client requests fresh attribute 341 information from the server. This option allows to tune the 342 attribute cache timeout to suit the workload needs. Shorter 343 timeouts mean better the cache coherency, but increased number 344 of calls to the server. Longer timeouts mean reduced number 345 of calls to the server at the expense of less stricter cache 346 coherency checks (i.e. incorrect attribute cache for a short 347 period of time). 348 rw mount the network share read-write (note that the 349 server may still consider the share read-only) 350 ro mount network share read-only 351 version used to distinguish different versions of the 352 mount helper utility (not typically needed) 353 sep if first mount option (after the -o), overrides 354 the comma as the separator between the mount 355 parms. e.g. 356 -o user=myname,password=mypassword,domain=mydom 357 could be passed instead with period as the separator by 358 -o sep=.user=myname.password=mypassword.domain=mydom 359 this might be useful when comma is contained within username 360 or password or domain. This option is less important 361 when the cifs mount helper cifs.mount (version 1.1 or later) 362 is used. 363 nosuid Do not allow remote executables with the suid bit 364 program to be executed. This is only meaningful for mounts 365 to servers such as Samba which support the CIFS Unix Extensions. 366 If you do not trust the servers in your network (your mount 367 targets) it is recommended that you specify this option for 368 greater security. 369 exec Permit execution of binaries on the mount. 370 noexec Do not permit execution of binaries on the mount. 371 dev Recognize block devices on the remote mount. 372 nodev Do not recognize devices on the remote mount. 373 suid Allow remote files on this mountpoint with suid enabled to 374 be executed (default for mounts when executed as root, 375 nosuid is default for user mounts). 376 credentials Although ignored by the cifs kernel component, it is used by 377 the mount helper, mount.cifs. When mount.cifs is installed it 378 opens and reads the credential file specified in order 379 to obtain the userid and password arguments which are passed to 380 the cifs vfs. 381 guest Although ignored by the kernel component, the mount.cifs 382 mount helper will not prompt the user for a password 383 if guest is specified on the mount options. If no 384 password is specified a null password will be used. 385 perm Client does permission checks (vfs_permission check of uid 386 and gid of the file against the mode and desired operation), 387 Note that this is in addition to the normal ACL check on the 388 target machine done by the server software. 389 Client permission checking is enabled by default. 390 noperm Client does not do permission checks. This can expose 391 files on this mount to access by other users on the local 392 client system. It is typically only needed when the server 393 supports the CIFS Unix Extensions but the UIDs/GIDs on the 394 client and server system do not match closely enough to allow 395 access by the user doing the mount, but it may be useful with 396 non CIFS Unix Extension mounts for cases in which the default 397 mode is specified on the mount but is not to be enforced on the 398 client (e.g. perhaps when MultiUserMount is enabled) 399 Note that this does not affect the normal ACL check on the 400 target machine done by the server software (of the server 401 ACL against the user name provided at mount time). 402 serverino Use server's inode numbers instead of generating automatically 403 incrementing inode numbers on the client. Although this will 404 make it easier to spot hardlinked files (as they will have 405 the same inode numbers) and inode numbers may be persistent, 406 note that the server does not guarantee that the inode numbers 407 are unique if multiple server side mounts are exported under a 408 single share (since inode numbers on the servers might not 409 be unique if multiple filesystems are mounted under the same 410 shared higher level directory). Note that some older 411 (e.g. pre-Windows 2000) do not support returning UniqueIDs 412 or the CIFS Unix Extensions equivalent and for those 413 this mount option will have no effect. Exporting cifs mounts 414 under nfsd requires this mount option on the cifs mount. 415 This is now the default if server supports the 416 required network operation. 417 noserverino Client generates inode numbers (rather than using the actual one 418 from the server). These inode numbers will vary after 419 unmount or reboot which can confuse some applications, 420 but not all server filesystems support unique inode 421 numbers. 422 setuids If the CIFS Unix extensions are negotiated with the server 423 the client will attempt to set the effective uid and gid of 424 the local process on newly created files, directories, and 425 devices (create, mkdir, mknod). If the CIFS Unix Extensions 426 are not negotiated, for newly created files and directories 427 instead of using the default uid and gid specified on 428 the mount, cache the new file's uid and gid locally which means 429 that the uid for the file can change when the inode is 430 reloaded (or the user remounts the share). 431 nosetuids The client will not attempt to set the uid and gid on 432 on newly created files, directories, and devices (create, 433 mkdir, mknod) which will result in the server setting the 434 uid and gid to the default (usually the server uid of the 435 user who mounted the share). Letting the server (rather than 436 the client) set the uid and gid is the default. If the CIFS 437 Unix Extensions are not negotiated then the uid and gid for 438 new files will appear to be the uid (gid) of the mounter or the 439 uid (gid) parameter specified on the mount. 440 netbiosname When mounting to servers via port 139, specifies the RFC1001 441 source name to use to represent the client netbios machine 442 name when doing the RFC1001 netbios session initialize. 443 direct Do not do inode data caching on files opened on this mount. 444 This precludes mmapping files on this mount. In some cases 445 with fast networks and little or no caching benefits on the 446 client (e.g. when the application is doing large sequential 447 reads bigger than page size without rereading the same data) 448 this can provide better performance than the default 449 behavior which caches reads (readahead) and writes 450 (writebehind) through the local Linux client pagecache 451 if oplock (caching token) is granted and held. Note that 452 direct allows write operations larger than page size 453 to be sent to the server. 454 strictcache Use for switching on strict cache mode. In this mode the 455 client read from the cache all the time it has Oplock Level II, 456 otherwise - read from the server. All written data are stored 457 in the cache, but if the client doesn't have Exclusive Oplock, 458 it writes the data to the server. 459 rwpidforward Forward pid of a process who opened a file to any read or write 460 operation on that file. This prevent applications like WINE 461 from failing on read and write if we use mandatory brlock style. 462 acl Allow setfacl and getfacl to manage posix ACLs if server 463 supports them. (default) 464 noacl Do not allow setfacl and getfacl calls on this mount 465 user_xattr Allow getting and setting user xattrs (those attributes whose 466 name begins with "user." or "os2.") as OS/2 EAs (extended 467 attributes) to the server. This allows support of the 468 setfattr and getfattr utilities. (default) 469 nouser_xattr Do not allow getfattr/setfattr to get/set/list xattrs 470 mapchars Translate six of the seven reserved characters (not backslash) 471 *?<>|: 472 to the remap range (above 0xF000), which also 473 allows the CIFS client to recognize files created with 474 such characters by Windows's POSIX emulation. This can 475 also be useful when mounting to most versions of Samba 476 (which also forbids creating and opening files 477 whose names contain any of these seven characters). 478 This has no effect if the server does not support 479 Unicode on the wire. 480 nomapchars Do not translate any of these seven characters (default). 481 nocase Request case insensitive path name matching (case 482 sensitive is the default if the server supports it). 483 (mount option "ignorecase" is identical to "nocase") 484 posixpaths If CIFS Unix extensions are supported, attempt to 485 negotiate posix path name support which allows certain 486 characters forbidden in typical CIFS filenames, without 487 requiring remapping. (default) 488 noposixpaths If CIFS Unix extensions are supported, do not request 489 posix path name support (this may cause servers to 490 reject creatingfile with certain reserved characters). 491 nounix Disable the CIFS Unix Extensions for this mount (tree 492 connection). This is rarely needed, but it may be useful 493 in order to turn off multiple settings all at once (ie 494 posix acls, posix locks, posix paths, symlink support 495 and retrieving uids/gids/mode from the server) or to 496 work around a bug in server which implement the Unix 497 Extensions. 498 nobrl Do not send byte range lock requests to the server. 499 This is necessary for certain applications that break 500 with cifs style mandatory byte range locks (and most 501 cifs servers do not yet support requesting advisory 502 byte range locks). 503 forcemandatorylock Even if the server supports posix (advisory) byte range 504 locking, send only mandatory lock requests. For some 505 (presumably rare) applications, originally coded for 506 DOS/Windows, which require Windows style mandatory byte range 507 locking, they may be able to take advantage of this option, 508 forcing the cifs client to only send mandatory locks 509 even if the cifs server would support posix advisory locks. 510 "forcemand" is accepted as a shorter form of this mount 511 option. 512 nostrictsync If this mount option is set, when an application does an 513 fsync call then the cifs client does not send an SMB Flush 514 to the server (to force the server to write all dirty data 515 for this file immediately to disk), although cifs still sends 516 all dirty (cached) file data to the server and waits for the 517 server to respond to the write. Since SMB Flush can be 518 very slow, and some servers may be reliable enough (to risk 519 delaying slightly flushing the data to disk on the server), 520 turning on this option may be useful to improve performance for 521 applications that fsync too much, at a small risk of server 522 crash. If this mount option is not set, by default cifs will 523 send an SMB flush request (and wait for a response) on every 524 fsync call. 525 nodfs Disable DFS (global name space support) even if the 526 server claims to support it. This can help work around 527 a problem with parsing of DFS paths with Samba server 528 versions 3.0.24 and 3.0.25. 529 remount remount the share (often used to change from ro to rw mounts 530 or vice versa) 531 cifsacl Report mode bits (e.g. on stat) based on the Windows ACL for 532 the file. (EXPERIMENTAL) 533 servern Specify the server 's netbios name (RFC1001 name) to use 534 when attempting to setup a session to the server. 535 This is needed for mounting to some older servers (such 536 as OS/2 or Windows 98 and Windows ME) since they do not 537 support a default server name. A server name can be up 538 to 15 characters long and is usually uppercased. 539 sfu When the CIFS Unix Extensions are not negotiated, attempt to 540 create device files and fifos in a format compatible with 541 Services for Unix (SFU). In addition retrieve bits 10-12 542 of the mode via the SETFILEBITS extended attribute (as 543 SFU does). In the future the bottom 9 bits of the 544 mode also will be emulated using queries of the security 545 descriptor (ACL). 546 mfsymlinks Enable support for Minshall+French symlinks 547 (see http://wiki.samba.org/index.php/UNIX_Extensions#Minshall.2BFrench_symlinks) 548 This option is ignored when specified together with the 549 'sfu' option. Minshall+French symlinks are used even if 550 the server supports the CIFS Unix Extensions. 551 sign Must use packet signing (helps avoid unwanted data modification 552 by intermediate systems in the route). Note that signing 553 does not work with lanman or plaintext authentication. 554 seal Must seal (encrypt) all data on this mounted share before 555 sending on the network. Requires support for Unix Extensions. 556 Note that this differs from the sign mount option in that it 557 causes encryption of data sent over this mounted share but other 558 shares mounted to the same server are unaffected. 559 locallease This option is rarely needed. Fcntl F_SETLEASE is 560 used by some applications such as Samba and NFSv4 server to 561 check to see whether a file is cacheable. CIFS has no way 562 to explicitly request a lease, but can check whether a file 563 is cacheable (oplocked). Unfortunately, even if a file 564 is not oplocked, it could still be cacheable (ie cifs client 565 could grant fcntl leases if no other local processes are using 566 the file) for cases for example such as when the server does not 567 support oplocks and the user is sure that the only updates to 568 the file will be from this client. Specifying this mount option 569 will allow the cifs client to check for leases (only) locally 570 for files which are not oplocked instead of denying leases 571 in that case. (EXPERIMENTAL) 572 sec Security mode. Allowed values are: 573 none attempt to connection as a null user (no name) 574 krb5 Use Kerberos version 5 authentication 575 krb5i Use Kerberos authentication and packet signing 576 ntlm Use NTLM password hashing (default) 577 ntlmi Use NTLM password hashing with signing (if 578 /proc/fs/cifs/PacketSigningEnabled on or if 579 server requires signing also can be the default) 580 ntlmv2 Use NTLMv2 password hashing 581 ntlmv2i Use NTLMv2 password hashing with packet signing 582 lanman (if configured in kernel config) use older 583 lanman hash 584hard Retry file operations if server is not responding 585soft Limit retries to unresponsive servers (usually only 586 one retry) before returning an error. (default) 587 588The mount.cifs mount helper also accepts a few mount options before -o 589including: 590 591 -S take password from stdin (equivalent to setting the environment 592 variable "PASSWD_FD=0" 593 -V print mount.cifs version 594 -? display simple usage information 595 596With most 2.6 kernel versions of modutils, the version of the cifs kernel 597module can be displayed via modinfo. 598 599Misc /proc/fs/cifs Flags and Debug Info 600======================================= 601Informational pseudo-files: 602DebugData Displays information about active CIFS sessions and 603 shares, features enabled as well as the cifs.ko 604 version. 605Stats Lists summary resource usage information as well as per 606 share statistics. 607 608Configuration pseudo-files: 609SecurityFlags Flags which control security negotiation and 610 also packet signing. Authentication (may/must) 611 flags (e.g. for NTLM and/or NTLMv2) may be combined with 612 the signing flags. Specifying two different password 613 hashing mechanisms (as "must use") on the other hand 614 does not make much sense. Default flags are 615 0x07007 616 (NTLM, NTLMv2 and packet signing allowed). The maximum 617 allowable flags if you want to allow mounts to servers 618 using weaker password hashes is 0x37037 (lanman, 619 plaintext, ntlm, ntlmv2, signing allowed). Some 620 SecurityFlags require the corresponding menuconfig 621 options to be enabled (lanman and plaintext require 622 CONFIG_CIFS_WEAK_PW_HASH for example). Enabling 623 plaintext authentication currently requires also 624 enabling lanman authentication in the security flags 625 because the cifs module only supports sending 626 laintext passwords using the older lanman dialect 627 form of the session setup SMB. (e.g. for authentication 628 using plain text passwords, set the SecurityFlags 629 to 0x30030): 630 631 may use packet signing 0x00001 632 must use packet signing 0x01001 633 may use NTLM (most common password hash) 0x00002 634 must use NTLM 0x02002 635 may use NTLMv2 0x00004 636 must use NTLMv2 0x04004 637 may use Kerberos security 0x00008 638 must use Kerberos 0x08008 639 may use lanman (weak) password hash 0x00010 640 must use lanman password hash 0x10010 641 may use plaintext passwords 0x00020 642 must use plaintext passwords 0x20020 643 (reserved for future packet encryption) 0x00040 644 645cifsFYI If set to non-zero value, additional debug information 646 will be logged to the system error log. This field 647 contains three flags controlling different classes of 648 debugging entries. The maximum value it can be set 649 to is 7 which enables all debugging points (default 0). 650 Some debugging statements are not compiled into the 651 cifs kernel unless CONFIG_CIFS_DEBUG2 is enabled in the 652 kernel configuration. cifsFYI may be set to one or 653 nore of the following flags (7 sets them all): 654 655 log cifs informational messages 0x01 656 log return codes from cifs entry points 0x02 657 log slow responses (ie which take longer than 1 second) 658 CONFIG_CIFS_STATS2 must be enabled in .config 0x04 659 660 661traceSMB If set to one, debug information is logged to the 662 system error log with the start of smb requests 663 and responses (default 0) 664LookupCacheEnable If set to one, inode information is kept cached 665 for one second improving performance of lookups 666 (default 1) 667LinuxExtensionsEnabled If set to one then the client will attempt to 668 use the CIFS "UNIX" extensions which are optional 669 protocol enhancements that allow CIFS servers 670 to return accurate UID/GID information as well 671 as support symbolic links. If you use servers 672 such as Samba that support the CIFS Unix 673 extensions but do not want to use symbolic link 674 support and want to map the uid and gid fields 675 to values supplied at mount (rather than the 676 actual values, then set this to zero. (default 1) 677 678These experimental features and tracing can be enabled by changing flags in 679/proc/fs/cifs (after the cifs module has been installed or built into the 680kernel, e.g. insmod cifs). To enable a feature set it to 1 e.g. to enable 681tracing to the kernel message log type: 682 683 echo 7 > /proc/fs/cifs/cifsFYI 684 685cifsFYI functions as a bit mask. Setting it to 1 enables additional kernel 686logging of various informational messages. 2 enables logging of non-zero 687SMB return codes while 4 enables logging of requests that take longer 688than one second to complete (except for byte range lock requests). 689Setting it to 4 requires CONFIG_CIFS_STATS2 to be set in kernel configuration 690(.config). Setting it to seven enables all three. Finally, tracing 691the start of smb requests and responses can be enabled via: 692 693 echo 1 > /proc/fs/cifs/traceSMB 694 695Per share (per client mount) statistics are available in /proc/fs/cifs/Stats. 696Additional information is available if CONFIG_CIFS_STATS2 is enabled in the 697kernel configuration (.config). The statistics returned include counters which 698represent the number of attempted and failed (ie non-zero return code from the 699server) SMB3 (or cifs) requests grouped by request type (read, write, close etc.). 700Also recorded is the total bytes read and bytes written to the server for 701that share. Note that due to client caching effects this can be less than the 702number of bytes read and written by the application running on the client. 703Statistics can be reset to zero by "echo 0 > /proc/fs/cifs/Stats" which may be 704useful if comparing performance of two different scenarios. 705 706Also note that "cat /proc/fs/cifs/DebugData" will display information about 707the active sessions and the shares that are mounted. 708 709Enabling Kerberos (extended security) works but requires version 1.2 or later 710of the helper program cifs.upcall to be present and to be configured in the 711/etc/request-key.conf file. The cifs.upcall helper program is from the Samba 712project(http://www.samba.org). NTLM and NTLMv2 and LANMAN support do not 713require this helper. Note that NTLMv2 security (which does not require the 714cifs.upcall helper program), instead of using Kerberos, is sufficient for 715some use cases. 716 717DFS support allows transparent redirection to shares in an MS-DFS name space. 718In addition, DFS support for target shares which are specified as UNC 719names which begin with host names (rather than IP addresses) requires 720a user space helper (such as cifs.upcall) to be present in order to 721translate host names to ip address, and the user space helper must also 722be configured in the file /etc/request-key.conf. Samba, Windows servers and 723many NAS appliances support DFS as a way of constructing a global name 724space to ease network configuration and improve reliability. 725 726To use cifs Kerberos and DFS support, the Linux keyutils package should be 727installed and something like the following lines should be added to the 728/etc/request-key.conf file: 729 730create cifs.spnego * * /usr/local/sbin/cifs.upcall %k 731create dns_resolver * * /usr/local/sbin/cifs.upcall %k 732 733CIFS kernel module parameters 734============================= 735These module parameters can be specified or modified either during the time of 736module loading or during the runtime by using the interface 737 /proc/module/cifs/parameters/<param> 738 739i.e. echo "value" > /sys/module/cifs/parameters/<param> 740 7411. enable_oplocks - Enable or disable oplocks. Oplocks are enabled by default. 742 [Y/y/1]. To disable use any of [N/n/0]. 743 744
