1MOUNT.CIFS(8) System Administration tools MOUNT.CIFS(8)
2
6 mount.cifs - mount using the Common Internet File System (CIFS)
7
9 mount.cifs {service} {mount-point} [-o options]
10
12 This tool is part of the cifs-utils suite.
13 mount.cifs mounts a Linux CIFS filesystem. It is usually invoked
15 indirectly by the mount(8) command when using the "-t cifs" option.
16 This command only works in Linux, and the kernel must support the cifs
17 filesystem. The CIFS protocol is the successor to the SMB protocol and
18 is supported by most Windows servers and many other commercial servers
19 and Network Attached Storage appliances as well as by the popular Open
20 Source server Samba.
21 The mount.cifs utility attaches the UNC name (exported network
23 resource) specified as service (using //server/share syntax, where
24 "server" is the server name or IP address and "share" is the name of
25 the share) to the local directory mount-point.
26 Options to mount.cifs are specified as a comma-separated list of
28 key=value pairs. It is possible to send options other than those listed
29 here, assuming that the cifs filesystem kernel module (cifs.ko)
30 supports them. Unrecognized cifs mount options passed to the cifs vfs
31 kernel code will be logged to the kernel log.
32 mount.cifs causes the cifs vfs to launch a thread named cifsd. After
34 mounting it keeps running until the mounted resource is unmounted
35 (usually via the umount utility).
36 mount.cifs -V command displays the version of cifs mount helper.
38 modinfo cifs command displays the version of cifs module.
40
42 username=arg
43 specifies the username to connect as. If this is not given, then
44 the environment variable USER is used.
45 Earlier versions of mount.cifs also allowed one to specify the
47 username in a "user%password" or "workgroup/user" or
48 "workgroup/user%password" to allow the password and workgroup to be
49 specified as part of the username. Support for those alternate
50 username formats is now deprecated and should no longer be used.
51 Users should use the discrete "password=" and "domain=" to specify
52 those values. While some versions of the cifs kernel module accept
53 "user=" as an abbreviation for this option, its use can confuse the
54 standard mount program into thinking that this is a non-superuser
55 mount. It is therefore recommended to use the full "username="
56 option name.
57 password=arg
59 specifies the CIFS password. If this option is not given then the
60 environment variable PASSWD is used. If the password is not
61 specified directly or indirectly via an argument to mount,
62 mount.cifs will prompt for a password, unless the guest option is
63 specified.
64 Note that a password which contains the delimiter character (i.e. a
66 comma ´,´) will fail to be parsed correctly on the command line.
67 However, the same password defined in the PASSWD environment
68 variable or via a credentials file (see below) or entered at the
69 password prompt will be read correctly.
70 credentials=filename
72 specifies a file that contains a username and/or password and
73 optionally the name of the workgroup. The format of the file is:
74 username=value
76 password=value
77 domain=value
78 This is preferred over having passwords in plaintext in a shared
80 file, such as /etc/fstab. Be sure to protect any credentials file
81 properly.
82 uid=arg
84 sets the uid that will own all files or directories on the mounted
85 filesystem when the server does not provide ownership information.
86 It may be specified as either a username or a numeric uid. When not
87 specified, the default is uid 0. The mount.cifs helper must be at
88 version 1.10 or higher to support specifying the uid in non-numeric
89 form. See the section on FILE AND DIRECTORY OWNERSHIP AND
90 PERMISSIONS below for more information.
91 forceuid
93 instructs the client to ignore any uid provided by the server for
94 files and directories and to always assign the owner to be the
95 value of the uid= option. See the section on FILE AND DIRECTORY
96 OWNERSHIP AND PERMISSIONS below for more information.
97 cruid=arg
99 sets the uid of the owner of the credentials cache. This is
100 primarily useful with sec=krb5. The default is the real uid of the
101 process performing the mount. Setting this parameter directs the
102 upcall to look for a credentials cache owned by that user.
103 gid=arg
105 sets the gid that will own all files or directories on the mounted
106 filesystem when the server does not provide ownership information.
107 It may be specified as either a groupname or a numeric gid. When
108 not specified, the default is gid 0. The mount.cifs helper must be
109 at version 1.10 or higher to support specifying the gid in
110 non-numeric form. See the section on FILE AND DIRECTORY OWNERSHIP
111 AND PERMISSIONS below for more information.
112 forcegid
114 instructs the client to ignore any gid provided by the server for
115 files and directories and to always assign the owner to be the
116 value of the gid= option. See the section on FILE AND DIRECTORY
117 OWNERSHIP AND PERMISSIONS below for more information.
118 port=arg
120 sets the port number on which the client will attempt to contact
121 the CIFS server. If this value is specified, look for an existing
122 connection with this port, and use that if one exists. If one
123 doesn't exist, try to create a new connection on that port. If that
124 connection fails, return an error. If this value isn't specified,
125 look for an existing connection on port 445 or 139. If no such
126 connection exists, try to connect on port 445 first and then port
127 139 if that fails. Return an error if both fail.
128 servernetbiosname=arg
130 Specify the server netbios name (RFC1001 name) to use when
131 attempting to setup a session to the server. Although rarely needed
132 for mounting to newer servers, this option is needed for mounting
133 to some older servers (such as OS/2 or Windows 98 and Windows ME)
134 since when connecting over port 139 they, unlike most newer
135 servers, do not support a default server name. A server name can be
136 up to 15 characters long and is usually uppercased.
137 servern=arg
139 Synonym for servernetbiosname.
140 netbiosname=arg
142 When mounting to servers via port 139, specifies the RFC1001 source
143 name to use to represent the client netbios machine name when doing
144 the RFC1001 netbios session initialize.
145 file_mode=arg
147 If the server does not support the CIFS Unix extensions this
148 overrides the default file mode.
149 dir_mode=arg
151 If the server does not support the CIFS Unix extensions this
152 overrides the default mode for directories.
153 ip=arg
155 sets the destination IP address. This option is set automatically
156 if the server name portion of the requested UNC name can be
157 resolved so rarely needs to be specified by the user.
158 domain=arg
160 sets the domain (workgroup) of the user
161 guest
163 don´t prompt for a password
164 iocharset
166 Charset used to convert local path names to and from Unicode.
167 Unicode is used by default for network path names if the server
168 supports it. If iocharset is not specified then the nls_default
169 specified during the local client kernel build will be used. If
170 server does not support Unicode, this parameter is unused.
171 ro
173 mount read-only
174 rw
176 mount read-write
177 setuids
179 If the CIFS Unix extensions are negotiated with the server the
180 client will attempt to set the effective uid and gid of the local
181 process on newly created files, directories, and devices (create,
182 mkdir, mknod). If the CIFS Unix Extensions are not negotiated, for
183 newly created files and directories instead of using the default
184 uid and gid specified on the the mount, cache the new file´s uid
185 and gid locally which means that the uid for the file can change
186 when the inode is reloaded (or the user remounts the share).
187 nosetuids
189 The client will not attempt to set the uid and gid on on newly
190 created files, directories, and devices (create, mkdir, mknod)
191 which will result in the server setting the uid and gid to the
192 default (usually the server uid of the user who mounted the share).
193 Letting the server (rather than the client) set the uid and gid is
194 the default.If the CIFS Unix Extensions are not negotiated then the
195 uid and gid for new files will appear to be the uid (gid) of the
196 mounter or the uid (gid) parameter specified on the mount.
197 perm
199 Client does permission checks (vfs_permission check of uid and gid
200 of the file against the mode and desired operation), Note that this
201 is in addition to the normal ACL check on the target machine done
202 by the server software. Client permission checking is enabled by
203 default.
204 noperm
206 Client does not do permission checks. This can expose files on this
207 mount to access by other users on the local client system. It is
208 typically only needed when the server supports the CIFS Unix
209 Extensions but the UIDs/GIDs on the client and server system do not
210 match closely enough to allow access by the user doing the mount.
211 Note that this does not affect the normal ACL check on the target
212 machine done by the server software (of the server ACL against the
213 user name provided at mount time).
214 dynperm
216 Instructs the server to maintain ownership and permissions in
217 memory that can´t be stored on the server. This information can
218 disappear at any time (whenever the inode is flushed from the
219 cache), so while this may help make some applications work, it´s
220 behavior is somewhat unreliable. See the section below on FILE AND
221 DIRECTORY OWNERSHIP AND PERMISSIONS for more information.
222 cache=
224 Cache mode. See the section below on CACHE COHERENCY for details.
225 Allowed values are:
226 · none: do not cache file data at all
228 · strict: follow the CIFS/SMB2 protocol strictly
230 · loose: allow loose caching semantics
232 The default in kernels prior to 3.7 was "loose". As of kernel 3.7
234 the default is "strict".
235 directio
237 Do not do inode data caching on files opened on this mount. This
238 precludes mmaping files on this mount. In some cases with fast
239 networks and little or no caching benefits on the client (e.g. when
240 the application is doing large sequential reads bigger than page
241 size without rereading the same data) this can provide better
242 performance than the default behavior which caches reads
243 (readahead) and writes (writebehind) through the local Linux client
244 pagecache if oplock (caching token) is granted and held. Note that
245 direct allows write operations larger than page size to be sent to
246 the server. On some kernels this requires the cifs.ko module to be
247 built with the CIFS_EXPERIMENTAL configure option.
248 This option is will be deprecated in 3.7. Users should use
250 cache=none instead on more recent kernels.
251 strictcache
253 Use for switching on strict cache mode. In this mode the client
254 reads from the cache all the time it has Oplock Level II, otherwise
255 - read from the server. As for write - the client stores a data in
256 the cache in Exclusive Oplock case, otherwise - write directly to
257 the server.
258 This option is will be deprecated in 3.7. Users should use
260 cache=strict instead on more recent kernels.
261 rwpidforward
263 Forward pid of a process who opened a file to any read or write
264 operation on that file. This prevent applications like WINE from
265 failing on read and write if we use mandatory brlock style.
266 mapchars
268 Translate six of the seven reserved characters (not backslash, but
269 including the colon, question mark, pipe, asterik, greater than and
270 less than characters) to the remap range (above 0xF000), which also
271 allows the CIFS client to recognize files created with such
272 characters by Windows´s POSIX emulation. This can also be useful
273 when mounting to most versions of Samba (which also forbids
274 creating and opening files whose names contain any of these seven
275 characters). This has no effect if the server does not support
276 Unicode on the wire. Please note that the files created with
277 mapchars mount option may not be accessible if the share is mounted
278 without that option.
279 nomapchars
281 Do not translate any of these seven characters (default)
282 intr
284 currently unimplemented
285 nointr
287 (default) currently unimplemented
288 hard
290 The program accessing a file on the cifs mounted file system will
291 hang when the server crashes.
292 soft
294 (default) The program accessing a file on the cifs mounted file
295 system will not hang when the server crashes and will return errors
296 to the user application.
297 noacl
299 Do not allow POSIX ACL operations even if server would support
300 them.
301 The CIFS client can get and set POSIX ACLs (getfacl, setfacl) to
303 Samba servers version 3.0.10 and later. Setting POSIX ACLs requires
304 enabling both CIFS_XATTR and then CIFS_POSIX support in the CIFS
305 configuration options when building the cifs module. POSIX ACL
306 support can be disabled on a per mount basis by specifying "noacl"
307 on mount.
308 cifsacl
310 This option is used to map CIFS/NTFS ACLs to/from Linux permission
311 bits, map SIDs to/from UIDs and GIDs, and get and set Security
312 Descriptors.
313 See sections on CIFS/NTFS ACL, SID/UID/GID MAPPING, SECURITY
315 DESCRIPTORS for more information.
316 backupuid=arg
318 File access by this user shall be done with the backup intent flag
319 set. Either a name or an id must be provided as an argument, there
320 are no default values.
321 See section ACCESSING FILES WITH BACKUP INTENT for more details
323 backupgid=arg
325 File access by users who are members of this group shall be done
326 with the backup intent flag set. Either a name or an id must be
327 provided as an argument, there are no default values.
328 See section ACCESSING FILES WITH BACKUP INTENT for more details
330 nocase
332 Request case insensitive path name matching (case sensitive is the
333 default if the server suports it).
334 ignorecase
336 Synonym for nocase.
337 sec=
339 Security mode. Allowed values are:
340 · none - attempt to connection as a null user (no name)
342 · krb5 - Use Kerberos version 5 authentication
344 · krb5i - Use Kerberos authentication and forcibly enable packet
346 signing
347 · ntlm - Use NTLM password hashing
349 · ntlmi - Use NTLM password hashing and force packet signing
351 · ntlmv2 - Use NTLMv2 password hashing
353 · ntlmv2i - Use NTLMv2 password hashing and force packet signing
355 · ntlmssp - Use NTLMv2 password hashing encapsulated in Raw
357 NTLMSSP message
358 · ntlmsspi - Use NTLMv2 password hashing encapsulated in Raw
360 NTLMSSP message, and force packet signing
361 The default in mainline kernel versions prior to v3.8 was sec=ntlm.
363 In v3.8, the default was changed to sec=ntlmssp.
364 If the server requires signing during protocol negotiation, then it
366 may be enabled automatically. Packet signing may also be enabled
367 automatically if it's enabled in /proc/fs/cifs/SecurityFlags.
368 nobrl
370 Do not send byte range lock requests to the server. This is
371 necessary for certain applications that break with cifs style
372 mandatory byte range locks (and most cifs servers do not yet
373 support requesting advisory byte range locks).
374 sfu
376 When the CIFS Unix Extensions are not negotiated, attempt to create
377 device files and fifos in a format compatible with Services for
378 Unix (SFU). In addition retrieve bits 10-12 of the mode via the
379 SETFILEBITS extended attribute (as SFU does). In the future the
380 bottom 9 bits of the mode mode also will be emulated using queries
381 of the security descriptor (ACL). [NB: requires version 1.39 or
382 later of the CIFS VFS. To recognize symlinks and be able to create
383 symlinks in an SFU interoperable form requires version 1.40 or
384 later of the CIFS VFS kernel module.
385 mfsymlinks
387 Enable support for Minshall+French symlinks(see
388 http://wiki.samba.org/index.php/UNIX_Extensions#Minshall.2BFrench_symlinks).
389 This option is ignored when specified together with the 'sfu'
390 option. Minshall+French symlinks are used even if the server
391 supports the CIFS Unix Extensions.
392 serverino
394 Use inode numbers (unique persistent file identifiers) returned by
395 the server instead of automatically generating temporary inode
396 numbers on the client. Although server inode numbers make it easier
397 to spot hardlinked files (as they will have the same inode numbers)
398 and inode numbers may be persistent (which is userful for some
399 sofware), the server does not guarantee that the inode numbers are
400 unique if multiple server side mounts are exported under a single
401 share (since inode numbers on the servers might not be unique if
402 multiple filesystems are mounted under the same shared higher level
403 directory). Note that not all servers support returning server
404 inode numbers, although those that support the CIFS Unix
405 Extensions, and Windows 2000 and later servers typically do support
406 this (although not necessarily on every local server filesystem).
407 Parameter has no effect if the server lacks support for returning
408 inode numbers or equivalent. This behavior is enabled by default.
409 noserverino
411 Client generates inode numbers itself rather than using the actual
412 ones from the server.
413 See section INODE NUMBERS for more information.
415 nounix
417 Disable the CIFS Unix Extensions for this mount. This can be useful
418 in order to turn off multiple settings at once. This includes POSIX
419 acls, POSIX locks, POSIX paths, symlink support and retrieving
420 uids/gids/mode from the server. This can also be useful to work
421 around a bug in a server that supports Unix Extensions.
422 See section INODE NUMBERS for more information.
424 nouser_xattr
426 Do not allow getfattr/setfattr to get/set xattrs, even if server
427 would support it otherwise. The default is for xattr support to be
428 enabled.
429 rsize=bytes
431 Maximum amount of data that the kernel will request in a read
432 request in bytes. Prior to kernel 3.2.0, the default was 16k, and
433 the maximum size was limited by the CIFSMaxBufSize module
434 parameter. As of kernel 3.2.0, the behavior varies according to
435 whether POSIX extensions are enabled on the mount and the server
436 supports large POSIX reads. If they are, then the default is 1M,
437 and the maxmimum is 16M. If they are not supported by the server,
438 then the default is 60k and the maximum is around 127k. The reason
439 for the 60k is because it's the maximum size read that windows
440 servers can fill. Note that this value is a maximum, and the client
441 may settle on a smaller size to accomodate what the server
442 supports. In kernels prior to 3.2.0, no negotiation is performed.
443 wsize=bytes
445 Maximum amount of data that the kernel will send in a write request
446 in bytes. Prior to kernel 3.0.0, the default and maximum was 57344
447 (14 * 4096 pages). As of 3.0.0, the default depends on whether the
448 client and server negotiate large writes via POSIX extensions. If
449 they do, then the default is 1M, and the maximum allowed is 16M. If
450 they do not, then the default is 65536 and the maximum allowed is
451 131007.
452 Note that this value is just a starting point for negotiation in
454 3.0.0 and up. The client and server may negotiate this size
455 downward according to the server's capabilities. In kernels prior
456 to 3.0.0, no negotiation is performed. It can end up with an
457 existing superblock if this value isn't specified or it's greater
458 or equal than the existing one.
459 fsc
461 Enable local disk caching using FS-Cache for CIFS. This option
462 could be useful to improve performance on a slow link, heavily
463 loaded server and/or network where reading from the disk is faster
464 than reading from the server (over the network). This could also
465 impact the scalability positively as the number of calls to the
466 server are reduced. But, be warned that local caching is not
467 suitable for all workloads, for e.g., read-once type workloads. So,
468 you need to consider carefully the situation/workload before using
469 this option. Currently, local disk caching is enabled for CIFS
470 files opened as read-only.
471 NOTE: This feature is available only in the recent kernels that
473 have been built with the kernel config option CONFIG_CIFS_FSCACHE.
474 You also need to have cachefilesd daemon installed and running to
475 make the cache operational.
476 multiuser
478 Map user accesses to individual credentials when accessing the
479 server. By default, CIFS mounts only use a single set of user
480 credentials (the mount credentials) when accessing a share. With
481 this option, the client instead creates a new session with the
482 server using the user's credentials whenever a new user accesses
483 the mount. Further accesses by that user will also use those
484 credentials. Because the kernel cannot prompt for passwords,
485 multiuser mounts are limited to mounts using sec= options that
486 don't require passwords.
487 With this change, it's feasible for the server to handle
489 permissions enforcement, so this option also implies "noperm".
490 Furthermore, when unix extensions aren't in use and the
491 administrator has not overriden ownership using the uid= or gid=
492 options, ownership of files is presented as the current user
493 accessing the share.
494 actimeo=arg
496 The time (in seconds) that the CIFS client caches attributes of a
497 file or directory before it requests attribute information from a
498 server. During this period the changes that occur on the server
499 remain undetected until the client checks the server again.
500 By default, the attribute cache timeout is set to 1 second. This
502 means more frequent on-the-wire calls to the server to check
503 whether attributes have changed which could impact performance.
504 With this option users can make a tradeoff between performance and
505 cache metadata correctness, depending on workload needs. Shorter
506 timeouts mean better cache coherency, but frequent increased number
507 of calls to the server. Longer timeouts mean a reduced number of
508 calls to the server but looser cache coherency. The actimeo value
509 is a positive integer that can hold values between 0 and a maximum
510 value of 2^30 * HZ (frequency of timer interrupt) setting.
511 noposixpaths
513 If unix extensions are enabled on a share, then the client will
514 typically allow filenames to include any character besides '/' in a
515 pathname component, and will use forward slashes as a pathname
516 delimiter. This option prevents the client from attempting to
517 negotiate the use of posix-style pathnames to the server.
518 posixpaths
520 Inverse of noposixpaths.
521 prefixpath=
523 It's possible to mount a subdirectory of a share. The preferred way
524 to do this is to append the path to the UNC when mounting. However,
525 it's also possible to do the same by setting this option and
526 providing the path there.
527 vers=
529 SMB protocol version. Allowed values are:
530 · 1.0 - The classic CIFS/SMBv1 protocol. This is the default.
532 · 2.0 - The SMBv2.002 protocol. This was initially introduced in
534 Windows Vista Service Pack 1, and Windows Server 2008. Note
535 that the initial release version of Windows Vista spoke a
536 slightly different dialect (2.000) that is not supported.
537 · 2.1 - The SMBv2.1 protocol that was introduced in Microsoft
539 Windows 7 and Windows Server 2008R2.
540 · 3.0 - The SMBv3.0 protocol that was introduced in Microsoft
542 Windows 8 and Windows Server 2012.
543 Note too that while this option governs the protocol version used,
545 not all features of each version are available.
546 --verbose
548 Print additional debugging information for the mount. Note that
549 this parameter must be specified before the -o. For example:
550 mount -t cifs //server/share /mnt --verbose -o user=username
552
554 It´s generally preferred to use forward slashes (/) as a delimiter in
555 service names. They are considered to be the "universal delimiter"
556 since they are generally not allowed to be embedded within path
557 components on Windows machines and the client can convert them to
558 blackslashes (\) unconditionally. Conversely, backslash characters are
559 allowed by POSIX to be part of a path component, and can´t be
560 automatically converted in the same way.
561 mount.cifs will attempt to convert backslashes to forward slashes where
563 it´s able to do so, but it cannot do so in any path component following
564 the sharename.
565
567 When Unix Extensions are enabled, we use the actual inode number
568 provided by the server in response to the POSIX calls as an inode
569 number.
570 When Unix Extensions are disabled and "serverino" mount option is
572 enabled there is no way to get the server inode number. The client
573 typically maps the server-assigned "UniqueID" onto an inode number.
574 Note that the UniqueID is a different value from the server inode
576 number. The UniqueID value is unique over the scope of the entire
577 server and is often greater than 2 power 32. This value often makes
578 programs that are not compiled with LFS (Large File Support), to
579 trigger a glibc EOVERFLOW error as this won´t fit in the target
580 structure field. It is strongly recommended to compile your programs
581 with LFS support (i.e. with -D_FILE_OFFSET_BITS=64) to prevent this
582 problem. You can also use "noserverino" mount option to generate inode
583 numbers smaller than 2 power 32 on the client. But you may not be able
584 to detect hardlinks properly.
585
587 With a network filesystem such as CIFS or NFS, the client must contend
588 with the fact that activity on other clients or the server could change
589 the contents or attributes of a file without the client being aware of
590 it. One way to deal with such a problem is to mandate that all file
591 accesses go to the server directly. This is performance prohibitive
592 however, so most protocols have some mechanism to allow the client to
593 cache data locally.
594 The CIFS protocol mandates (in effect) that the client should not cache
596 file data unless it holds an opportunistic lock (aka oplock) or a
597 lease. Both of these entities allow the client to guarantee certain
598 types of exclusive access to a file so that it can access its contents
599 without needing to continually interact with the server. The server
600 will call back the client when it needs to revoke either of them and
601 allow the client a certain amount of time to flush any cached data.
602 The cifs client uses the kernel's pagecache to cache file data. Any I/O
604 that's done through the pagecache is generally page-aligned. This can
605 be problematic when combined with byte-range locks as Windows' locking
606 is mandatory and can block reads and writes from occurring.
607 cache=none means that the client never utilizes the cache for normal
609 reads and writes. It always accesses the server directly to satisfy a
610 read or write request.
611 cache=strict means that the client will attempt to follow the CIFS/SMB2
613 protocol strictly. That is, the cache is only trusted when the client
614 holds an oplock. When the client does not hold an oplock, then the
615 client bypasses the cache and accesses the server directly to satisfy a
616 read or write request. By doing this, the client avoids problems with
617 byte range locks. Additionally, byte range locks are cached on the
618 client when it holds an oplock and are "pushed" to the server when that
619 oplock is recalled.
620 cache=loose allows the client to use looser protocol semantics which
622 can sometimes provide better performance at the expense of cache
623 coherency. File access always involves the pagecache. When an oplock or
624 lease is not held, then the client will attempt to flush the cache soon
625 after a write to a file. Note that that flush does not necessarily
626 occur before a write system call returns.
627 In the case of a read without holding an oplock, the client will
629 attempt to periodically check the attributes of the file in order to
630 ascertain whether it has changed and the cache might no longer be
631 valid. This mechanism is much like the one that NFSv2/3 use for cache
632 coherency, but it particularly problematic with CIFS. Windows is quite
633 "lazy" with respect to updating the "LastWriteTime" field that the
634 client uses to verify this. The effect is that cache=loose can cause
635 data corruption when multiple readers and writers are working on the
636 same files.
637 Because of this, when multiple clients are accessing the same set of
639 files, then cache=strict is recommended. That helps eliminate problems
640 with cache coherency by following the CIFS/SMB2 protocols more
641 strictly.
642 Note too that no matter what caching model is used, the client will
644 always use the pagecache to handle mmap'ed files. Writes to mmap'ed
645 files are only guaranteed to be flushed to the server when msync() is
646 called, or on close().
647 The default in kernels prior to 3.7 was "loose". As of 3.7, the default
649 is "strict".
650
652 This option is used to work with file objects which posses Security
653 Descriptors and CIFS/NTFS ACL instead of UID, GID, file permission
654 bits, and POSIX ACL as user authentication model. This is the most
655 common authentication model for CIFS servers and is the one used by
656 Windows.
657 Support for this requires both CIFS_XATTR and CIFS_ACL support in the
659 CIFS configuration options when building the cifs module.
660 A CIFS/NTFS ACL is mapped to file permission bits using an algorithm
662 specified in the following Microsoft TechNet document:
663 · http://technet.microsoft.com/en-us/library/bb463216.aspx
665 In order to map SIDs to/from UIDs and GIDs, the following is required:
667 · a kernel upcall to the cifs.idmap utility set up via request-
669 key.conf(5)
670 · winbind support configured via nsswitch.conf(5) and smb.conf(5)
672 Please refer to the respective manpages of cifs.idmap(8) and
674 winbindd(8) for more information.
675 Security descriptors for a file object can be retrieved and set
677 directly using extended attribute named system.cifs_acl. The security
678 descriptors presented via this interface are "raw" blobs of data and
679 need a userspace utility to either parse and format or to assemble it
680 such as getcifsacl(1) and setcifsacl(1) respectively.
681 Some of the things to consider while using this mount option:
683 · There may be an increased latency when handling metadata due to
685 additional requests to get and set security descriptors.
686 · The mapping between a CIFS/NTFS ACL and POSIX file permission bits
688 is imperfect and some ACL information may be lost in the
689 translation.
690 · If either upcall to cifs.idmap is not setup correctly or winbind is
692 not configured and running, ID mapping will fail. In that case uid
693 and gid will default to either to those values of the share or to
694 the values of uid and/or gid mount options if specified.
695
697 For an user on the server, desired access to a file is determined by
698 the permissions and rights associated with that file. This is
699 typically accomplished using owenrship and ACL. For a user who does
700 not have access rights to a file, it is still possible to access that
701 file for a specific or a targeted purpose by granting special rights.
702 One of the specific purposes is to access a file with the intent to
703 either backup or restore i.e. backup intent. The right to access a
704 file with the backup intent can typically be granted by making that
705 user a part of the built-in group Backup Operators. Thus, when this
706 user attempts to open a file with the backup intent, open request is
707 sent by setting the bit FILE_OPEN_FOR_BACKUP_INTENT as one of the
708 CreateOptions.
709 As an example, on a Windows server, a user named testuser, cannot open
711 this file with such a security descriptor.
712 REVISION:0x1
714 CONTROL:0x9404
715 OWNER:Administrator
716 GROUP:Domain Users
717 ACL:Administrator:ALLOWED/0x0/FULL
718 But the user testuser, if it becomes part of the group Backup
720 Operators, can open the file with the backup intent.
721 Any user on the client side who can authenticate as such a user on the
723 server, can access the files with the backup intent. But it is
724 desirable and preferable for security reasons amongst many, to restrict
725 this special right.
726 The mount option backupuid is used to restrict this special right to a
728 user which is specified by either a name or an id. The mount option
729 backupgid is used to restrict this special right to the users in a
730 group which is specified by either a name or an id. Only users maching
731 either backupuid or backupgid shall attempt to access files with backup
732 intent. These two mount options can be used together.
733
735 The core CIFS protocol does not provide unix ownership information or
736 mode for files and directories. Because of this, files and directories
737 will generally appear to be owned by whatever values the uid= or gid=
738 options are set, and will have permissions set to the default file_mode
739 and dir_mode for the mount. Attempting to change these values via
740 chmod/chown will return success but have no effect.
741 When the client and server negotiate unix extensions, files and
743 directories will be assigned the uid, gid, and mode provided by the
744 server. Because CIFS mounts are generally single-user, and the same
745 credentials are used no matter what user accesses the mount, newly
746 created files and directories will generally be given ownership
747 corresponding to whatever credentials were used to mount the share.
748 If the uid´s and gid´s being used do not match on the client and
750 server, the forceuid and forcegid options may be helpful. Note however,
751 that there is no corresponding option to override the mode. Permissions
752 assigned to a file when forceuid or forcegid are in effect may not
753 reflect the the real permissions.
754 When unix extensions are not negotiated, it´s also possible to emulate
756 them locally on the server using the "dynperm" mount option. When this
757 mount option is in effect, newly created files and directories will
758 receive what appear to be proper permissions. These permissions are not
759 stored on the server however and can disappear at any time in the
760 future (subject to the whims of the kernel flushing out the inode
761 cache). In general, this mount option is discouraged.
762 It´s also possible to override permission checking on the client
764 altogether via the noperm option. Server-side permission checks cannot
765 be overriden. The permission checks done by the server will always
766 correspond to the credentials used to mount the share, and not
767 necessarily to the user who is accessing the share.
768
770 The variable USER may contain the username of the person to be used to
771 authenticate to the server. The variable can be used to set both
772 username and password by using the format username%password.
773 The variable PASSWD may contain the password of the person using the
775 client.
776 The variable PASSWD_FILE may contain the pathname of a file to read the
778 password from. A single line of input is read and used as the password.
779
781 This command may be used only by root, unless installed setuid, in
782 which case the noeexec and nosuid mount flags are enabled. When
783 installed as a setuid program, the program follows the conventions set
784 forth by the mount program for user mounts, with the added restriction
785 that users must be able to chdir() into the mountpoint prior to the
786 mount in order to be able to mount onto it.
787 Some samba client tools like smbclient(8) honour client-side
789 configuration parameters present in smb.conf. Unlike those client
790 tools, mount.cifs ignores smb.conf completely.
791
793 The primary mechanism for making configuration changes and for reading
794 debug information for the cifs vfs is via the Linux /proc filesystem.
795 In the directory /proc/fs/cifs are various configuration files and
796 pseudo files which can display debug information. There are additional
797 startup options such as maximum buffer size and number of buffers which
798 only may be set when the kernel cifs vfs (cifs.ko module) is loaded.
799 These can be seen by running the modinfo utility against the file
800 cifs.ko which will list the options that may be passed to cifs during
801 module installation (device driver load). For more information see the
802 kernel file fs/cifs/README.
803
805 Mounting using the CIFS URL specification is currently not supported.
806 The credentials file does not handle usernames or passwords with
808 leading space.
809 Note that the typical response to a bug report is a suggestion to try
811 the latest version first. So please try doing that first, and always
812 include which versions you use of relevant software when reporting bugs
813 (minimum: mount.cifs (try mount.cifs -V), kernel (see /proc/version)
814 and server type you are trying to contact.
815
817 This man page is correct for version 1.74 of the cifs vfs filesystem
818 (roughly Linux kernel 3.0).
819
821 cifs.upcall(8), getcifsacl(1), setcifsacl(1)
822 Documentation/filesystems/cifs.txt and fs/cifs/README in the linux
824 kernel source tree may contain additional options and information.
825
827 Steve French
828 The syntax and manpage were loosely based on that of smbmount. It was
830 converted to Docbook/XML by Jelmer Vernooij.
831 The maintainer of the Linux cifs vfs and the userspace tool mount.cifs
833 is Steve French. The Linux CIFS Mailing list is the preferred place to
834 ask questions regarding these programs.
835cifs-utils 02/07/2010 MOUNT.CIFS(8)