1 |
62 |
marcus.erl |
The CIFS VFS support for Linux supports many advanced network filesystem
|
2 |
|
|
features such as hierarchical dfs like namespace, hardlinks, locking and more.
|
3 |
|
|
It was designed to comply with the SNIA CIFS Technical Reference (which
|
4 |
|
|
supersedes the 1992 X/Open SMB Standard) as well as to perform best practice
|
5 |
|
|
practical interoperability with Windows 2000, Windows XP, Samba and equivalent
|
6 |
|
|
servers.
|
7 |
|
|
|
8 |
|
|
For questions or bug reports please contact:
|
9 |
|
|
sfrench@samba.org (sfrench@us.ibm.com)
|
10 |
|
|
|
11 |
|
|
Build instructions:
|
12 |
|
|
==================
|
13 |
|
|
For Linux 2.4:
|
14 |
|
|
1) Get the kernel source (e.g.from http://www.kernel.org)
|
15 |
|
|
and download the cifs vfs source (see the project page
|
16 |
|
|
at http://us1.samba.org/samba/Linux_CIFS_client.html)
|
17 |
|
|
and change directory into the top of the kernel directory
|
18 |
|
|
then patch the kernel (e.g. "patch -p1 < cifs_24.patch")
|
19 |
|
|
to add the cifs vfs to your kernel configure options if
|
20 |
|
|
it has not already been added (e.g. current SuSE and UL
|
21 |
|
|
users do not need to apply the cifs_24.patch since the cifs vfs is
|
22 |
|
|
already in the kernel configure menu) and then
|
23 |
|
|
mkdir linux/fs/cifs and then copy the current cifs vfs files from
|
24 |
|
|
the cifs download to your kernel build directory e.g.
|
25 |
|
|
|
26 |
|
|
cp /fs/cifs/* to /fs/cifs
|
27 |
|
|
|
28 |
|
|
2) make menuconfig (or make xconfig)
|
29 |
|
|
3) select cifs from within the network filesystem choices
|
30 |
|
|
4) save and exit
|
31 |
|
|
5) make dep
|
32 |
|
|
6) make modules (or "make" if CIFS VFS not to be built as a module)
|
33 |
|
|
|
34 |
|
|
For Linux 2.6:
|
35 |
|
|
1) Download the kernel (e.g. from http://www.kernel.org)
|
36 |
|
|
and change directory into the top of the kernel directory tree
|
37 |
|
|
(e.g. /usr/src/linux-2.5.73)
|
38 |
|
|
2) make menuconfig (or make xconfig)
|
39 |
|
|
3) select cifs from within the network filesystem choices
|
40 |
|
|
4) save and exit
|
41 |
|
|
5) make
|
42 |
|
|
|
43 |
|
|
|
44 |
|
|
Installation instructions:
|
45 |
|
|
=========================
|
46 |
|
|
If you have built the CIFS vfs as module (successfully) simply
|
47 |
|
|
type "make modules_install" (or if you prefer, manually copy the file to
|
48 |
|
|
the modules directory e.g. /lib/modules/2.4.10-4GB/kernel/fs/cifs/cifs.o).
|
49 |
|
|
|
50 |
|
|
If you have built the CIFS vfs into the kernel itself, follow the instructions
|
51 |
|
|
for your distribution on how to install a new kernel (usually you
|
52 |
|
|
would simply type "make install").
|
53 |
|
|
|
54 |
|
|
If you do not have the utility mount.cifs (in the Samba 3.0 source tree and on
|
55 |
|
|
the CIFS VFS web site) copy it to the same directory in which mount.smbfs and
|
56 |
|
|
similar files reside (usually /sbin). Although the helper software is not
|
57 |
|
|
required, mount.cifs is recommended. Eventually the Samba 3.0 utility program
|
58 |
|
|
"net" may also be helpful since it may someday provide easier mount syntax for
|
59 |
|
|
users who are used to Windows e.g. net use
|
60 |
|
|
Note that running the Winbind pam/nss module (logon service) on all of your
|
61 |
|
|
Linux clients is useful in mapping Uids and Gids consistently across the
|
62 |
|
|
domain to the proper network user. The mount.cifs mount helper can be
|
63 |
|
|
trivially built from Samba 3.0 or later source e.g. by executing:
|
64 |
|
|
|
65 |
|
|
gcc samba/source/client/mount.cifs.c -o mount.cifs
|
66 |
|
|
|
67 |
|
|
If cifs is built as a module, then the size and number of network buffers
|
68 |
|
|
and maximum number of simultaneous requests to one server can be configured.
|
69 |
|
|
Changing these from their defaults is not recommended. By executing modinfo
|
70 |
|
|
modinfo kernel/fs/cifs/cifs.ko
|
71 |
|
|
on kernel/fs/cifs/cifs.ko the list of configuration changes that can be made
|
72 |
|
|
at module initialization time (by running insmod cifs.ko) can be seen.
|
73 |
|
|
|
74 |
|
|
Allowing User Mounts
|
75 |
|
|
====================
|
76 |
|
|
To permit users to mount and unmount over directories they own is possible
|
77 |
|
|
with the cifs vfs. A way to enable such mounting is to mark the mount.cifs
|
78 |
|
|
utility as suid (e.g. "chmod +s /sbin/mount.cifs). To enable users to
|
79 |
|
|
umount shares they mount requires
|
80 |
|
|
1) mount.cifs version 1.4 or later
|
81 |
|
|
2) an entry for the share in /etc/fstab indicating that a user may
|
82 |
|
|
unmount it e.g.
|
83 |
|
|
//server/usersharename /mnt/username cifs user 0 0
|
84 |
|
|
|
85 |
|
|
Note that when the mount.cifs utility is run suid (allowing user mounts),
|
86 |
|
|
in order to reduce risks, the "nosuid" mount flag is passed in on mount to
|
87 |
|
|
disallow execution of an suid program mounted on the remote target.
|
88 |
|
|
When mount is executed as root, nosuid is not passed in by default,
|
89 |
|
|
and execution of suid programs on the remote target would be enabled
|
90 |
|
|
by default. This can be changed, as with nfs and other filesystems,
|
91 |
|
|
by simply specifying "nosuid" among the mount options. For user mounts
|
92 |
|
|
though to be able to pass the suid flag to mount requires rebuilding
|
93 |
|
|
mount.cifs with the following flag:
|
94 |
|
|
|
95 |
|
|
gcc samba/source/client/mount.cifs.c -DCIFS_ALLOW_USR_SUID -o mount.cifs
|
96 |
|
|
|
97 |
|
|
There is a corresponding manual page for cifs mounting in the Samba 3.0 and
|
98 |
|
|
later source tree in docs/manpages/mount.cifs.8
|
99 |
|
|
|
100 |
|
|
Allowing User Unmounts
|
101 |
|
|
======================
|
102 |
|
|
To permit users to ummount directories that they have user mounted (see above),
|
103 |
|
|
the utility umount.cifs may be used. It may be invoked directly, or if
|
104 |
|
|
umount.cifs is placed in /sbin, umount can invoke the cifs umount helper
|
105 |
|
|
(at least for most versions of the umount utility) for umount of cifs
|
106 |
|
|
mounts, unless umount is invoked with -i (which will avoid invoking a umount
|
107 |
|
|
helper). As with mount.cifs, to enable user unmounts umount.cifs must be marked
|
108 |
|
|
as suid (e.g. "chmod +s /sbin/umount.cifs") or equivalent (some distributions
|
109 |
|
|
allow adding entries to a file to the /etc/permissions file to achieve the
|
110 |
|
|
equivalent suid effect). For this utility to succeed the target path
|
111 |
|
|
must be a cifs mount, and the uid of the current user must match the uid
|
112 |
|
|
of the user who mounted the resource.
|
113 |
|
|
|
114 |
|
|
Also note that the customary way of allowing user mounts and unmounts is
|
115 |
|
|
(instead of using mount.cifs and unmount.cifs as suid) to add a line
|
116 |
|
|
to the file /etc/fstab for each //server/share you wish to mount, but
|
117 |
|
|
this can become unwieldy when potential mount targets include many
|
118 |
|
|
or unpredictable UNC names.
|
119 |
|
|
|
120 |
|
|
Samba Considerations
|
121 |
|
|
====================
|
122 |
|
|
To get the maximum benefit from the CIFS VFS, we recommend using a server that
|
123 |
|
|
supports the SNIA CIFS Unix Extensions standard (e.g. Samba 2.2.5 or later or
|
124 |
|
|
Samba 3.0) but the CIFS vfs works fine with a wide variety of CIFS servers.
|
125 |
|
|
Note that uid, gid and file permissions will display default values if you do
|
126 |
|
|
not have a server that supports the Unix extensions for CIFS (such as Samba
|
127 |
|
|
2.2.5 or later). To enable the Unix CIFS Extensions in the Samba server, add
|
128 |
|
|
the line:
|
129 |
|
|
|
130 |
|
|
unix extensions = yes
|
131 |
|
|
|
132 |
|
|
to your smb.conf file on the server. Note that the following smb.conf settings
|
133 |
|
|
are also useful (on the Samba server) when the majority of clients are Unix or
|
134 |
|
|
Linux:
|
135 |
|
|
|
136 |
|
|
case sensitive = yes
|
137 |
|
|
delete readonly = yes
|
138 |
|
|
ea support = yes
|
139 |
|
|
|
140 |
|
|
Note that server ea support is required for supporting xattrs from the Linux
|
141 |
|
|
cifs client, and that EA support is present in later versions of Samba (e.g.
|
142 |
|
|
3.0.6 and later (also EA support works in all versions of Windows, at least to
|
143 |
|
|
shares on NTFS filesystems). Extended Attribute (xattr) support is an optional
|
144 |
|
|
feature of most Linux filesystems which may require enabling via
|
145 |
|
|
make menuconfig. Client support for extended attributes (user xattr) can be
|
146 |
|
|
disabled on a per-mount basis by specifying "nouser_xattr" on mount.
|
147 |
|
|
|
148 |
|
|
The CIFS client can get and set POSIX ACLs (getfacl, setfacl) to Samba servers
|
149 |
|
|
version 3.10 and later. Setting POSIX ACLs requires enabling both XATTR and
|
150 |
|
|
then POSIX support in the CIFS configuration options when building the cifs
|
151 |
|
|
module. POSIX ACL support can be disabled on a per mount basic by specifying
|
152 |
|
|
"noacl" on mount.
|
153 |
|
|
|
154 |
|
|
Some administrators may want to change Samba's smb.conf "map archive" and
|
155 |
|
|
"create mask" parameters from the default. Unless the create mask is changed
|
156 |
|
|
newly created files can end up with an unnecessarily restrictive default mode,
|
157 |
|
|
which may not be what you want, although if the CIFS Unix extensions are
|
158 |
|
|
enabled on the server and client, subsequent setattr calls (e.g. chmod) can
|
159 |
|
|
fix the mode. Note that creating special devices (mknod) remotely
|
160 |
|
|
may require specifying a mkdev function to Samba if you are not using
|
161 |
|
|
Samba 3.0.6 or later. For more information on these see the manual pages
|
162 |
|
|
("man smb.conf") on the Samba server system. Note that the cifs vfs,
|
163 |
|
|
unlike the smbfs vfs, does not read the smb.conf on the client system
|
164 |
|
|
(the few optional settings are passed in on mount via -o parameters instead).
|
165 |
|
|
Note that Samba 2.2.7 or later includes a fix that allows the CIFS VFS to delete
|
166 |
|
|
open files (required for strict POSIX compliance). Windows Servers already
|
167 |
|
|
supported this feature. Samba server does not allow symlinks that refer to files
|
168 |
|
|
outside of the share, so in Samba versions prior to 3.0.6, most symlinks to
|
169 |
|
|
files with absolute paths (ie beginning with slash) such as:
|
170 |
|
|
ln -s /mnt/foo bar
|
171 |
|
|
would be forbidden. Samba 3.0.6 server or later includes the ability to create
|
172 |
|
|
such symlinks safely by converting unsafe symlinks (ie symlinks to server
|
173 |
|
|
files that are outside of the share) to a samba specific format on the server
|
174 |
|
|
that is ignored by local server applications and non-cifs clients and that will
|
175 |
|
|
not be traversed by the Samba server). This is opaque to the Linux client
|
176 |
|
|
application using the cifs vfs. Absolute symlinks will work to Samba 3.0.5 or
|
177 |
|
|
later, but only for remote clients using the CIFS Unix extensions, and will
|
178 |
|
|
be invisbile to Windows clients and typically will not affect local
|
179 |
|
|
applications running on the same server as Samba.
|
180 |
|
|
|
181 |
|
|
Use instructions:
|
182 |
|
|
================
|
183 |
|
|
Once the CIFS VFS support is built into the kernel or installed as a module
|
184 |
|
|
(cifs.o), you can use mount syntax like the following to access Samba or Windows
|
185 |
|
|
servers:
|
186 |
|
|
|
187 |
|
|
mount -t cifs //9.53.216.11/e$ /mnt -o user=myname,pass=mypassword
|
188 |
|
|
|
189 |
|
|
Before -o the option -v may be specified to make the mount.cifs
|
190 |
|
|
mount helper display the mount steps more verbosely.
|
191 |
|
|
After -o the following commonly used cifs vfs specific options
|
192 |
|
|
are supported:
|
193 |
|
|
|
194 |
|
|
user=
|
195 |
|
|
pass=
|
196 |
|
|
domain=
|
197 |
|
|
|
198 |
|
|
Other cifs mount options are described below. Use of TCP names (in addition to
|
199 |
|
|
ip addresses) is available if the mount helper (mount.cifs) is installed. If
|
200 |
|
|
you do not trust the server to which are mounted, or if you do not have
|
201 |
|
|
cifs signing enabled (and the physical network is insecure), consider use
|
202 |
|
|
of the standard mount options "noexec" and "nosuid" to reduce the risk of
|
203 |
|
|
running an altered binary on your local system (downloaded from a hostile server
|
204 |
|
|
or altered by a hostile router).
|
205 |
|
|
|
206 |
|
|
Although mounting using format corresponding to the CIFS URL specification is
|
207 |
|
|
not possible in mount.cifs yet, it is possible to use an alternate format
|
208 |
|
|
for the server and sharename (which is somewhat similar to NFS style mount
|
209 |
|
|
syntax) instead of the more widely used UNC format (i.e. \\server\share):
|
210 |
|
|
mount -t cifs tcp_name_of_server:share_name /mnt -o user=myname,pass=mypasswd
|
211 |
|
|
|
212 |
|
|
When using the mount helper mount.cifs, passwords may be specified via alternate
|
213 |
|
|
mechanisms, instead of specifying it after -o using the normal "pass=" syntax
|
214 |
|
|
on the command line:
|
215 |
|
|
1) By including it in a credential file. Specify credentials=filename as one
|
216 |
|
|
of the mount options. Credential files contain two lines
|
217 |
|
|
username=someuser
|
218 |
|
|
password=your_password
|
219 |
|
|
2) By specifying the password in the PASSWD environment variable (similarly
|
220 |
|
|
the user name can be taken from the USER environment variable).
|
221 |
|
|
3) By specifying the password in a file by name via PASSWD_FILE
|
222 |
|
|
4) By specifying the password in a file by file descriptor via PASSWD_FD
|
223 |
|
|
|
224 |
|
|
If no password is provided, mount.cifs will prompt for password entry
|
225 |
|
|
|
226 |
|
|
Restrictions
|
227 |
|
|
============
|
228 |
|
|
Servers must support either "pure-TCP" (port 445 TCP/IP CIFS connections) or RFC
|
229 |
|
|
1001/1002 support for "Netbios-Over-TCP/IP." This is not likely to be a
|
230 |
|
|
problem as most servers support this.
|
231 |
|
|
|
232 |
|
|
Valid filenames differ between Windows and Linux. Windows typically restricts
|
233 |
|
|
filenames which contain certain reserved characters (e.g.the character :
|
234 |
|
|
which is used to delimit the beginning of a stream name by Windows), while
|
235 |
|
|
Linux allows a slightly wider set of valid characters in filenames. Windows
|
236 |
|
|
servers can remap such characters when an explicit mapping is specified in
|
237 |
|
|
the Server's registry. Samba starting with version 3.10 will allow such
|
238 |
|
|
filenames (ie those which contain valid Linux characters, which normally
|
239 |
|
|
would be forbidden for Windows/CIFS semantics) as long as the server is
|
240 |
|
|
configured for Unix Extensions (and the client has not disabled
|
241 |
|
|
/proc/fs/cifs/LinuxExtensionsEnabled).
|
242 |
|
|
|
243 |
|
|
|
244 |
|
|
CIFS VFS Mount Options
|
245 |
|
|
======================
|
246 |
|
|
A partial list of the supported mount options follows:
|
247 |
|
|
user The user name to use when trying to establish
|
248 |
|
|
the CIFS session.
|
249 |
|
|
password The user password. If the mount helper is
|
250 |
|
|
installed, the user will be prompted for password
|
251 |
|
|
if it is not supplied.
|
252 |
|
|
ip The ip address of the target server
|
253 |
|
|
unc The target server Universal Network Name (export) to
|
254 |
|
|
mount.
|
255 |
|
|
domain Set the SMB/CIFS workgroup name prepended to the
|
256 |
|
|
username during CIFS session establishment
|
257 |
|
|
uid Set the default uid for inodes. For mounts to servers
|
258 |
|
|
which do support the CIFS Unix extensions, such as a
|
259 |
|
|
properly configured Samba server, the server provides
|
260 |
|
|
the uid, gid and mode so this parameter should not be
|
261 |
|
|
specified unless the server and clients uid and gid
|
262 |
|
|
numbering differ. If the server and client are in the
|
263 |
|
|
same domain (e.g. running winbind or nss_ldap) and
|
264 |
|
|
the server supports the Unix Extensions then the uid
|
265 |
|
|
and gid can be retrieved from the server (and uid
|
266 |
|
|
and gid would not have to be specifed on the mount.
|
267 |
|
|
For servers which do not support the CIFS Unix
|
268 |
|
|
extensions, the default uid (and gid) returned on lookup
|
269 |
|
|
of existing files will be the uid (gid) of the person
|
270 |
|
|
who executed the mount (root, except when mount.cifs
|
271 |
|
|
is configured setuid for user mounts) unless the "uid="
|
272 |
|
|
(gid) mount option is specified. For the uid (gid) of newly
|
273 |
|
|
created files and directories, ie files created since
|
274 |
|
|
the last mount of the server share, the expected uid
|
275 |
|
|
(gid) is cached as long as the inode remains in
|
276 |
|
|
memory on the client. Also note that permission
|
277 |
|
|
checks (authorization checks) on accesses to a file occur
|
278 |
|
|
at the server, but there are cases in which an administrator
|
279 |
|
|
may want to restrict at the client as well. For those
|
280 |
|
|
servers which do not report a uid/gid owner
|
281 |
|
|
(such as Windows), permissions can also be checked at the
|
282 |
|
|
client, and a crude form of client side permission checking
|
283 |
|
|
can be enabled by specifying file_mode and dir_mode on
|
284 |
|
|
the client. Note that the mount.cifs helper must be
|
285 |
|
|
at version 1.10 or higher to support specifying the uid
|
286 |
|
|
(or gid) in non-numberic form.
|
287 |
|
|
gid Set the default gid for inodes (similar to above).
|
288 |
|
|
file_mode If CIFS Unix extensions are not supported by the server
|
289 |
|
|
this overrides the default mode for file inodes.
|
290 |
|
|
dir_mode If CIFS Unix extensions are not supported by the server
|
291 |
|
|
this overrides the default mode for directory inodes.
|
292 |
|
|
port attempt to contact the server on this tcp port, before
|
293 |
|
|
trying the usual ports (port 445, then 139).
|
294 |
|
|
iocharset Codepage used to convert local path names to and from
|
295 |
|
|
Unicode. Unicode is used by default for network path
|
296 |
|
|
names if the server supports it. If iocharset is
|
297 |
|
|
not specified then the nls_default specified
|
298 |
|
|
during the local client kernel build will be used.
|
299 |
|
|
If server does not support Unicode, this parameter is
|
300 |
|
|
unused.
|
301 |
|
|
rsize default read size (usually 16K). The client currently
|
302 |
|
|
can not use rsize larger than CIFSMaxBufSize. CIFSMaxBufSize
|
303 |
|
|
defaults to 16K and may be changed (from 8K to the maximum
|
304 |
|
|
kmalloc size allowed by your kernel) at module install time
|
305 |
|
|
for cifs.ko. Setting CIFSMaxBufSize to a very large value
|
306 |
|
|
will cause cifs to use more memory and may reduce performance
|
307 |
|
|
in some cases. To use rsize greater than 127K (the original
|
308 |
|
|
cifs protocol maximum) also requires that the server support
|
309 |
|
|
a new Unix Capability flag (for very large read) which some
|
310 |
|
|
newer servers (e.g. Samba 3.0.26 or later) do. rsize can be
|
311 |
|
|
set from a minimum of 2048 to a maximum of 130048 (127K or
|
312 |
|
|
CIFSMaxBufSize, whichever is smaller)
|
313 |
|
|
wsize default write size (default 57344)
|
314 |
|
|
maximum wsize currently allowed by CIFS is 57344 (fourteen
|
315 |
|
|
4096 byte pages)
|
316 |
|
|
rw mount the network share read-write (note that the
|
317 |
|
|
server may still consider the share read-only)
|
318 |
|
|
ro mount network share read-only
|
319 |
|
|
version used to distinguish different versions of the
|
320 |
|
|
mount helper utility (not typically needed)
|
321 |
|
|
sep if first mount option (after the -o), overrides
|
322 |
|
|
the comma as the separator between the mount
|
323 |
|
|
parms. e.g.
|
324 |
|
|
-o user=myname,password=mypassword,domain=mydom
|
325 |
|
|
could be passed instead with period as the separator by
|
326 |
|
|
-o sep=.user=myname.password=mypassword.domain=mydom
|
327 |
|
|
this might be useful when comma is contained within username
|
328 |
|
|
or password or domain. This option is less important
|
329 |
|
|
when the cifs mount helper cifs.mount (version 1.1 or later)
|
330 |
|
|
is used.
|
331 |
|
|
nosuid Do not allow remote executables with the suid bit
|
332 |
|
|
program to be executed. This is only meaningful for mounts
|
333 |
|
|
to servers such as Samba which support the CIFS Unix Extensions.
|
334 |
|
|
If you do not trust the servers in your network (your mount
|
335 |
|
|
targets) it is recommended that you specify this option for
|
336 |
|
|
greater security.
|
337 |
|
|
exec Permit execution of binaries on the mount.
|
338 |
|
|
noexec Do not permit execution of binaries on the mount.
|
339 |
|
|
dev Recognize block devices on the remote mount.
|
340 |
|
|
nodev Do not recognize devices on the remote mount.
|
341 |
|
|
suid Allow remote files on this mountpoint with suid enabled to
|
342 |
|
|
be executed (default for mounts when executed as root,
|
343 |
|
|
nosuid is default for user mounts).
|
344 |
|
|
credentials Although ignored by the cifs kernel component, it is used by
|
345 |
|
|
the mount helper, mount.cifs. When mount.cifs is installed it
|
346 |
|
|
opens and reads the credential file specified in order
|
347 |
|
|
to obtain the userid and password arguments which are passed to
|
348 |
|
|
the cifs vfs.
|
349 |
|
|
guest Although ignored by the kernel component, the mount.cifs
|
350 |
|
|
mount helper will not prompt the user for a password
|
351 |
|
|
if guest is specified on the mount options. If no
|
352 |
|
|
password is specified a null password will be used.
|
353 |
|
|
perm Client does permission checks (vfs_permission check of uid
|
354 |
|
|
and gid of the file against the mode and desired operation),
|
355 |
|
|
Note that this is in addition to the normal ACL check on the
|
356 |
|
|
target machine done by the server software.
|
357 |
|
|
Client permission checking is enabled by default.
|
358 |
|
|
noperm Client does not do permission checks. This can expose
|
359 |
|
|
files on this mount to access by other users on the local
|
360 |
|
|
client system. It is typically only needed when the server
|
361 |
|
|
supports the CIFS Unix Extensions but the UIDs/GIDs on the
|
362 |
|
|
client and server system do not match closely enough to allow
|
363 |
|
|
access by the user doing the mount, but it may be useful with
|
364 |
|
|
non CIFS Unix Extension mounts for cases in which the default
|
365 |
|
|
mode is specified on the mount but is not to be enforced on the
|
366 |
|
|
client (e.g. perhaps when MultiUserMount is enabled)
|
367 |
|
|
Note that this does not affect the normal ACL check on the
|
368 |
|
|
target machine done by the server software (of the server
|
369 |
|
|
ACL against the user name provided at mount time).
|
370 |
|
|
serverino Use server's inode numbers instead of generating automatically
|
371 |
|
|
incrementing inode numbers on the client. Although this will
|
372 |
|
|
make it easier to spot hardlinked files (as they will have
|
373 |
|
|
the same inode numbers) and inode numbers may be persistent,
|
374 |
|
|
note that the server does not guarantee that the inode numbers
|
375 |
|
|
are unique if multiple server side mounts are exported under a
|
376 |
|
|
single share (since inode numbers on the servers might not
|
377 |
|
|
be unique if multiple filesystems are mounted under the same
|
378 |
|
|
shared higher level directory). Note that some older
|
379 |
|
|
(e.g. pre-Windows 2000) do not support returning UniqueIDs
|
380 |
|
|
or the CIFS Unix Extensions equivalent and for those
|
381 |
|
|
this mount option will have no effect. Exporting cifs mounts
|
382 |
|
|
under nfsd requires this mount option on the cifs mount.
|
383 |
|
|
noserverino Client generates inode numbers (rather than using the actual one
|
384 |
|
|
from the server) by default.
|
385 |
|
|
setuids If the CIFS Unix extensions are negotiated with the server
|
386 |
|
|
the client will attempt to set the effective uid and gid of
|
387 |
|
|
the local process on newly created files, directories, and
|
388 |
|
|
devices (create, mkdir, mknod). If the CIFS Unix Extensions
|
389 |
|
|
are not negotiated, for newly created files and directories
|
390 |
|
|
instead of using the default uid and gid specified on
|
391 |
|
|
the mount, cache the new file's uid and gid locally which means
|
392 |
|
|
that the uid for the file can change when the inode is
|
393 |
|
|
reloaded (or the user remounts the share).
|
394 |
|
|
nosetuids The client will not attempt to set the uid and gid on
|
395 |
|
|
on newly created files, directories, and devices (create,
|
396 |
|
|
mkdir, mknod) which will result in the server setting the
|
397 |
|
|
uid and gid to the default (usually the server uid of the
|
398 |
|
|
user who mounted the share). Letting the server (rather than
|
399 |
|
|
the client) set the uid and gid is the default. If the CIFS
|
400 |
|
|
Unix Extensions are not negotiated then the uid and gid for
|
401 |
|
|
new files will appear to be the uid (gid) of the mounter or the
|
402 |
|
|
uid (gid) parameter specified on the mount.
|
403 |
|
|
netbiosname When mounting to servers via port 139, specifies the RFC1001
|
404 |
|
|
source name to use to represent the client netbios machine
|
405 |
|
|
name when doing the RFC1001 netbios session initialize.
|
406 |
|
|
direct Do not do inode data caching on files opened on this mount.
|
407 |
|
|
This precludes mmaping files on this mount. In some cases
|
408 |
|
|
with fast networks and little or no caching benefits on the
|
409 |
|
|
client (e.g. when the application is doing large sequential
|
410 |
|
|
reads bigger than page size without rereading the same data)
|
411 |
|
|
this can provide better performance than the default
|
412 |
|
|
behavior which caches reads (readahead) and writes
|
413 |
|
|
(writebehind) through the local Linux client pagecache
|
414 |
|
|
if oplock (caching token) is granted and held. Note that
|
415 |
|
|
direct allows write operations larger than page size
|
416 |
|
|
to be sent to the server.
|
417 |
|
|
acl Allow setfacl and getfacl to manage posix ACLs if server
|
418 |
|
|
supports them. (default)
|
419 |
|
|
noacl Do not allow setfacl and getfacl calls on this mount
|
420 |
|
|
user_xattr Allow getting and setting user xattrs as OS/2 EAs (extended
|
421 |
|
|
attributes) to the server (default) e.g. via setfattr
|
422 |
|
|
and getfattr utilities.
|
423 |
|
|
nouser_xattr Do not allow getfattr/setfattr to get/set/list xattrs
|
424 |
|
|
mapchars Translate six of the seven reserved characters (not backslash)
|
425 |
|
|
*?<>|:
|
426 |
|
|
to the remap range (above 0xF000), which also
|
427 |
|
|
allows the CIFS client to recognize files created with
|
428 |
|
|
such characters by Windows's POSIX emulation. This can
|
429 |
|
|
also be useful when mounting to most versions of Samba
|
430 |
|
|
(which also forbids creating and opening files
|
431 |
|
|
whose names contain any of these seven characters).
|
432 |
|
|
This has no effect if the server does not support
|
433 |
|
|
Unicode on the wire.
|
434 |
|
|
nomapchars Do not translate any of these seven characters (default).
|
435 |
|
|
nocase Request case insensitive path name matching (case
|
436 |
|
|
sensitive is the default if the server suports it).
|
437 |
|
|
posixpaths If CIFS Unix extensions are supported, attempt to
|
438 |
|
|
negotiate posix path name support which allows certain
|
439 |
|
|
characters forbidden in typical CIFS filenames, without
|
440 |
|
|
requiring remapping. (default)
|
441 |
|
|
noposixpaths If CIFS Unix extensions are supported, do not request
|
442 |
|
|
posix path name support (this may cause servers to
|
443 |
|
|
reject creatingfile with certain reserved characters).
|
444 |
|
|
nounix Disable the CIFS Unix Extensions for this mount (tree
|
445 |
|
|
connection). This is rarely needed, but it may be useful
|
446 |
|
|
in order to turn off multiple settings all at once (ie
|
447 |
|
|
posix acls, posix locks, posix paths, symlink support
|
448 |
|
|
and retrieving uids/gids/mode from the server) or to
|
449 |
|
|
work around a bug in server which implement the Unix
|
450 |
|
|
Extensions.
|
451 |
|
|
nobrl Do not send byte range lock requests to the server.
|
452 |
|
|
This is necessary for certain applications that break
|
453 |
|
|
with cifs style mandatory byte range locks (and most
|
454 |
|
|
cifs servers do not yet support requesting advisory
|
455 |
|
|
byte range locks).
|
456 |
|
|
remount remount the share (often used to change from ro to rw mounts
|
457 |
|
|
or vice versa)
|
458 |
|
|
cifsacl Report mode bits (e.g. on stat) based on the Windows ACL for
|
459 |
|
|
the file. (EXPERIMENTAL)
|
460 |
|
|
servern Specify the server 's netbios name (RFC1001 name) to use
|
461 |
|
|
when attempting to setup a session to the server. This is
|
462 |
|
|
This is needed for mounting to some older servers (such
|
463 |
|
|
as OS/2 or Windows 98 and Windows ME) since they do not
|
464 |
|
|
support a default server name. A server name can be up
|
465 |
|
|
to 15 characters long and is usually uppercased.
|
466 |
|
|
sfu When the CIFS Unix Extensions are not negotiated, attempt to
|
467 |
|
|
create device files and fifos in a format compatible with
|
468 |
|
|
Services for Unix (SFU). In addition retrieve bits 10-12
|
469 |
|
|
of the mode via the SETFILEBITS extended attribute (as
|
470 |
|
|
SFU does). In the future the bottom 9 bits of the
|
471 |
|
|
mode also will be emulated using queries of the security
|
472 |
|
|
descriptor (ACL).
|
473 |
|
|
sign Must use packet signing (helps avoid unwanted data modification
|
474 |
|
|
by intermediate systems in the route). Note that signing
|
475 |
|
|
does not work with lanman or plaintext authentication.
|
476 |
|
|
sec Security mode. Allowed values are:
|
477 |
|
|
none attempt to connection as a null user (no name)
|
478 |
|
|
krb5 Use Kerberos version 5 authentication
|
479 |
|
|
krb5i Use Kerberos authentication and packet signing
|
480 |
|
|
ntlm Use NTLM password hashing (default)
|
481 |
|
|
ntlmi Use NTLM password hashing with signing (if
|
482 |
|
|
/proc/fs/cifs/PacketSigningEnabled on or if
|
483 |
|
|
server requires signing also can be the default)
|
484 |
|
|
ntlmv2 Use NTLMv2 password hashing
|
485 |
|
|
ntlmv2i Use NTLMv2 password hashing with packet signing
|
486 |
|
|
lanman (if configured in kernel config) use older
|
487 |
|
|
lanman hash
|
488 |
|
|
|
489 |
|
|
The mount.cifs mount helper also accepts a few mount options before -o
|
490 |
|
|
including:
|
491 |
|
|
|
492 |
|
|
-S take password from stdin (equivalent to setting the environment
|
493 |
|
|
variable "PASSWD_FD=0"
|
494 |
|
|
-V print mount.cifs version
|
495 |
|
|
-? display simple usage information
|
496 |
|
|
|
497 |
|
|
With most 2.6 kernel versions of modutils, the version of the cifs kernel
|
498 |
|
|
module can be displayed via modinfo.
|
499 |
|
|
|
500 |
|
|
Misc /proc/fs/cifs Flags and Debug Info
|
501 |
|
|
=======================================
|
502 |
|
|
Informational pseudo-files:
|
503 |
|
|
DebugData Displays information about active CIFS sessions
|
504 |
|
|
and shares, as well as the cifs.ko version.
|
505 |
|
|
Stats Lists summary resource usage information as well as per
|
506 |
|
|
share statistics, if CONFIG_CIFS_STATS in enabled
|
507 |
|
|
in the kernel configuration.
|
508 |
|
|
|
509 |
|
|
Configuration pseudo-files:
|
510 |
|
|
MultiuserMount If set to one, more than one CIFS session to
|
511 |
|
|
the same server ip address can be established
|
512 |
|
|
if more than one uid accesses the same mount
|
513 |
|
|
point and if the uids user/password mapping
|
514 |
|
|
information is available. (default is 0)
|
515 |
|
|
PacketSigningEnabled If set to one, cifs packet signing is enabled
|
516 |
|
|
and will be used if the server requires
|
517 |
|
|
it. If set to two, cifs packet signing is
|
518 |
|
|
required even if the server considers packet
|
519 |
|
|
signing optional. (default 1)
|
520 |
|
|
SecurityFlags Flags which control security negotiation and
|
521 |
|
|
also packet signing. Authentication (may/must)
|
522 |
|
|
flags (e.g. for NTLM and/or NTLMv2) may be combined with
|
523 |
|
|
the signing flags. Specifying two different password
|
524 |
|
|
hashing mechanisms (as "must use") on the other hand
|
525 |
|
|
does not make much sense. Default flags are
|
526 |
|
|
0x07007
|
527 |
|
|
(NTLM, NTLMv2 and packet signing allowed). Maximum
|
528 |
|
|
allowable flags if you want to allow mounts to servers
|
529 |
|
|
using weaker password hashes is 0x37037 (lanman,
|
530 |
|
|
plaintext, ntlm, ntlmv2, signing allowed):
|
531 |
|
|
|
532 |
|
|
may use packet signing 0x00001
|
533 |
|
|
must use packet signing 0x01001
|
534 |
|
|
may use NTLM (most common password hash) 0x00002
|
535 |
|
|
must use NTLM 0x02002
|
536 |
|
|
may use NTLMv2 0x00004
|
537 |
|
|
must use NTLMv2 0x04004
|
538 |
|
|
may use Kerberos security (not implemented yet) 0x00008
|
539 |
|
|
must use Kerberos (not implemented yet) 0x08008
|
540 |
|
|
may use lanman (weak) password hash 0x00010
|
541 |
|
|
must use lanman password hash 0x10010
|
542 |
|
|
may use plaintext passwords 0x00020
|
543 |
|
|
must use plaintext passwords 0x20020
|
544 |
|
|
(reserved for future packet encryption) 0x00040
|
545 |
|
|
|
546 |
|
|
cifsFYI If set to non-zero value, additional debug information
|
547 |
|
|
will be logged to the system error log. This field
|
548 |
|
|
contains three flags controlling different classes of
|
549 |
|
|
debugging entries. The maximum value it can be set
|
550 |
|
|
to is 7 which enables all debugging points (default 0).
|
551 |
|
|
Some debugging statements are not compiled into the
|
552 |
|
|
cifs kernel unless CONFIG_CIFS_DEBUG2 is enabled in the
|
553 |
|
|
kernel configuration. cifsFYI may be set to one or
|
554 |
|
|
nore of the following flags (7 sets them all):
|
555 |
|
|
|
556 |
|
|
log cifs informational messages 0x01
|
557 |
|
|
log return codes from cifs entry points 0x02
|
558 |
|
|
log slow responses (ie which take longer than 1 second)
|
559 |
|
|
CONFIG_CIFS_STATS2 must be enabled in .config 0x04
|
560 |
|
|
|
561 |
|
|
|
562 |
|
|
traceSMB If set to one, debug information is logged to the
|
563 |
|
|
system error log with the start of smb requests
|
564 |
|
|
and responses (default 0)
|
565 |
|
|
LookupCacheEnable If set to one, inode information is kept cached
|
566 |
|
|
for one second improving performance of lookups
|
567 |
|
|
(default 1)
|
568 |
|
|
OplockEnabled If set to one, safe distributed caching enabled.
|
569 |
|
|
(default 1)
|
570 |
|
|
LinuxExtensionsEnabled If set to one then the client will attempt to
|
571 |
|
|
use the CIFS "UNIX" extensions which are optional
|
572 |
|
|
protocol enhancements that allow CIFS servers
|
573 |
|
|
to return accurate UID/GID information as well
|
574 |
|
|
as support symbolic links. If you use servers
|
575 |
|
|
such as Samba that support the CIFS Unix
|
576 |
|
|
extensions but do not want to use symbolic link
|
577 |
|
|
support and want to map the uid and gid fields
|
578 |
|
|
to values supplied at mount (rather than the
|
579 |
|
|
actual values, then set this to zero. (default 1)
|
580 |
|
|
Experimental When set to 1 used to enable certain experimental
|
581 |
|
|
features (currently enables multipage writes
|
582 |
|
|
when signing is enabled, the multipage write
|
583 |
|
|
performance enhancement was disabled when
|
584 |
|
|
signing turned on in case buffer was modified
|
585 |
|
|
just before it was sent, also this flag will
|
586 |
|
|
be used to use the new experimental directory change
|
587 |
|
|
notification code).
|
588 |
|
|
|
589 |
|
|
These experimental features and tracing can be enabled by changing flags in
|
590 |
|
|
/proc/fs/cifs (after the cifs module has been installed or built into the
|
591 |
|
|
kernel, e.g. insmod cifs). To enable a feature set it to 1 e.g. to enable
|
592 |
|
|
tracing to the kernel message log type:
|
593 |
|
|
|
594 |
|
|
echo 7 > /proc/fs/cifs/cifsFYI
|
595 |
|
|
|
596 |
|
|
cifsFYI functions as a bit mask. Setting it to 1 enables additional kernel
|
597 |
|
|
logging of various informational messages. 2 enables logging of non-zero
|
598 |
|
|
SMB return codes while 4 enables logging of requests that take longer
|
599 |
|
|
than one second to complete (except for byte range lock requests).
|
600 |
|
|
Setting it to 4 requires defining CONFIG_CIFS_STATS2 manually in the
|
601 |
|
|
source code (typically by setting it in the beginning of cifsglob.h),
|
602 |
|
|
and setting it to seven enables all three. Finally, tracing
|
603 |
|
|
the start of smb requests and responses can be enabled via:
|
604 |
|
|
|
605 |
|
|
echo 1 > /proc/fs/cifs/traceSMB
|
606 |
|
|
|
607 |
|
|
Two other experimental features are under development. To test these
|
608 |
|
|
requires enabling CONFIG_CIFS_EXPERIMENTAL
|
609 |
|
|
|
610 |
|
|
cifsacl support needed to retrieve approximated mode bits based on
|
611 |
|
|
the contents on the CIFS ACL.
|
612 |
|
|
|
613 |
|
|
DNOTIFY fcntl: needed for support of directory change
|
614 |
|
|
notification and perhaps later for file leases)
|
615 |
|
|
|
616 |
|
|
Per share (per client mount) statistics are available in /proc/fs/cifs/Stats
|
617 |
|
|
if the kernel was configured with cifs statistics enabled. The statistics
|
618 |
|
|
represent the number of successful (ie non-zero return code from the server)
|
619 |
|
|
SMB responses to some of the more common commands (open, delete, mkdir etc.).
|
620 |
|
|
Also recorded is the total bytes read and bytes written to the server for
|
621 |
|
|
that share. Note that due to client caching effects this can be less than the
|
622 |
|
|
number of bytes read and written by the application running on the client.
|
623 |
|
|
The statistics for the number of total SMBs and oplock breaks are different in
|
624 |
|
|
that they represent all for that share, not just those for which the server
|
625 |
|
|
returned success.
|
626 |
|
|
|
627 |
|
|
Also note that "cat /proc/fs/cifs/DebugData" will display information about
|
628 |
|
|
the active sessions and the shares that are mounted.
|
629 |
|
|
Enabling Kerberos (extended security) works when CONFIG_CIFS_EXPERIMENTAL is enabled
|
630 |
|
|
but requires a user space helper (from the Samba project). NTLM and NTLMv2 and
|
631 |
|
|
LANMAN support do not require this helpr.
|