Use the value of the parameter a list of filename-matching patterns separated by slash characters to match all the files in the share that might be a source of trouble. The syntax of this parameter is similar to that of the veto files parameter. If you want to be really careful and can live with reduced performance, you can turn off oplocks altogether, preventing the oplock break problem from ever occurring:.
This disables oplocks for all files in all shares served by the Samba server. This example allows other shares, which might have less sensitive data, to attain better performance, while trading performance for better data integrity for files in the [database] share. Most of the time, oplocks help Windows client systems cooperate to avoid overwriting each other's changes. Unix systems also have file-locking mechanisms to allow Unix processes to cooperate with each other.
But if a file stored on a Samba system is accessed by both a Windows network client and a local Unix process—without an additional coordination between the two systems—the Unix process could easily ride roughshod over an oplock. Some Unix systems have enhanced kernels that understand the Windows oplocks maintained by Samba. If you leave oplocks enabled and your Unix system does not support kernel oplocks, you could end up with corrupted data when somebody runs a Unix process that reads or writes a file that Windows users also access.
This is another case where the veto oplock files parameter can be used, assuming you can anticipate which Samba files are used by both Windows users and Unix users. We can use veto oplock files like this:. This will suppress the use of oplocks on. Samba's options for locks and oplocks are given in Table If yes , denies access to an entire file if a byte-range lock exists in it. If yes , tells client the lock was obtained, but doesn't actually lock it. The locking option can be used to tell Samba to engage or disengage server-side byte-range locks on behalf of the client.
Samba implements byte-range locks on the server side with normal Unix advisory locks and consequently prevents other properly behaved Unix processes from overwriting a locked byte range. If the locking option is set to yes , the requestor is delayed until the holder of either type of lock releases it or crashes. If, however, the option is set to no , no byte-range locks are kept for the files, although requests to lock and unlock files will appear to succeed.
The option is set to yes by default; however, you can turn this option off if you have read-only media. This option checks every file access for a byte-range lock on the range of bytes being accessed. This is typically not needed if a client adheres to all the locking mechanisms in place. This option is set to no by default; however, you can reset it per share as follows:. If this option is set to yes , mandatory locks are enforced on any file with byte-range locks.
This option enables or disables support for oplocks on the client. The option is enabled by default. However, you can disable it with the following command:. If you are in an extremely unstable network environment or have many clients that cannot take advantage of opportunistic locking, it might be better to shut this Samba feature off. If the host operating system does not support kernel oplocks, oplocks should be disabled if users are accessing the same files from both Unix applications such as vi and SMB clients.
If a Unix application on the Samba host system that is not part of the Samba suite tries to open a file for writing that Samba has oplocked to a Windows client, it is likely to succeed depending on the operating system , and both Samba and the client are never aware of it. Some versions of Unix have support for oplocks in the kernel that can work along with Samba's oplocks. In this case, the Unix process trying to open the file is suspended while Samba directs the client to write its copy back.
After that has happened, the operating system allows the open to complete. This can result in significant improvements in performance on files that are written infrequently or not at all—especially executables—because all clients can then maintain a read-ahead cache for the file.
By default, level2 oplocks is set to yes , and you probably won't need to change it. Currently, Samba cannot support level 2 oplocks along with kernel oplocks and automatically disables level 2 oplocks when kernel oplocks are in use.
This might change in future releases as improved support for oplocks is added by the Samba developers. Samba can automatically detect its Unix host's support of kernel oplocks and will set the value of kernel oplocks automatically.
You should never need to set this option in your Samba configuration file. When this option is set to yes , Samba pretends to allow oplocks rather than actually supporting them. If this option is enabled on a read-only share such as a shared CD-ROM drive , all clients are told that the files are available for opportunistic locking and never warned of simultaneous access. As a result, Windows clients cache more of the file's data and obtain much better performance.
This option was added to Samba before opportunistic-locking support was available, and it is now generally considered better to use real oplocks. Samba also supports blocking locks , a minor variant of range locks.
Here, if the range of bytes is not available, the client specifies an amount of time that it's willing to wait. The server then caches the lock request, periodically checking to see if the file is available. If it is, it notifies the client; however, if time expires, Samba will tell the client that the request has failed. This strategy prevents the client from continually polling to see if the lock is available. When set to yes , blocking locks are enforced on the file.
If this option is set to no , Samba behaves as if normal locking mechanisms are in place on the file. The default is yes. You can provide a list of filenames that are never granted opportunistic locks with the veto oplock files option. This option can be set either globally or on a per-share basis. The value of this option is a series of patterns. We recommend that you disable oplocks on any files that are meant to be updated by Unix or are intended for simultaneous sharing by several processes.
This option sometimes called lock dir specifies the location of a directory where Samba will store SMB deny-mode lock files. Samba stores other files in this directory as well, such as browse lists and its shared memory file.
You can override this location as follows:. Samba supports a mechanism called connection scripts , by which commands can be executed on the server as clients connect to a share or later disconnect from it.
By using configuration file variables along with some custom programming, you can create connection scripts that perform a wide range of functions. As a simple example, here is a "quick and dirty" way to monitor connections to shares on the Samba server in real time. First, the value of the preexec parameter is set as follows:.
To watch clients connect, run the following command:. Every time a new connection is made, an additional line is printed, showing the output of the preexec command. Notice the lines resulting from connections by user martha and aaron. The connections from aaron are similar, except that he connected from a Windows 98 system, which does not use the [profiles] share. See Chapter 4 for more information about domain logons. Checked items might include the following:.
To handle this kind of task, a shell script or other program would be written to perform the checks and take appropriate actions, such as removing offending files. The root preexec parameter would be used to run the command as the root user, using configuration file variables to pass arguments. Table introduces some of the configuration options provided for setting up users. If set to yes , nonzero exit status of root preexec command will disconnect. If set to yes , nonzero exit status of preexec command will disconnect.
This option specifies as its value a Unix command to be run as the root user before any connection to a share is completed. You should use this option specifically for performing actions that require root privilege. To ensure security, users should never be able to modify the target of the root preexec command.
In addition, unless you explicitly redirect it, any information the command sends to standard output will be discarded. If you intend to use any preexec or postexec script, you should ensure that it will run correctly before having Samba invoke it. Sometimes you might want the share to disconnect if the root preexec script fails, giving the client an error rather than allowing it to connect.
For example, if you are using root preexec to mount a CD-ROM or filesystem, it would make no sense to connect the client to it in the event that the mount fails. For example, a common use of this option is to perform logging, such as the following:. You must redirect the standard output of the command if you want to use it. Otherwise, it is discarded. This warning also applies to the command's standard error output.
If you intend to use a preexec script, you should ensure that it will run correctly before having Samba invoke it. This is similar to root preexec close , except that it goes with the preexec option. Once the user disconnects from the share, the command specified with postexec is run as the user on the Samba server to do any necessary cleanup. This option is essentially the same as the preexec option. Following the postexec option, the root postexec command is run, if one has been specified.
Again, this option specifies as its value a Unix command to be run as the root user before disconnecting from a share. In a large network where many shared folders are spread out over a large number of servers, it can be difficult for users to locate the resources they are trying to find. Browsing through Network Neighborhood or My Network Places can become an ordeal rather than a time-saving convenience.
To mitigate this problem, Microsoft added an extension to file sharing called Distributed filesystem Dfs. Using Dfs, it is possible to organize file shares on the network so that they appear to users as organized in a single directory tree on a single server, regardless of which servers on the network actually contain the resources.
Instead of having to browse the entire network, users can go to the Dfs share and locate their data much more easily. Dfs can also help administrators because it provides a level of indirection between the name of a shared folder and its actual location. The Dfs share contains references to resources on the network, and when a resource is accessed, the Dfs server hands the client off to the actual server of the resource.
When moving resources to another computer, the reference to the resource in the Dfs share can be redirected to the new location in one step, with the change being entirely seamless for users. To a limited extent, Dfs also can help improve performance for read-only shares because it provides load balancing.
It is possible to set up a Dfs reference to point to identical shares on two or more servers. The Dfs server then divides requests between the servers, dividing the client load among them. However, this works well only for static, read-only data because no provision is included in Dfs for synchronization among the servers when changes are made on any of them.
Modern versions of Windows come with client-side support for Dfs, and no extra configuration is required. Support is more limited for older versions, however.
Windows for Workgroups cannot function as a Dfs client at all. Windows NT 4. Later service packs such as Service Pack 6 include the Dfs Client. Windows 95 must also have the Dfs Client software installed to act as a Dfs client. Without the Dfs Client software, double-clicking a remote folder in a Dfs share will show an empty folder, and no error message will appear. To act as a Dfs server, Samba 2.
See Chapter 2 for instructions on configuring and compiling Samba. Samba 3. Once a Dfs-enabled Samba server is running, there are just two steps to serving a Dfs share.
First we will set up a Dfs root directory on the server, and then we will modify the smb. This can be any directory, but it is important that it be owned by root and given the proper permissions:. The Dfs directory tree can have subdirectories and files, just like any other shared directory. These will function just as they would in any other share, allowing clients to access the directories and files on the Samba server.
The whole idea of Dfs, though, is to gather together shares on other servers by making references to them in the Dfs tree. The way this is implemented with Samba involves a clever use of symbolic links, which can be in the Dfs root directory or any subdirectory in the Dfs tree.
You are probably familiar with using symbolic links to create references to files that exist on the same system, and perhaps crossing a local filesystem boundary which ordinary Unix links cannot do. But maybe you didn't know that symbolic links have a more general functionality. Although we can't display its contents directly, as we could with a text or binary file, a symbolic link "contains" an ASCII text string naming what the link points to.
For example, take a look at the listing for these symbolic links:. The size of alnk 9 bytes is smaller, corresponding to the shorter name of dreamtime. This link might appear as a "broken" link in a directory listing because it points to something that isn't a file on the local system. For example, the file command will report:. When Samba encounters this file, it sees the leading msdfs : and interprets the rest as the name of a remote share. The client is then redirected to the remote share.
Note that this is similar to a UNC appended onto the msdfs : string, except that in this case, the two backslashes preceding the server's name are omitted. In addition to regular network shares, you can use symbolic links of this type to reference Dfs shares on other Dfs servers. However, referencing printer shares does not work. Dfs is for sharing files only.
That is, simply use a list of shares separated by commas as the reference. Remember, it is up to you to make sure the shared folders remain identical. Set up permissions on the servers to make the shares read-only to users. The last thing we need to do is to modify the smb.
The Dfs root is added as a share definition:. You can use any name you like for the share. To enable support for Dfs in the server, we need to add one line to the [global] section:. Restart the Samba daemons—or just wait a minute for them to reread the configuration file—and you will see the new share from Windows clients.
If you have trouble accessing any of the remote shares in the Dfs share, recheck your symbolic links to make sure they were created correctly. If you previously had a share by the same name as your Dfs share, you might need to reboot Windows clients before they can access the share as a Dfs share. For this to work, the server that holds the home directories must also have Samba running, with a [homes] share of its own.
Table introduces the NIS configuration options specifically for setting up users. The nis homedir and homedir map options are for Samba servers on network sites where Unix home directories are provided using NFS, the automounter, and NIS. The nis homedir option indicates that the home-directory server for the user needs to be looked up in NIS. The homedir map option tells Samba in which NIS map to look for the server that has the user's home directory. The server needs to be a Samba server so that the client can do an SMB connect to it, and the other Samba servers need to have NIS installed so that they can do the lookup.
For example, if user joe asks for a share called [joe] , and the nis homedir option is set to yes , Samba will look in the file specified by homedir map for a home directory for joe.
If it finds one, Samba will return the associated system name to the client. The client will then try to connect to that machine and get the share from there. Enabling NIS lookups looks like the following:. Don't worry about that—you should still be able to see when the box is checked and when it isn't. Filesystem Differences One of the biggest issues for which Samba has to correct is the difference between Unix and Microsoft filesystems.
Hiding and Vetoing Files Sometimes you need to ensure that a user cannot see or access a file at all. Links When a client tries to open a symbolic link on a Samba server share, Samba attempts to follow the link to find the real file and let the client open it, as if the user were on a Unix machine. Filesystem Options Table shows a breakdown of the options we discussed earlier. Table Filesystem configuration options Option Parameters Function Default Scope dont descend string list of directories Indicates a list of directories whose contents Samba should make invisible to clients.
None Share follow symlinks Boolean If set to no , will not honor symbolic links. None Share veto files string list of files List of file patterns to never show.
None Share delete veto files Boolean If set to yes , will delete files matched by veto files when the directory they reside in is deleted. For example: -rwxr--r-- 1 tom users Apr 13 access.
Creation Masks File and directory creation masks are similar to umasks you have probably encountered while working with Unix systems. File and Directory Permission Options The options for file and directory permissions are summarized in Table ; each option is then described in detail. File and directory permission options Option Parameters Function Default Scope create mask create mode numeric Maximum permissions for files created by Samba.
None Share force user string username Effective username for a user accessing this share. None Share delete readonly Boolean Allows a user to delete a read-only file from a writable directory. TIP When saving documents, many Windows applications rename their datafiles with a. Versions of Unix that offer the necessary support include the following: Solaris 2. Here are some examples: virtuosity.
JAV team. TXT antidisestablishmentarianism. TXT antidisease. TXT Using these rules will allow Windows for Workgroups to differentiate the two files on behalf of the poor individual who is forced to see the network through the eyes of that operating system.
Representing and resolving filenames with Samba Another item that we should point out is that there is a difference between how an operating system represents a file and how it resolves it. Mangling Options Samba allows more refined instructions on how it should perform name mangling, including those controlling the case sensitivity, the character inserted to form a mangled name, and the ability to map filenames manually from one format to another. Name-mangling options Option Parameters Function Default Scope case sensitive casesignames Boolean If yes , treats filenames as case-sensitive Windows doesn't.
Lower Share preserve case Boolean If yes , keep the case the client supplied i. None Share case sensitive This share-level option, which has the obtuse synonym casesignames , specifies whether Samba should preserve case when resolving filenames in a specific share. Locks and Oplocks Concurrent writes to a single file are not desirable in any operating system. Opportunistic Locking Opportunistic locking allows a client to notify the Samba server that it will not only be the exclusive writer of a file, but will also cache its changes to that file locally to speed up access by reducing network activity.
Unix and Oplocks Most of the time, oplocks help Windows client systems cooperate to avoid overwriting each other's changes. Locks and Oplocks Configuration Options Samba's options for locks and oplocks are given in Table None Share lock directory string fully qualified pathname Sets the location where various Samba files, including locks, are stored.
As specified in Samba makefile Global locking The locking option can be used to tell Samba to engage or disengage server-side byte-range locks on behalf of the client. Connection Scripts Samba supports a mechanism called connection scripts , by which commands can be executed on the server as clients connect to a share or later disconnect from it. Checked items might include the following: Disk usage, on a per-share, per-directory, or per-file basis Types of files stored on the server Whether filenames follow naming guidelines Whether viruses have copied themselves to the Samba server To handle this kind of task, a shell script or other program would be written to perform the checks and take appropriate actions, such as removing offending files.
Connection Script Options Table introduces some of the configuration options provided for setting up users. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. Can Samba veto files,except specified directory? Ask Question. Asked 10 years, 1 month ago.
Active 10 years, 1 month ago. Viewed 2k times. OS:debian 6. Improve this question. Create a free Team What is Teams? Learn more. Asked 2 years ago. Active 9 months ago. Viewed 4k times. Improve this question. Add a comment. Active Oldest Votes. Improve this answer. Tthe hide files had no affect. I've only tested it on the 4. The hide files had no affect. Is there a version hard line with samba where this begins working? In any case the veto files is working for me.
0コメント