diff options
Diffstat (limited to 'fs/cifs/README')
-rw-r--r-- | fs/cifs/README | 475 |
1 files changed, 475 insertions, 0 deletions
diff --git a/fs/cifs/README b/fs/cifs/README new file mode 100644 index 000000000000..0f20edc935b5 --- /dev/null +++ b/fs/cifs/README | |||
@@ -0,0 +1,475 @@ | |||
1 | The CIFS VFS support for Linux supports many advanced network filesystem | ||
2 | features such as heirarchical 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 <cifs_download_dir>/fs/cifs/* to <kernel_download_dir>/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 or from bitkeeper | ||
36 | at bk://linux.bkbits.net/linux-2.5) and change directory into the top | ||
37 | of the kernel directory tree (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 <mount point> <UNC name or cifs URL> | ||
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 | Samba Considerations | ||
101 | ==================== | ||
102 | To get the maximum benefit from the CIFS VFS, we recommend using a server that | ||
103 | supports the SNIA CIFS Unix Extensions standard (e.g. Samba 2.2.5 or later or | ||
104 | Samba 3.0) but the CIFS vfs works fine with a wide variety of CIFS servers. | ||
105 | Note that uid, gid and file permissions will display default values if you do | ||
106 | not have a server that supports the Unix extensions for CIFS (such as Samba | ||
107 | 2.2.5 or later). To enable the Unix CIFS Extensions in the Samba server, add | ||
108 | the line: | ||
109 | |||
110 | unix extensions = yes | ||
111 | |||
112 | to your smb.conf file on the server. Note that the following smb.conf settings | ||
113 | are also useful (on the Samba server) when the majority of clients are Unix or | ||
114 | Linux: | ||
115 | |||
116 | case sensitive = yes | ||
117 | delete readonly = yes | ||
118 | ea support = yes | ||
119 | |||
120 | Note that server ea support is required for supporting xattrs from the Linux | ||
121 | cifs client, and that EA support is present in later versions of Samba (e.g. | ||
122 | 3.0.6 and later (also EA support works in all versions of Windows, at least to | ||
123 | shares on NTFS filesystems). Extended Attribute (xattr) support is an optional | ||
124 | feature of most Linux filesystems which may require enabling via | ||
125 | make menuconfig. Client support for extended attributes (user xattr) can be | ||
126 | disabled on a per-mount basis by specifying "nouser_xattr" on mount. | ||
127 | |||
128 | The CIFS client can get and set POSIX ACLs (getfacl, setfacl) to Samba servers | ||
129 | version 3.10 and later. Setting POSIX ACLs requires enabling both XATTR and | ||
130 | then POSIX support in the CIFS configuration options when building the cifs | ||
131 | module. POSIX ACL support can be disabled on a per mount basic by specifying | ||
132 | "noacl" on mount. | ||
133 | |||
134 | Some administrators may want to change Samba's smb.conf "map archive" and | ||
135 | "create mask" parameters from the default. Unless the create mask is changed | ||
136 | newly created files can end up with an unnecessarily restrictive default mode, | ||
137 | which may not be what you want, although if the CIFS Unix extensions are | ||
138 | enabled on the server and client, subsequent setattr calls (e.g. chmod) can | ||
139 | fix the mode. Note that creating special devices (mknod) remotely | ||
140 | may require specifying a mkdev function to Samba if you are not using | ||
141 | Samba 3.0.6 or later. For more information on these see the manual pages | ||
142 | ("man smb.conf") on the Samba server system. Note that the cifs vfs, | ||
143 | unlike the smbfs vfs, does not read the smb.conf on the client system | ||
144 | (the few optional settings are passed in on mount via -o parameters instead). | ||
145 | Note that Samba 2.2.7 or later includes a fix that allows the CIFS VFS to delete | ||
146 | open files (required for strict POSIX compliance). Windows Servers already | ||
147 | supported this feature. Samba server does not allow symlinks that refer to files | ||
148 | outside of the share, so in Samba versions prior to 3.0.6, most symlinks to | ||
149 | files with absolute paths (ie beginning with slash) such as: | ||
150 | ln -s /mnt/foo bar | ||
151 | would be forbidden. Samba 3.0.6 server or later includes the ability to create | ||
152 | such symlinks safely by converting unsafe symlinks (ie symlinks to server | ||
153 | files that are outside of the share) to a samba specific format on the server | ||
154 | that is ignored by local server applications and non-cifs clients and that will | ||
155 | not be traversed by the Samba server). This is opaque to the Linux client | ||
156 | application using the cifs vfs. Absolute symlinks will work to Samba 3.0.5 or | ||
157 | later, but only for remote clients using the CIFS Unix extensions, and will | ||
158 | be invisbile to Windows clients and typically will not affect local | ||
159 | applications running on the same server as Samba. | ||
160 | |||
161 | Use instructions: | ||
162 | ================ | ||
163 | Once the CIFS VFS support is built into the kernel or installed as a module | ||
164 | (cifs.o), you can use mount syntax like the following to access Samba or Windows | ||
165 | servers: | ||
166 | |||
167 | mount -t cifs //9.53.216.11/e$ /mnt -o user=myname,pass=mypassword | ||
168 | |||
169 | Before -o the option -v may be specified to make the mount.cifs | ||
170 | mount helper display the mount steps more verbosely. | ||
171 | After -o the following commonly used cifs vfs specific options | ||
172 | are supported: | ||
173 | |||
174 | user=<username> | ||
175 | pass=<password> | ||
176 | domain=<domain name> | ||
177 | |||
178 | Other cifs mount options are described below. Use of TCP names (in addition to | ||
179 | ip addresses) is available if the mount helper (mount.cifs) is installed. If | ||
180 | you do not trust the server to which are mounted, or if you do not have | ||
181 | cifs signing enabled (and the physical network is insecure), consider use | ||
182 | of the standard mount options "noexec" and "nosuid" to reduce the risk of | ||
183 | running an altered binary on your local system (downloaded from a hostile server | ||
184 | or altered by a hostile router). | ||
185 | |||
186 | Although mounting using format corresponding to the CIFS URL specification is | ||
187 | not possible in mount.cifs yet, it is possible to use an alternate format | ||
188 | for the server and sharename (which is somewhat similar to NFS style mount | ||
189 | syntax) instead of the more widely used UNC format (i.e. \\server\share): | ||
190 | mount -t cifs tcp_name_of_server:share_name /mnt -o user=myname,pass=mypasswd | ||
191 | |||
192 | When using the mount helper mount.cifs, passwords may be specified via alternate | ||
193 | mechanisms, instead of specifying it after -o using the normal "pass=" syntax | ||
194 | on the command line: | ||
195 | 1) By including it in a credential file. Specify credentials=filename as one | ||
196 | of the mount options. Credential files contain two lines | ||
197 | username=someuser | ||
198 | password=your_password | ||
199 | 2) By specifying the password in the PASSWD environment variable (similarly | ||
200 | the user name can be taken from the USER environment variable). | ||
201 | 3) By specifying the password in a file by name via PASSWD_FILE | ||
202 | 4) By specifying the password in a file by file descriptor via PASSWD_FD | ||
203 | |||
204 | If no password is provided, mount.cifs will prompt for password entry | ||
205 | |||
206 | Restrictions | ||
207 | ============ | ||
208 | Servers must support the NTLM SMB dialect (which is the most recent, supported | ||
209 | by Samba and Windows NT version 4, 2000 and XP and many other SMB/CIFS servers) | ||
210 | Servers must support either "pure-TCP" (port 445 TCP/IP CIFS connections) or RFC | ||
211 | 1001/1002 support for "Netbios-Over-TCP/IP." Neither of these is likely to be a | ||
212 | problem as most servers support this. IPv6 support is planned for the future, | ||
213 | and is almost complete. | ||
214 | |||
215 | Valid filenames differ between Windows and Linux. Windows typically restricts | ||
216 | filenames which contain certain reserved characters (e.g.the character : | ||
217 | which is used to delimit the beginning of a stream name by Windows), while | ||
218 | Linux allows a slightly wider set of valid characters in filenames. Windows | ||
219 | servers can remap such characters when an explicit mapping is specified in | ||
220 | the Server's registry. Samba starting with version 3.10 will allow such | ||
221 | filenames (ie those which contain valid Linux characters, which normally | ||
222 | would be forbidden for Windows/CIFS semantics) as long as the server is | ||
223 | configured for Unix Extensions (and the client has not disabled | ||
224 | /proc/fs/cifs/LinuxExtensionsEnabled). | ||
225 | |||
226 | |||
227 | CIFS VFS Mount Options | ||
228 | ====================== | ||
229 | A partial list of the supported mount options follows: | ||
230 | user The user name to use when trying to establish | ||
231 | the CIFS session. | ||
232 | password The user password. If the mount helper is | ||
233 | installed, the user will be prompted for password | ||
234 | if it is not supplied. | ||
235 | ip The ip address of the target server | ||
236 | unc The target server Universal Network Name (export) to | ||
237 | mount. | ||
238 | domain Set the SMB/CIFS workgroup name prepended to the | ||
239 | username during CIFS session establishment | ||
240 | uid If CIFS Unix extensions are not supported by the server | ||
241 | this overrides the default uid for inodes. For mounts to | ||
242 | servers which do support the CIFS Unix extensions, such | ||
243 | as a properly configured Samba server, the server provides | ||
244 | the uid, gid and mode. For servers which do not support | ||
245 | the Unix extensions, the default uid (and gid) returned on | ||
246 | lookup of existing files is the uid (gid) of the person | ||
247 | who executed the mount (root, except when mount.cifs | ||
248 | is configured setuid for user mounts) unless the "uid=" | ||
249 | (gid) mount option is specified. For the uid (gid) of newly | ||
250 | created files and directories, ie files created since | ||
251 | the last mount of the server share, the expected uid | ||
252 | (gid) is cached as as long as the inode remains in | ||
253 | memory on the client. Also note that permission | ||
254 | checks (authorization checks) on accesses to a file occur | ||
255 | at the server, but there are cases in which an administrator | ||
256 | may want to restrict at the client as well. For those | ||
257 | servers which do not report a uid/gid owner | ||
258 | (such as Windows), permissions can also be checked at the | ||
259 | client, and a crude form of client side permission checking | ||
260 | can be enabled by specifying file_mode and dir_mode on | ||
261 | the client | ||
262 | gid If CIFS Unix extensions are not supported by the server | ||
263 | this overrides the default gid for inodes. | ||
264 | file_mode If CIFS Unix extensions are not supported by the server | ||
265 | this overrides the default mode for file inodes. | ||
266 | dir_mode If CIFS Unix extensions are not supported by the server | ||
267 | this overrides the default mode for directory inodes. | ||
268 | port attempt to contact the server on this tcp port, before | ||
269 | trying the usual ports (port 445, then 139). | ||
270 | iocharset Codepage used to convert local path names to and from | ||
271 | Unicode. Unicode is used by default for network path | ||
272 | names if the server supports it. If iocharset is | ||
273 | not specified then the nls_default specified | ||
274 | during the local client kernel build will be used. | ||
275 | If server does not support Unicode, this parameter is | ||
276 | unused. | ||
277 | rsize default read size | ||
278 | wsize default write size | ||
279 | rw mount the network share read-write (note that the | ||
280 | server may still consider the share read-only) | ||
281 | ro mount network share read-only | ||
282 | version used to distinguish different versions of the | ||
283 | mount helper utility (not typically needed) | ||
284 | sep if first mount option (after the -o), overrides | ||
285 | the comma as the separator between the mount | ||
286 | parms. e.g. | ||
287 | -o user=myname,password=mypassword,domain=mydom | ||
288 | could be passed instead with period as the separator by | ||
289 | -o sep=.user=myname.password=mypassword.domain=mydom | ||
290 | this might be useful when comma is contained within username | ||
291 | or password or domain. This option is less important | ||
292 | when the cifs mount helper cifs.mount (version 1.1 or later) | ||
293 | is used. | ||
294 | nosuid Do not allow remote executables with the suid bit | ||
295 | program to be executed. This is only meaningful for mounts | ||
296 | to servers such as Samba which support the CIFS Unix Extensions. | ||
297 | If you do not trust the servers in your network (your mount | ||
298 | targets) it is recommended that you specify this option for | ||
299 | greater security. | ||
300 | exec Permit execution of binaries on the mount. | ||
301 | noexec Do not permit execution of binaries on the mount. | ||
302 | dev Recognize block devices on the remote mount. | ||
303 | nodev Do not recognize devices on the remote mount. | ||
304 | suid Allow remote files on this mountpoint with suid enabled to | ||
305 | be executed (default for mounts when executed as root, | ||
306 | nosuid is default for user mounts). | ||
307 | credentials Although ignored by the cifs kernel component, it is used by | ||
308 | the mount helper, mount.cifs. When mount.cifs is installed it | ||
309 | opens and reads the credential file specified in order | ||
310 | to obtain the userid and password arguments which are passed to | ||
311 | the cifs vfs. | ||
312 | guest Although ignored by the kernel component, the mount.cifs | ||
313 | mount helper will not prompt the user for a password | ||
314 | if guest is specified on the mount options. If no | ||
315 | password is specified a null password will be used. | ||
316 | perm Client does permission checks (vfs_permission check of uid | ||
317 | and gid of the file against the mode and desired operation), | ||
318 | Note that this is in addition to the normal ACL check on the | ||
319 | target machine done by the server software. | ||
320 | Client permission checking is enabled by default. | ||
321 | noperm Client does not do permission checks. This can expose | ||
322 | files on this mount to access by other users on the local | ||
323 | client system. It is typically only needed when the server | ||
324 | supports the CIFS Unix Extensions but the UIDs/GIDs on the | ||
325 | client and server system do not match closely enough to allow | ||
326 | access by the user doing the mount. | ||
327 | Note that this does not affect the normal ACL check on the | ||
328 | target machine done by the server software (of the server | ||
329 | ACL against the user name provided at mount time). | ||
330 | serverino Use servers inode numbers instead of generating automatically | ||
331 | incrementing inode numbers on the client. Although this will | ||
332 | make it easier to spot hardlinked files (as they will have | ||
333 | the same inode numbers) and inode numbers may be persistent, | ||
334 | note that the server does not guarantee that the inode numbers | ||
335 | are unique if multiple server side mounts are exported under a | ||
336 | single share (since inode numbers on the servers might not | ||
337 | be unique if multiple filesystems are mounted under the same | ||
338 | shared higher level directory). Note that this requires that | ||
339 | the server support the CIFS Unix Extensions as other servers | ||
340 | do not return a unique IndexNumber on SMB FindFirst (most | ||
341 | servers return zero as the IndexNumber). Parameter has no | ||
342 | effect to Windows servers and others which do not support the | ||
343 | CIFS Unix Extensions. | ||
344 | noserverino Client generates inode numbers (rather than using the actual one | ||
345 | from the server) by default. | ||
346 | setuids If the CIFS Unix extensions are negotiated with the server | ||
347 | the client will attempt to set the effective uid and gid of | ||
348 | the local process on newly created files, directories, and | ||
349 | devices (create, mkdir, mknod). | ||
350 | nosetuids The client will not attempt to set the uid and gid on | ||
351 | on newly created files, directories, and devices (create, | ||
352 | mkdir, mknod) which will result in the server setting the | ||
353 | uid and gid to the default (usually the server uid of the | ||
354 | usern who mounted the share). Letting the server (rather than | ||
355 | the client) set the uid and gid is the default. This | ||
356 | parameter has no effect if the CIFS Unix Extensions are not | ||
357 | negotiated. | ||
358 | netbiosname When mounting to servers via port 139, specifies the RFC1001 | ||
359 | source name to use to represent the client netbios machine | ||
360 | name when doing the RFC1001 netbios session initialize. | ||
361 | direct Do not do inode data caching on files opened on this mount. | ||
362 | This precludes mmaping files on this mount. In some cases | ||
363 | with fast networks and little or no caching benefits on the | ||
364 | client (e.g. when the application is doing large sequential | ||
365 | reads bigger than page size without rereading the same data) | ||
366 | this can provide better performance than the default | ||
367 | behavior which caches reads (reaadahead) and writes | ||
368 | (writebehind) through the local Linux client pagecache | ||
369 | if oplock (caching token) is granted and held. Note that | ||
370 | direct allows write operations larger than page size | ||
371 | to be sent to the server. | ||
372 | acl Allow setfacl and getfacl to manage posix ACLs if server | ||
373 | supports them. (default) | ||
374 | noacl Do not allow setfacl and getfacl calls on this mount | ||
375 | user_xattr Allow getting and setting user xattrs as OS/2 EAs (extended | ||
376 | attributes) to the server (default) e.g. via setfattr | ||
377 | and getfattr utilities. | ||
378 | nouser_xattr Do not allow getfattr/setfattr to get/set xattrs | ||
379 | |||
380 | The mount.cifs mount helper also accepts a few mount options before -o | ||
381 | including: | ||
382 | |||
383 | -S take password from stdin (equivalent to setting the environment | ||
384 | variable "PASSWD_FD=0" | ||
385 | -V print mount.cifs version | ||
386 | -? display simple usage information | ||
387 | |||
388 | With recent 2.6 kernel versions of modutils, the version of the cifs kernel | ||
389 | module can be displayed via modinfo. | ||
390 | |||
391 | Misc /proc/fs/cifs Flags and Debug Info | ||
392 | ======================================= | ||
393 | Informational pseudo-files: | ||
394 | DebugData Displays information about active CIFS sessions | ||
395 | and shares. | ||
396 | Stats Lists summary resource usage information as well as per | ||
397 | share statistics, if CONFIG_CIFS_STATS in enabled | ||
398 | in the kernel configuration. | ||
399 | |||
400 | Configuration pseudo-files: | ||
401 | MultiuserMount If set to one, more than one CIFS session to | ||
402 | the same server ip address can be established | ||
403 | if more than one uid accesses the same mount | ||
404 | point and if the uids user/password mapping | ||
405 | information is available. (default is 0) | ||
406 | PacketSigningEnabled If set to one, cifs packet signing is enabled | ||
407 | and will be used if the server requires | ||
408 | it. If set to two, cifs packet signing is | ||
409 | required even if the server considers packet | ||
410 | signing optional. (default 1) | ||
411 | cifsFYI If set to one, additional debug information is | ||
412 | logged to the system error log. (default 0) | ||
413 | ExtendedSecurity If set to one, SPNEGO session establishment | ||
414 | is allowed which enables more advanced | ||
415 | secure CIFS session establishment (default 0) | ||
416 | NTLMV2Enabled If set to one, more secure password hashes | ||
417 | are used when the server supports them and | ||
418 | when kerberos is not negotiated (default 0) | ||
419 | traceSMB If set to one, debug information is logged to the | ||
420 | system error log with the start of smb requests | ||
421 | and responses (default 0) | ||
422 | LookupCacheEnable If set to one, inode information is kept cached | ||
423 | for one second improving performance of lookups | ||
424 | (default 1) | ||
425 | OplockEnabled If set to one, safe distributed caching enabled. | ||
426 | (default 1) | ||
427 | LinuxExtensionsEnabled If set to one then the client will attempt to | ||
428 | use the CIFS "UNIX" extensions which are optional | ||
429 | protocol enhancements that allow CIFS servers | ||
430 | to return accurate UID/GID information as well | ||
431 | as support symbolic links. If you use servers | ||
432 | such as Samba that support the CIFS Unix | ||
433 | extensions but do not want to use symbolic link | ||
434 | support and want to map the uid and gid fields | ||
435 | to values supplied at mount (rather than the | ||
436 | actual values, then set this to zero. (default 1) | ||
437 | |||
438 | These experimental features and tracing can be enabled by changing flags in | ||
439 | /proc/fs/cifs (after the cifs module has been installed or built into the | ||
440 | kernel, e.g. insmod cifs). To enable a feature set it to 1 e.g. to enable | ||
441 | tracing to the kernel message log type: | ||
442 | |||
443 | echo 1 > /proc/fs/cifs/cifsFYI | ||
444 | |||
445 | and for more extensive tracing including the start of smb requests and responses | ||
446 | |||
447 | echo 1 > /proc/fs/cifs/traceSMB | ||
448 | |||
449 | Two other experimental features are under development and to test | ||
450 | require enabling CONFIG_CIFS_EXPERIMENTAL | ||
451 | |||
452 | More efficient write operations and SMB buffer handling | ||
453 | |||
454 | DNOTIFY fcntl: needed for support of directory change | ||
455 | notification and perhaps later for file leases) | ||
456 | |||
457 | Per share (per client mount) statistics are available in /proc/fs/cifs/Stats | ||
458 | if the kernel was configured with cifs statistics enabled. The statistics | ||
459 | represent the number of successful (ie non-zero return code from the server) | ||
460 | SMB responses to some of the more common commands (open, delete, mkdir etc.). | ||
461 | Also recorded is the total bytes read and bytes written to the server for | ||
462 | that share. Note that due to client caching effects this can be less than the | ||
463 | number of bytes read and written by the application running on the client. | ||
464 | The statistics for the number of total SMBs and oplock breaks are different in | ||
465 | that they represent all for that share, not just those for which the server | ||
466 | returned success. | ||
467 | |||
468 | Also note that "cat /proc/fs/cifs/DebugData" will display information about | ||
469 | the active sessions and the shares that are mounted. Note: NTLMv2 enablement | ||
470 | will not work since they its implementation is not quite complete yet. | ||
471 | Do not alter these configuration values unless you are doing specific testing. | ||
472 | Enabling extended security works to Windows 2000 Workstations and XP but not to | ||
473 | Windows 2000 server or Samba since it does not usually send "raw NTLMSSP" | ||
474 | (instead it sends NTLMSSP encapsulated in SPNEGO/GSSAPI, which support is not | ||
475 | complete in the CIFS VFS yet). | ||