diff options
Diffstat (limited to 'docs/htmldocs/AccessControls.html')
| -rw-r--r-- | docs/htmldocs/AccessControls.html | 641 |
1 files changed, 641 insertions, 0 deletions
diff --git a/docs/htmldocs/AccessControls.html b/docs/htmldocs/AccessControls.html new file mode 100644 index 0000000000..7330836f36 --- /dev/null +++ b/docs/htmldocs/AccessControls.html @@ -0,0 +1,641 @@ +<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 13. File, Directory and Share Access Controls</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="samba-doc.html" title="SAMBA Project Documentation"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="previous" href="groupmapping.html" title="Chapter 12. Mapping MS Windows and UNIX Groups"><link rel="next" href="locking.html" title="Chapter 14. File and Record Locking"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 13. File, Directory and Share Access Controls</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="groupmapping.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="locking.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="AccessControls"></a>Chapter 13. File, Directory and Share Access Controls</h2></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jeremy</span> <span class="surname">Allison</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jra@samba.org">jra@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jelmer</span> <span class="othername">R.</span> <span class="surname">Vernooij</span></h3><span class="contrib">drawing</span><div class="affiliation"><span class="orgname">The Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>></tt></p></div></div></div></div><div><p class="pubdate">May 10, 2003</p></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="AccessControls.html#id2904266">Features and Benefits</a></dt><dt><a href="AccessControls.html#id2904395">File System Access Controls</a></dt><dd><dl><dt><a href="AccessControls.html#id2904431">MS Windows NTFS Comparison with UNIX File Systems</a></dt><dt><a href="AccessControls.html#id2904735">Managing Directories</a></dt><dt><a href="AccessControls.html#id2904829">File and Directory Access Control</a></dt></dl></dd><dt><a href="AccessControls.html#id2905040">Share Definition Access Controls</a></dt><dd><dl><dt><a href="AccessControls.html#id2905070">User and Group Based Controls</a></dt><dt><a href="AccessControls.html#id2905491">File and Directory Permissions Based Controls</a></dt><dt><a href="AccessControls.html#id2905871">Miscellaneous Controls</a></dt></dl></dd><dt><a href="AccessControls.html#id2906251">Access Controls on Shares</a></dt><dd><dl><dt><a href="AccessControls.html#id2906323">Share Permissions Management</a></dt></dl></dd><dt><a href="AccessControls.html#id2906623">MS Windows Access Control Lists and UNIX Interoperability</a></dt><dd><dl><dt><a href="AccessControls.html#id2906631">Managing UNIX permissions Using NT Security Dialogs</a></dt><dt><a href="AccessControls.html#id2906675">Viewing File Security on a Samba Share</a></dt><dt><a href="AccessControls.html#id2906755">Viewing file ownership</a></dt><dt><a href="AccessControls.html#id2906887">Viewing File or Directory Permissions</a></dt><dt><a href="AccessControls.html#id2907132">Modifying file or directory permissions</a></dt><dt><a href="AccessControls.html#id2907296">Interaction with the standard Samba create mask + parameters</a></dt><dt><a href="AccessControls.html#id2907693">Interaction with the standard Samba file attribute mapping</a></dt></dl></dd><dt><a href="AccessControls.html#id2907788">Common Errors</a></dt><dd><dl><dt><a href="AccessControls.html#id2907802">Users can not write to a public share</a></dt><dt><a href="AccessControls.html#id2908232">I have set force user but Samba still makes root the owner of all the files I touch!</a></dt><dt><a href="AccessControls.html#id2908284">MS Word with Samba changes owner of file</a></dt></dl></dd></dl></div><a class="indexterm" name="id2904188"></a><p> +Advanced MS Windows users are frequently perplexed when file, directory and share manipulation of +resources shared via Samba do not behave in the manner they might expect. MS Windows network +administrators are often confused regarding network access controls and how to +provide users with the access they need while protecting resources from unauthorised access. +</p><p> +Many UNIX administrators are unfamiliar with the MS Windows environment and in particular +have difficulty in visualizing what the MS Windows user wishes to achieve in attempts to set file +and directory access permissions. +</p><p> +The problem lies in the differences in how file and directory permissions and controls work +between the two environments. This difference is one that Samba can not completely hide, even +though it does try to bridge the chasm to a degree. +</p><a class="indexterm" name="id2904225"></a><p> +POSIX Access Control List technology has been available (along with Extended Attributes) +for UNIX for many years, yet there is little evidence today of any significant use. This +explains to some extent the slow adoption of ACLs into commercial Linux products. MS Windows +administrators are astounded at this given that ACLs were a foundational capability of the now +decade old MS Windows NT operating system. +</p><p> +The purpose of this chapter is to present each of the points of control that are possible with +Samba-3 in the hope that this will help the network administrator to find the optimum method +for delivering the best environment for MS Windows desktop users. +</p><p> +This is an opportune point to mention that Samba was created to provide a means of interoperability +and interchange of data between differing operating environments. Samba has no intent change +UNIX/Linux into a platform like MS Windows. Instead the purpose was and is to provide a sufficient +level of exchange of data between the two environments. What is available today extends well +beyond early plans and expectations, yet the gap continues to shrink. +</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2904266"></a>Features and Benefits</h2></div></div><div></div></div><p> + Samba offers a lot of flexibility in file system access management. These are the key access control + facilities present in Samba today: + </p><div class="itemizedlist"><p class="title"><b>Samba Access Control Facilities</b></p><ul type="disc"><li><p> + <span class="emphasis"><em>UNIX File and Directory Permissions</em></span> + </p><p> + Samba honours and implements UNIX file system access controls. Users + who access a Samba server will do so as a particular MS Windows user. + This information is passed to the Samba server as part of the logon or + connection setup process. Samba uses this user identity to validate + whether or not the user should be given access to file system resources + (files and directories). This chapter provides an overview for those + to whom the UNIX permissions and controls are a little strange or unknown. + </p></li><li><p> + <span class="emphasis"><em>Samba Share Definitions</em></span> + </p><p> + In configuring share settings and controls in the <tt class="filename">smb.conf</tt> file + the network administrator can exercise over-rides to native file + system permissions and behaviours. This can be handy and convenient + to affect behaviour that is more like what MS Windows NT users expect + but it is seldom the <span class="emphasis"><em>best</em></span> way to achieve this. + The basic options and techniques are described herein. + </p></li><li><p> + <span class="emphasis"><em>Samba Share ACLs</em></span> + </p><p> + Just like it is possible in MS Windows NT to set ACLs on shares + themselves, so it is possible to do this in Samba. + Very few people make use of this facility, yet it remains on of the + easiest ways to affect access controls (restrictions) and can often + do so with minimum invasiveness compared with other methods. + </p></li><li><p> + <span class="emphasis"><em>MS Windows ACLs through UNIX POSIX ACLs</em></span> + </p><p> + The use of POSIX ACLs on UNIX/Linux is possible ONLY if the underlying + operating system supports them. If not, then this option will not be + available to you. Current UNIX technology platforms have native support + for POSIX ACLs. There are patches for the Linux kernel that provide + this also. Sadly, few Linux platforms ship today with native ACLs and + Extended Attributes enabled. This chapter has pertinent information + for users of platforms that support them. + </p></li></ul></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2904395"></a>File System Access Controls</h2></div></div><div></div></div><p> +Perhaps the most important recognition to be made is the simple fact that MS Windows NT4 / 200x / XP +implement a totally divergent file system technology from what is provided in the UNIX operating system +environment. Firstly we should consider what the most significant differences are, then we shall look +at how Samba helps to bridge the differences. +</p><a class="indexterm" name="id2904414"></a><a class="indexterm" name="id2904423"></a><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2904431"></a>MS Windows NTFS Comparison with UNIX File Systems</h3></div></div><div></div></div><p> + Samba operates on top of the UNIX file system. This means it is subject to UNIX file system conventions + and permissions. It also means that if the MS Windows networking environment requires file system + behaviour that differs from unix file system behaviour then somehow Samba is responsible for emulating + that in a transparent and consistent manner. + </p><p> + It is good news that Samba does this to a very large extent and on top of that provides a high degree + of optional configuration to over-ride the default behaviour. We will look at some of these over-rides, + but for the greater part we will stay within the bounds of default behaviour. Those wishing to explore + to depths of control ability should review the <tt class="filename">smb.conf</tt> man page. + </p><div class="variablelist"><p class="title"><b>File System Feature Comparison</b></p><dl><dt><span class="term">Name Space</span></dt><dd><p> + MS Windows NT4 / 200x/ XP files names may be up to 254 characters long, UNIX file names + may be 1023 characters long. In MS Windows file extensions indicate particular file types, + in UNIX this is not so rigorously observed as all names are considered arbitrary. + </p><p> + What MS Windows calls a Folder, UNIX calls a directory. + </p></dd><dt><span class="term">Case Sensitivity</span></dt><dd><p> + <a class="indexterm" name="id2904517"></a> + MS Windows file names are generally upper case if made up of 8.3 (ie: 8 character file name + and 3 character extension. If longer than 8.3 file names are Case Preserving, and Case + Insensitive. + </p><p> + UNIX file and directory names are case sensitive and case preserving. Samba implements the + MS Windows file name behaviour, but it does so as a user application. The UNIX file system + provides no mechanism to perform case insensitive file name lookups. MS Windows does this + by default. This means that Samba has to carry the processing overhead to provide features + that are NOT native to the UNIX operating system environment. + </p><p> + Consider the following, all are unique UNIX names but one single MS Windows file name: + <tt class="computeroutput"> + MYFILE.TXT + MyFile.txt + myfile.txt + </tt> + So clearly, In an MS Windows file name space these three files CAN NOT co-exist! But in UNIX + they can. So what should Samba do if all three are present? Answer, the one that is lexically + first will be accessible to MS Windows users, the others are invisible and unaccessible - any + other solution would be suicidal. + </p></dd><dt><span class="term">Directory Separators</span></dt><dd><p> + MS Windows and DOS uses the back-slash '\' as a directory delimiter, UNIX uses the forward-slash '/' + as it's directory delimiter. This is transparently handled by Samba. + </p></dd><dt><span class="term">Drive Identification</span></dt><dd><p> + MS Windows products support a notion of drive letters, like <b class="command">C:</b> to represent + disk partitions. UNIX has NO concept if separate identifiers for file partitions since each + such file system is <tt class="filename">mounted</tt> to become part of the over-all directory tree. + The UNIX directory tree begins at '/', just like the root of a DOS drive is specified like + <b class="command">C:\</b>. + </p></dd><dt><span class="term">File Naming Conventions</span></dt><dd><p> + MS Windows generally never experiences file names that begin with a '.', while in UNIX these + are commonly found in a user's home directory. Files that begin with a '.' are typically + either start up files for various UNIX applications, or they may be files that contain + start-up configuration data. + </p></dd><dt><span class="term">Links and Short-Cuts</span></dt><dd><p> + <a class="indexterm" name="id2904667"></a> + <a class="indexterm" name="id2904678"></a> + <a class="indexterm" name="id2904689"></a> + + MS Windows make use of "links and Short-Cuts" that are actually special types of files that will + redirect an attempt to execute the file to the real location of the file. UNIX knows of file and directory + links, but they are entirely different from what MS Windows users are used to. + </p><p> + Symbolic links are files in UNIX that contain the actual location of the data (file OR directory). An + operation (like read or write) will operate directly on the file referenced. Symbolic links are also + referred to as 'soft links'. A hard link is something that MS Windows is NOT familiar with. It allows + one physical file to be known simultaneously by more than one file name. + </p></dd></dl></div><p> + There are many other subtle differences that may cause the MS Windows administrator some temporary discomfort + in the process of becoming familiar with UNIX/Linux. These are best left for a text that is dedicated to the + purpose of UNIX/Linux training/education. + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2904735"></a>Managing Directories</h3></div></div><div></div></div><p> + There are three basic operations for managing directories, <b class="command">create, delete, rename</b>. + </p><div class="table"><a name="id2904754"></a><p class="title"><b>Table 13.1. Managing directories with unix and windows</b></p><table summary="Managing directories with unix and windows" border="1"><colgroup><col><col><col></colgroup><thead><tr><th align="center">Action</th><th align="center">MS Windows Command</th><th align="center">UNIX Command</th></tr></thead><tbody><tr><td align="center">create</td><td align="center">md folder</td><td align="center">mkdir folder</td></tr><tr><td align="center">delete</td><td align="center">rd folder</td><td align="center">rmdir folder</td></tr><tr><td align="center">rename</td><td align="center">rename oldname newname</td><td align="center">mv oldname newname</td></tr></tbody></table></div><p> + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2904829"></a>File and Directory Access Control</h3></div></div><div></div></div><p> + The network administrator is strongly advised to read foundational training manuals and reference materials + regarding file and directory permissions maintenance. Much can be achieved with the basic UNIX permissions + without having to resort to more complex facilities like POSIX Access Control Lists (ACLs) or Extended + Attributes (EAs). + </p><p> + UNIX/Linux file and directory access permissions involves setting three (3) primary sets of data and one (1) control set. + A UNIX file listing looks as follows:- + +</p><pre class="screen"> +<tt class="prompt">$ </tt><b class="userinput"><tt>ls -la</tt></b> +total 632 +drwxr-xr-x 13 maryo gnomes 816 2003-05-12 22:56 . +drwxrwxr-x 37 maryo gnomes 3800 2003-05-12 22:29 .. +dr-xr-xr-x 2 maryo gnomes 48 2003-05-12 22:29 muchado02 +drwxrwxrwx 2 maryo gnomes 48 2003-05-12 22:29 muchado03 +drw-rw-rw- 2 maryo gnomes 48 2003-05-12 22:29 muchado04 +d-w--w--w- 2 maryo gnomes 48 2003-05-12 22:29 muchado05 +dr--r--r-- 2 maryo gnomes 48 2003-05-12 22:29 muchado06 +drwsrwsrwx 2 maryo gnomes 48 2003-05-12 22:29 muchado08 +---------- 1 maryo gnomes 1242 2003-05-12 22:31 mydata00.lst +--w--w--w- 1 maryo gnomes 7754 2003-05-12 22:33 mydata02.lst +-r--r--r-- 1 maryo gnomes 21017 2003-05-12 22:32 mydata04.lst +-rw-rw-rw- 1 maryo gnomes 41105 2003-05-12 22:32 mydata06.lst +<tt class="prompt">$ </tt> +</pre><p> + </p><p> + The columns above represent (from left to right): permissions, number of hard links to file, owner, group, size (bytes), access date, access time, file name. + </p><p> + An overview of the permissions field can be found in <a href="AccessControls.html#access1" title="Figure 13.1. Overview of unix permissions field">the image below</a>. + </p><div class="figure"><a name="access1"></a><p class="title"><b>Figure 13.1. Overview of unix permissions field</b></p><div class="mediaobject"><img src="projdoc/imagefiles/access1.png" width="270" alt="Overview of unix permissions field"></div></div><p> + Any bit flag may be unset. An unset bit flag is the equivalent of 'Can NOT' and is represented as a '-' character. + + </p><div class="example"><a name="id2904965"></a><p class="title"><b>Example 13.1. Example File</b></p><pre class="programlisting"> + -rwxr-x--- Means: The owner (user) can read, write, execute + the group can read and execute + everyone else can NOT do anything with it + </pre></div><p> + + </p><p> + Additional possibilities in the [type] field are: c = character device, b = block device, p = pipe device, s = UNIX Domain Socket. + </p><p> + The letters `rwxXst' set permissions for the user, group and others as: read (r), write (w), execute (or access for directories) (x), + execute only if the file is a directory or already has execute permission for some user (X), set user or group ID on execution (s), + sticky (t). + </p><p> + When the sticky bit is set on a directory, files in that directory may be unlinked (deleted) or renamed only by root or their owner. + Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on + directories, such as /tmp, that are world-writable. + </p><p> + When the set user or group ID bit (s) is set on a directory, then all files created within it will be owned by the user and/or + group whose 'set user or group' bit is set. This can be very helpful in setting up directories that for which it is desired that + all users who are in a group should be able to write to and read from a file, particularly when it is undesirable for that file + to be exclusively owned by a user who's primary group is not the group that all such users belong to. + </p><p> + When a directory is set <tt class="constant">drw-r-----</tt> this means that the owner can read and create (write) files in it, but because + the (x) execute flags are not set files can not be listed (seen) in the directory by anyone. The group can read files in the + directory but can NOT create new files. NOTE: If files in the directory are set to be readable and writable for the group, then + group members will be able to write to (or delete) them. + </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2905040"></a>Share Definition Access Controls</h2></div></div><div></div></div><p> +The following parameters in the <tt class="filename">smb.conf</tt> file sections that define a share control or affect access controls. +Before using any of the following options please refer to the man page for <tt class="filename">smb.conf</tt>. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2905070"></a>User and Group Based Controls</h3></div></div><div></div></div><p> + User and group based controls can prove very useful. In some situations it is distinctly desirable to affect all + file system operations as if a single user is doing this, the use of the <a class="indexterm" name="id2905084"></a><i class="parameter"><tt>force user</tt></i> and + <a class="indexterm" name="id2905097"></a><i class="parameter"><tt>force group</tt></i> behaviour will achieve this. In other situations it may be necessary to affect a + paranoia level of control to ensure that only particular authorised persons will be able to access a share or + it's contents, here the use of the <a class="indexterm" name="id2905115"></a><i class="parameter"><tt>valid users</tt></i> or the <a class="indexterm" name="id2905129"></a><i class="parameter"><tt>invalid users</tt></i> may + be most useful. + </p><p> + As always, it is highly advisable to use the least difficult to maintain and the least ambiguous method for + controlling access. Remember, that when you leave the scene someone else will need to provide assistance and + if that person finds too great a mess, or if they do not understand what you have done then there is risk of + Samba being removed and an alternative solution being adopted. + </p><div class="table"><a name="id2905157"></a><p class="title"><b>Table 13.2. User and Group Based Controls</b></p><table summary="User and Group Based Controls" border="1"><colgroup><col align="left"><col align="justify"></colgroup><thead><tr><th align="center">Control Parameter</th><th align="center">Description - Action - Notes</th></tr></thead><tbody><tr><td align="left"><a class="indexterm" name="id2905214"></a><i class="parameter"><tt>admin users</tt></i></td><td align="justify"><p> + List of users who will be granted administrative privileges on the share. + They will do all file operations as the super-user (root). + Any user in this list will be able to do anything they like on the share, + irrespective of file permissions. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905244"></a><i class="parameter"><tt>force group</tt></i></td><td align="justify"><p> + Specifies a UNIX group name that will be assigned as the default primary group + for all users connecting to this service. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905271"></a><i class="parameter"><tt>force user</tt></i></td><td align="justify"><p> + Specifies a UNIX user name that will be assigned as the default user for all users connecting to this service. + This is useful for sharing files. Incorrect use can cause security problems. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905299"></a><i class="parameter"><tt>guest ok</tt></i></td><td align="justify"><p> + If this parameter is set for a service, then no password is required to connect to the service. Privileges will be + those of the guest account. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905326"></a><i class="parameter"><tt>invalid users</tt></i></td><td align="justify"><p> + List of users that should not be allowed to login to this service. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905353"></a><i class="parameter"><tt>only user</tt></i></td><td align="justify"><p> + Controls whether connections with usernames not in the user list will be allowed. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905379"></a><i class="parameter"><tt>read list</tt></i></td><td align="justify"><p> + List of users that are given read-only access to a service. Users in this list + will not be given write access, no matter what the read only option is set to. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905406"></a><i class="parameter"><tt>username</tt></i></td><td align="justify"><p> + Refer to the <tt class="filename">smb.conf</tt> man page for more information - this is a complex and potentially misused parameter. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905440"></a><i class="parameter"><tt>valid users</tt></i></td><td align="justify"><p> + List of users that should be allowed to login to this service. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905466"></a><i class="parameter"><tt>write list</tt></i></td><td align="justify"><p> + List of users that are given read-write access to a service. + </p></td></tr></tbody></table></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2905491"></a>File and Directory Permissions Based Controls</h3></div></div><div></div></div><p> + The following file and directory permission based controls, if misused, can result in considerable difficulty to + diagnose the cause of mis-configuration. Use them sparingly and carefully. By gradually introducing each one by one + undesirable side-effects may be detected. In the event of a problem, always comment all of them out and then gradually + re-introduce them in a controlled fashion. + </p><div class="table"><a name="id2905512"></a><p class="title"><b>Table 13.3. File and Directory Permission Based Controls</b></p><table summary="File and Directory Permission Based Controls" border="1"><colgroup><col align="left"><col align="justify"></colgroup><thead><tr><th align="center">Control Parameter</th><th align="center">Description - Action - Notes</th></tr></thead><tbody><tr><td align="left"><a class="indexterm" name="id2905567"></a><i class="parameter"><tt>create mask</tt></i></td><td align="justify"><p> + Refer to the <tt class="filename">smb.conf</tt> man page. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905599"></a><i class="parameter"><tt>directory mask</tt></i></td><td align="justify"><p> + The octal modes used when converting DOS modes to UNIX modes when creating UNIX directories. + See also: directory security mask. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905626"></a><i class="parameter"><tt>dos filemode</tt></i></td><td align="justify"><p> + Enabling this parameter allows a user who has write access to the file to modify the permissions on it. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905652"></a><i class="parameter"><tt>force create mode</tt></i></td><td align="justify"><p> + This parameter specifies a set of UNIX mode bit permissions that will always be set on a file created by Samba. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905680"></a><i class="parameter"><tt>force directory mode</tt></i></td><td align="justify"><p> + This parameter specifies a set of UNIX mode bit permissions that will always be set on a directory created by Samba. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905708"></a><i class="parameter"><tt>force directory security mode</tt></i></td><td align="justify"><p> + Controls UNIX permission bits modified when a Windows NT client is manipulating UNIX permissions on a directory + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905736"></a><i class="parameter"><tt>force security mode</tt></i></td><td align="justify"><p> + Controls UNIX permission bits modified when a Windows NT client manipulates UNIX permissions. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905762"></a><i class="parameter"><tt>hide unreadable</tt></i></td><td align="justify"><p> + Prevents clients from seeing the existence of files that cannot be read. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905789"></a><i class="parameter"><tt>hide unwriteable files</tt></i></td><td align="justify"><p> + Prevents clients from seeing the existence of files that cannot be written to. Unwriteable directories are shown as usual. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905817"></a><i class="parameter"><tt>nt acl support</tt></i></td><td align="justify"><p> + This parameter controls whether smbd will attempt to map UNIX permissions into Windows NT access control lists. + </p></td></tr><tr><td align="left"><a class="indexterm" name="id2905844"></a><i class="parameter"><tt>security mask</tt></i></td><td align="justify"><p> + Controls UNIX permission bits modified when a Windows NT client is manipulating the UNIX permissions on a file. + </p></td></tr></tbody></table></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2905871"></a>Miscellaneous Controls</h3></div></div><div></div></div><p> + The following are documented because of the prevalence of administrators creating inadvertent barriers to file + access by not understanding the full implications of <tt class="filename">smb.conf</tt> file settings. + </p><div class="table"><a name="id2905893"></a><p class="title"><b>Table 13.4. Other Controls</b></p><table summary="Other Controls" border="1"><colgroup><col align="justify"><col align="justify"></colgroup><thead><tr><th align="center">Control Parameter</th><th align="center">Description - Action - Notes</th></tr></thead><tbody><tr><td align="justify"><a class="indexterm" name="id2905948"></a><i class="parameter"><tt>case sensitive</tt></i>, <a class="indexterm" name="id2905962"></a><i class="parameter"><tt>default case</tt></i>, <a class="indexterm" name="id2905976"></a><i class="parameter"><tt>short preserve case</tt></i></td><td align="justify"><p> + This means that all file name lookup will be done in a case sensitive manner. + Files will be created with the precise filename Samba received from the MS Windows client. + </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2906004"></a><i class="parameter"><tt>csc policy</tt></i></td><td align="justify"><p> + Client Side Caching Policy - parallels MS Windows client side file caching capabilities. + </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2906031"></a><i class="parameter"><tt>dont descend</tt></i></td><td align="justify"><p> + Allows to specify a comma-delimited list of directories that the server should always show as empty. + </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2906058"></a><i class="parameter"><tt>dos filetime resolution</tt></i></td><td align="justify"><p> + This option is mainly used as a compatibility option for Visual C++ when used against Samba shares. + </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2906085"></a><i class="parameter"><tt>dos filetimes</tt></i></td><td align="justify"><p> + DOS and Windows allows users to change file time stamps if they can write to the file. POSIX semantics prevent this. + This options allows DOS and Windows behaviour. + </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2906112"></a><i class="parameter"><tt>fake oplocks</tt></i></td><td align="justify"><p> + Oplocks are the way that SMB clients get permission from a server to locally cache file operations. If a server grants an + oplock then the client is free to assume that it is the only one accessing the file and it will aggressively cache file data. + </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2906143"></a><i class="parameter"><tt>hide dot files</tt></i>, <a class="indexterm" name="id2906157"></a><i class="parameter"><tt>hide files</tt></i>, <a class="indexterm" name="id2906171"></a><i class="parameter"><tt>veto files</tt></i></td><td align="justify"><p> + Note: MS Windows Explorer allows over-ride of files marked as hidden so they will still be visible. + </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2906196"></a><i class="parameter"><tt>read only</tt></i></td><td align="justify"><p> + If this parameter is yes, then users of a service may not create or modify files in the service's directory. + </p></td></tr><tr><td align="justify"><a class="indexterm" name="id2906224"></a><i class="parameter"><tt>veto files</tt></i></td><td align="justify"><p> + List of files and directories that are neither visible nor accessible. + </p></td></tr></tbody></table></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2906251"></a>Access Controls on Shares</h2></div></div><div></div></div><p> + This section deals with how to configure Samba per share access control restrictions. + By default, Samba sets no restrictions on the share itself. Restrictions on the share itself + can be set on MS Windows NT4/200x/XP shares. This can be a very effective way to limit who can + connect to a share. In the absence of specific restrictions the default setting is to allow + the global user <tt class="constant">Everyone</tt> Full Control (ie: Full control, Change and Read). + </p><p> + At this time Samba does NOT provide a tool for configuring access control setting on the Share + itself. Samba does have the capacity to store and act on access control settings, but the only + way to create those settings is to use either the NT4 Server Manager or the Windows 200x MMC for + Computer Management. + </p><p> + Samba stores the per share access control settings in a file called <tt class="filename">share_info.tdb</tt>. + The location of this file on your system will depend on how samba was compiled. The default location + for Samba's tdb files is under <tt class="filename">/usr/local/samba/var</tt>. If the <tt class="filename">tdbdump</tt> + utility has been compiled and installed on your system, then you can examine the contents of this file + by: <b class="userinput"><tt>tdbdump share_info.tdb</tt></b>. + </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2906323"></a>Share Permissions Management</h3></div></div><div></div></div><p> + The best tool for the task is platform dependant. Choose the best tool for your environment. + </p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2906336"></a>Windows NT4 Workstation/Server</h4></div></div><div></div></div><p> + The tool you need to use to manage share permissions on a Samba server is the NT Server Manager. + Server Manager is shipped with Windows NT4 Server products but not with Windows NT4 Workstation. + You can obtain the NT Server Manager for MS Windows NT4 Workstation from Microsoft - see details below. + </p><div class="procedure"><p class="title"><b>Procedure 13.1. Instructions</b></p><ol type="1"><li><p> + Launch the <span class="application">NT4 Server Manager</span>, click on the Samba server you want to administer, then from the menu + select <span class="guimenu">Computer</span>, then click on the <span class="guimenuitem">Shared Directories</span> entry. + </p></li><li><p> + Now click on the share that you wish to manage, then click on the <span class="guilabel">Properties</span> tab, next click on + the <span class="guilabel">Permissions</span> tab. Now you can add or change access control settings as you wish. + </p></li></ol></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2906419"></a>Windows 200x/XP</h4></div></div><div></div></div><p> + On <span class="application">MS Windows NT4/200x/XP</span> system access control lists on the share itself are set using native + tools, usually from file manager. For example, in Windows 200x: right click on the shared folder, + then select <span class="guimenuitem">Sharing</span>, then click on <span class="guilabel">Permissions</span>. The default + Windows NT4/200x permission allows <span class="emphasis"><em>Everyone</em></span> Full Control on the Share. + </p><p> + MS Windows 200x and later all comes with a tool called the <span class="application">Computer Management</span> snap-in for the + Microsoft Management Console (MMC). This tool is located by clicking on <tt class="filename">Control Panel -> + Administrative Tools -> Computer Management</tt>. + </p><div class="procedure"><p class="title"><b>Procedure 13.2. Instructions</b></p><ol type="1"><li><p> + After launching the MMC with the Computer Management snap-in, click on the menu item <span class="guimenuitem">Action</span>, + select <span class="guilabel">Connect to another computer</span>. If you are not logged onto a domain you will be prompted + to enter a domain login user identifier and a password. This will authenticate you to the domain. + If you where already logged in with administrative privilege this step is not offered. + </p></li><li><p> + If the Samba server is not shown in the <span class="guilabel">Select Computer</span> box, then type in the name of the target + Samba server in the field <span class="guilabel">Name:</span>. Now click on the <span class="guibutton">[+]</span> next to + <span class="guilabel">System Tools</span>, then on the <span class="guibutton">[+]</span> next to <span class="guilabel">Shared Folders</span> in the + left panel. + </p></li><li><p> + Now in the right panel, double-click on the share you wish to set access control permissions on. + Then click on the tab <span class="guilabel">Share Permissions</span>. It is now possible to add access control entities + to the shared folder. Do NOT forget to set what type of access (full control, change, read) you + wish to assign for each entry. + </p></li></ol></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p> + Be careful. If you take away all permissions from the <tt class="constant">Everyone</tt> user without removing this user + then effectively no user will be able to access the share. This is a result of what is known as + ACL precedence. ie: Everyone with <span class="emphasis"><em>no access</em></span> means that MaryK who is part of the group + <tt class="constant">Everyone</tt> will have no access even if this user is given explicit full control access. + </p></div></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2906623"></a>MS Windows Access Control Lists and UNIX Interoperability</h2></div></div><div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2906631"></a>Managing UNIX permissions Using NT Security Dialogs</h3></div></div><div></div></div><p> + Windows NT clients can use their native security settings dialog box to view and modify the + underlying UNIX permissions. + </p><p> + Note that this ability is careful not to compromise the security of the UNIX host Samba is running on, and + still obeys all the file permission rules that a Samba administrator can set. + </p><p> + Samba does not attempt to go beyond POSIX ACLs, so that the various finer-grained access control + options provided in Windows are actually ignore. + </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> + All access to UNIX/Linux system files via Samba is controlled by the operating system file access controls. + When trying to figure out file access problems it is vitally important to find the identity of the Windows + user as it is presented by Samba at the point of file access. This can best be determined from the + Samba log files. + </p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2906675"></a>Viewing File Security on a Samba Share</h3></div></div><div></div></div><p> + From an NT4/2000/XP client, single-click with the right mouse button on any file or directory in a Samba + mounted drive letter or UNC path. When the menu pops-up, click on the <span class="guilabel">Properties</span> + entry at the bottom of the menu. This brings up the file properties dialog box. Click on the tab + <span class="guilabel">Security</span> and you will see three buttons, <span class="guibutton">Permissions</span>, + <span class="guibutton">Auditing</span>, and <span class="guibutton">Ownership</span>. The <span class="guibutton">Auditing</span> + button will cause either an error message <span class="errorname">A requested privilege is not held by the client</span> + to appear if the user is not the NT Administrator, or a dialog which is intended to allow an Administrator + to add auditing requirements to a file if the user is logged on as the NT Administrator. This dialog is + non-functional with a Samba share at this time, as the only useful button, the <span class="guibutton">Add</span> + button will not currently allow a list of users to be seen. + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2906755"></a>Viewing file ownership</h3></div></div><div></div></div><p> + Clicking on the <span class="guibutton">Ownership</span> button brings up a dialog box telling you who owns + the given file. The owner name will be of the form: + </p><p> + <b class="command">"SERVER\user (Long name)"</b> + </p><p> + Where <i class="replaceable"><tt>SERVER</tt></i> is the NetBIOS name of the Samba server, <i class="replaceable"><tt>user</tt></i> + is the user name of the UNIX user who owns the file, and <i class="replaceable"><tt>(Long name)</tt></i> is the + descriptive string identifying the user (normally found in the GECOS field of the UNIX password database). + Click on the <span class="guibutton">Close </span> button to remove this dialog. + </p><p> + If the parameter <a class="indexterm" name="id2906818"></a><i class="parameter"><tt>nt acl support</tt></i> is set to <tt class="constant">false</tt> + then the file owner will be shown as the NT user <tt class="constant">"Everyone"</tt>. + </p><p> + The <span class="guibutton">Take Ownership</span> button will not allow you to change the ownership of this file to + yourself (clicking on it will display a dialog box complaining that the user you are currently logged onto + the NT client cannot be found). The reason for this is that changing the ownership of a file is a privileged + operation in UNIX, available only to the <span class="emphasis"><em>root</em></span> user. As clicking on this button causes + NT to attempt to change the ownership of a file to the current user logged into the NT client this will + not work with Samba at this time.</p><p> + There is an NT chown command that will work with Samba and allow a user with Administrator privilege connected + to a Samba server as root to change the ownership of files on both a local NTFS filesystem or remote mounted NTFS + or Samba drive. This is available as part of the <span class="application">Seclib</span> NT security library written + by Jeremy Allison of the Samba-Team, available from the main Samba FTP site.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2906887"></a>Viewing File or Directory Permissions</h3></div></div><div></div></div><p> + The third button is the <span class="guibutton">Permissions</span> button. Clicking on this brings up a dialog box + that shows both the permissions and the UNIX owner of the file or directory. The owner is displayed in the form: + </p><p><b class="command">"<i class="replaceable"><tt>SERVER</tt></i>\ + <i class="replaceable"><tt>user</tt></i> + <i class="replaceable"><tt>(Long name)</tt></i>"</b></p><p>Where <i class="replaceable"><tt>SERVER</tt></i> is the NetBIOS name of the Samba server, + <i class="replaceable"><tt>user</tt></i> is the user name of the UNIX user who owns the file, and + <i class="replaceable"><tt>(Long name)</tt></i> is the descriptive string identifying the user (normally found in the + GECOS field of the UNIX password database).</p><p> + If the parameter <a class="indexterm" name="id2906953"></a><i class="parameter"><tt>nt acl support</tt></i> is set to <tt class="constant">false</tt> + then the file owner will be shown as the NT user <tt class="constant">"Everyone"</tt> and the permissions will be + shown as NT "Full Control". + </p><p> + The permissions field is displayed differently for files and directories, so I'll describe the way file permissions + are displayed first. + </p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2906986"></a>File Permissions</h4></div></div><div></div></div><p>The standard UNIX user/group/world triplet and + the corresponding "read", "write", "execute" permissions + triplets are mapped by Samba into a three element NT ACL + with the 'r', 'w', and 'x' bits mapped into the corresponding + NT permissions. The UNIX world permissions are mapped into + the global NT group <tt class="constant">Everyone</tt>, followed + by the list of permissions allowed for UNIX world. The UNIX + owner and group permissions are displayed as an NT + <span class="guiicon">user</span> icon and an NT <span class="guiicon">local + group</span> icon respectively followed by the list + of permissions allowed for the UNIX user and group.</p><p>As many UNIX permission sets don't map into common + NT names such as <tt class="constant">read</tt>, <tt class="constant"> + "change"</tt> or <tt class="constant">full control</tt> then + usually the permissions will be prefixed by the words <tt class="constant"> + "Special Access"</tt> in the NT display list.</p><p>But what happens if the file has no permissions allowed + for a particular UNIX user group or world component? In order + to allow "no permissions" to be seen and modified then Samba + overloads the NT <b class="command">"Take Ownership"</b> ACL attribute + (which has no meaning in UNIX) and reports a component with + no permissions as having the NT <b class="command">"O"</b> bit set. + This was chosen of course to make it look like a zero, meaning + zero permissions. More details on the decision behind this will + be given below.</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2907088"></a>Directory Permissions</h4></div></div><div></div></div><p>Directories on an NT NTFS file system have two + different sets of permissions. The first set of permissions + is the ACL set on the directory itself, this is usually displayed + in the first set of parentheses in the normal <tt class="constant">"RW"</tt> + NT style. This first set of permissions is created by Samba in + exactly the same way as normal file permissions are, described + above, and is displayed in the same way.</p><p>The second set of directory permissions has no real meaning + in the UNIX permissions world and represents the <tt class="constant"> + inherited</tt> permissions that any file created within + this directory would inherit.</p><p>Samba synthesises these inherited permissions for NT by + returning as an NT ACL the UNIX permission mode that a new file + created by Samba on this share would receive.</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2907132"></a>Modifying file or directory permissions</h3></div></div><div></div></div><p>Modifying file and directory permissions is as simple + as changing the displayed permissions in the dialog box, and + clicking the <span class="guibutton">OK</span> button. However, there are + limitations that a user needs to be aware of, and also interactions + with the standard Samba permission masks and mapping of DOS + attributes that need to also be taken into account.</p><p>If the parameter <a class="indexterm" name="id2907161"></a><i class="parameter"><tt>nt acl support</tt></i> + is set to <tt class="constant">false</tt> then any attempt to set + security permissions will fail with an <span class="errorname">"Access Denied" + </span> message.</p><p>The first thing to note is that the <span class="guibutton">"Add"</span> + button will not return a list of users in Samba (it will give + an error message of <span class="errorname">The remote procedure call failed + and did not execute</span>). This means that you can only + manipulate the current user/group/world permissions listed in + the dialog box. This actually works quite well as these are the + only permissions that UNIX actually has.</p><p>If a permission triplet (either user, group, or world) + is removed from the list of permissions in the NT dialog box, + then when the <span class="guibutton">OK</span> button is pressed it will + be applied as "no permissions" on the UNIX side. If you then + view the permissions again the "no permissions" entry will appear + as the NT <b class="command">"O"</b> flag, as described above. This + allows you to add permissions back to a file or directory once + you have removed them from a triplet component.</p><p>As UNIX supports only the "r", "w" and "x" bits of + an NT ACL then if other NT security attributes such as "Delete + access" are selected then they will be ignored when applied on + the Samba server.</p><p>When setting permissions on a directory the second + set of permissions (in the second set of parentheses) is + by default applied to all files within that directory. If this + is not what you want you must uncheck the <span class="guilabel">Replace + permissions on existing files</span> checkbox in the NT + dialog before clicking <span class="guibutton">OK</span>.</p><p>If you wish to remove all permissions from a + user/group/world component then you may either highlight the + component and click the <span class="guibutton">Remove</span> button, + or set the component to only have the special <tt class="constant">Take + Ownership</tt> permission (displayed as <b class="command">"O" + </b>) highlighted.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2907296"></a>Interaction with the standard Samba create mask + parameters</h3></div></div><div></div></div><p>There are four parameters + to control interaction with the standard Samba create mask parameters. + These are : + + </p><div class="itemizedlist"><ul type="disc"><li><p><a class="indexterm" name="id2907315"></a><i class="parameter"><tt>security mask</tt></i></p></li><li><p><a class="indexterm" name="id2907333"></a><i class="parameter"><tt>force security mode</tt></i></p></li><li><p><a class="indexterm" name="id2907350"></a><i class="parameter"><tt>directory security mask</tt></i></p></li><li><p><a class="indexterm" name="id2907367"></a><i class="parameter"><tt>force directory security mode</tt></i></p></li></ul></div><p> + + </p><p>Once a user clicks <span class="guibutton">OK</span> to apply the + permissions Samba maps the given permissions into a user/group/world + r/w/x triplet set, and then will check the changed permissions for a + file against the bits set in the + <a class="indexterm" name="id2907397"></a><i class="parameter"><tt>security mask</tt></i> parameter. Any bits that + were changed that are not set to '1' in this parameter are left alone + in the file permissions.</p><p>Essentially, zero bits in the <a class="indexterm" name="id2907418"></a><i class="parameter"><tt>security mask</tt></i> + mask may be treated as a set of bits the user is <span class="emphasis"><em>not</em></span> + allowed to change, and one bits are those the user is allowed to change. + </p><p>If not set explicitly this parameter is set to the same value as + the <a class="indexterm" name="id2907443"></a><i class="parameter"><tt>create mask</tt></i> parameter. To allow a user to modify all the + user/group/world permissions on a file, set this parameter + to 0777.</p><p>Next Samba checks the changed permissions for a file against + the bits set in the + <a class="indexterm" name="id2907465"></a><i class="parameter"><tt>force security mode</tt></i> parameter. Any bits + that were changed that correspond to bits set to '1' in this parameter + are forced to be set.</p><p>Essentially, bits set in the <i class="parameter"><tt>force security mode + </tt></i> parameter may be treated as a set of bits that, when + modifying security on a file, the user has always set to be 'on'.</p><p>If not set explicitly this parameter is set to the same value + as the <a class="indexterm" name="id2907500"></a><i class="parameter"><tt>force create mode</tt></i> parameter. + To allow a user to modify all the user/group/world permissions on a file + with no restrictions set this parameter to 000.</p><p>The <a class="indexterm" name="id2907521"></a><i class="parameter"><tt>security mask</tt></i> and <i class="parameter"><tt>force + security mode</tt></i> parameters are applied to the change + request in that order.</p><p>For a directory Samba will perform the same operations as + described above for a file except using the parameter <i class="parameter"><tt> + directory security mask</tt></i> instead of <i class="parameter"><tt>security + mask</tt></i>, and <i class="parameter"><tt>force directory security mode + </tt></i> parameter instead of <i class="parameter"><tt>force security mode + </tt></i>.</p><p>The <a class="indexterm" name="id2907582"></a><i class="parameter"><tt>directory security mask</tt></i> parameter + by default is set to the same value as the <i class="parameter"><tt>directory mask + </tt></i> parameter and the <i class="parameter"><tt>force directory security + mode</tt></i> parameter by default is set to the same value as + the <a class="indexterm" name="id2907613"></a><i class="parameter"><tt>force directory mode</tt></i> parameter. </p><p>In this way Samba enforces the permission restrictions that + an administrator can set on a Samba share, whilst still allowing users + to modify the permission bits within that restriction.</p><p>If you want to set up a share that allows users full control + in modifying the permission bits on their files and directories and + doesn't force any particular bits to be set 'on', then set the following + parameters in the <tt class="filename">smb.conf</tt> file in that share specific section : + </p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>security mask = 0777</tt></i></td></tr><tr><td><i class="parameter"><tt>force security mode = 0</tt></i></td></tr><tr><td><i class="parameter"><tt>directory security mask = 0777</tt></i></td></tr><tr><td><i class="parameter"><tt>force directory security mode = 0</tt></i></td></tr></table></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2907693"></a>Interaction with the standard Samba file attribute mapping</h3></div></div><div></div></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Samba maps some of the DOS attribute bits (such as "read + only") into the UNIX permissions of a file. This means there can + be a conflict between the permission bits set via the security + dialog and the permission bits set by the file attribute mapping. + </p></div><p>One way this can show up is if a file has no UNIX read access + for the owner it will show up as "read only" in the standard + file attributes tabbed dialog. Unfortunately this dialog is + the same one that contains the security info in another tab.</p><p>What this can mean is that if the owner changes the permissions + to allow themselves read access using the security dialog, clicks + <span class="guibutton">OK</span> to get back to the standard attributes tab + dialog, and then clicks <span class="guibutton">OK</span> on that dialog, then + NT will set the file permissions back to read-only (as that is what + the attributes still say in the dialog). This means that after setting + permissions and clicking <span class="guibutton">OK</span> to get back to the + attributes dialog you should always hit <span class="guibutton">Cancel</span> + rather than <span class="guibutton">OK</span> to ensure that your changes + are not overridden.</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2907788"></a>Common Errors</h2></div></div><div></div></div><p> +File, Directory and Share access problems are very common on the mailing list. The following +are examples taken from the mailing list in recent times. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2907802"></a>Users can not write to a public share</h3></div></div><div></div></div><p> + “<span class="quote"> + We are facing some troubles with file / directory permissions. I can log on the domain as admin user(root), + and there's a public share, on which everyone needs to have permission to create / modify files, but only + root can change the file, no one else can. We need to constantly go to server to + <b class="userinput"><tt>chgrp -R users *</tt></b> and <b class="userinput"><tt>chown -R nobody *</tt></b> to allow others users to change the file. + </span>” + </p><p> + There are many ways to solve this problem, here are a few hints: + </p><div class="procedure"><ol type="1"><li><p> + Go to the top of the directory that is shared + </p></li><li><p> + Set the ownership to what ever public owner and group you want +</p><pre class="screen"> +<tt class="prompt">$ </tt>find 'directory_name' -type d -exec chown user.group {}\; +<tt class="prompt">$ </tt>find 'directory_name' -type d -exec chmod 6775 'directory_name' +<tt class="prompt">$ </tt>find 'directory_name' -type f -exec chmod 0775 {} \; +<tt class="prompt">$ </tt>find 'directory_name' -type f -exec chown user.group {}\; +</pre><p> + </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> + The above will set the 'sticky bit' on all directories. Read your + UNIX/Linux man page on what that does. It causes the OS to assign + to all files created in the directories the ownership of the + directory. + </p></div></li><li><p> + + Directory is: <i class="replaceable"><tt>/foodbar</tt></i> +</p><pre class="screen"> +<tt class="prompt">$ </tt><b class="userinput"><tt>chown jack.engr /foodbar</tt></b> +</pre><p> + </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This is the same as doing:</p><pre class="screen"> +<tt class="prompt">$ </tt><b class="userinput"><tt>chown jack /foodbar</tt></b> +<tt class="prompt">$ </tt><b class="userinput"><tt>chgrp engr /foodbar</tt></b> +</pre></div></li><li><p>Now do: + +</p><pre class="screen"> +<tt class="prompt">$ </tt><b class="userinput"><tt>chmod 6775 /foodbar</tt></b> +<tt class="prompt">$ </tt><b class="userinput"><tt>ls -al /foodbar/..</tt></b> +</pre><p> + + </p><p>You should see: +</p><pre class="screen"> +drwsrwsr-x 2 jack engr 48 2003-02-04 09:55 foodbar +</pre><p> + </p></li><li><p>Now do: +</p><pre class="screen"> +<tt class="prompt">$ </tt><b class="userinput"><tt>su - jill</tt></b> +<tt class="prompt">$ </tt><b class="userinput"><tt>cd /foodbar</tt></b> +<tt class="prompt">$ </tt><b class="userinput"><tt>touch Afile</tt></b> +<tt class="prompt">$ </tt><b class="userinput"><tt>ls -al</tt></b> +</pre><p> + </p><p> + You should see that the file <tt class="filename">Afile</tt> created by Jill will have ownership + and permissions of Jack, as follows: +</p><pre class="screen"> +-rw-r--r-- 1 jack engr 0 2003-02-04 09:57 Afile +</pre><p> + </p></li><li><p> + Now in your <tt class="filename">smb.conf</tt> for the share add: + </p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>force create mode = 0775</tt></i></td></tr><tr><td><i class="parameter"><tt>force direcrtory mode = 6775</tt></i></td></tr></table><p> + </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> + The above are only needed <span class="emphasis"><em>if</em></span> your users are <span class="emphasis"><em>not</em></span> members of the group + you have used. ie: Within the OS do not have write permission on the directory. + </p></div><p> + An alternative is to set in the <tt class="filename">smb.conf</tt> entry for the share: + </p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>force user = jack</tt></i></td></tr><tr><td><i class="parameter"><tt>force group = engr</tt></i></td></tr></table><p> + </p></li></ol></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2908232"></a>I have set force user but Samba still makes <span class="emphasis"><em>root</em></span> the owner of all the files I touch!</h3></div></div><div></div></div><p> + When you have a user in <a class="indexterm" name="id2908248"></a><i class="parameter"><tt>admin users</tt></i>, samba will always do file operations for + this user as <span class="emphasis"><em>root</em></span>, even if <a class="indexterm" name="id2908268"></a><i class="parameter"><tt>force user</tt></i> has been set. + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2908284"></a>MS Word with Samba changes owner of file</h3></div></div><div></div></div><p> + <span class="emphasis"><em>Question:</em></span> “<span class="quote">When userB saves a word document that is owned by userA the updated file is now owned by userB. + Why is Samba doing this? How do I fix this?</span>” + </p><p> + <span class="emphasis"><em>Answer:</em></span> Word does the following when you modify/change a Word document: Word Creates a NEW document with + a temporary name, Word then closes the old document and deletes it, Word then renames the new document to the original document name. + There is NO mechanism by which Samba CAN IN ANY WAY know that the new document really should be owned by the owners + of the original file. Samba has no way of knowing that the file will be renamed by MS Word. As far as Samba is able + to tell, the file that gets created is a NEW file, not one that the application (Word) is updating. + </p><p> + There is a work-around to solve the permissions problem. That work-around involves understanding how you can manage file + system behaviour from within the <tt class="filename">smb.conf</tt> file, as well as understanding how Unix file systems work. Set on the directory + in which you are changing word documents: <b class="command">chmod g+s 'directory_name'</b> This ensures that all files will + be created with the group that owns the directory. In smb.conf share declaration section set: + </p><p> + </p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>force create mode = 0660</tt></i></td></tr><tr><td><i class="parameter"><tt>force directory mode = 0770</tt></i></td></tr></table><p> + </p><p> + These two settings will ensure that all directories and files that get created in the share will be read/writable by the + owner and group set on the directory itself. + </p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="groupmapping.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="locking.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 12. Mapping MS Windows and UNIX Groups </td><td width="20%" align="center"><a accesskey="h" href="samba-doc.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 14. File and Record Locking</td></tr></table></div></body></html> |