Add all the source files from the old CVS tree,

add the 5 missing chapters from the HOWTO
and add jht's Samba by Example book.
(This used to be commit 9fb5bcb93e57c5162b3ee6f9c7d777dc0269d100)

1 files changed, 1309 insertions, 0 deletions

diff --git a/docs/howto/AccessControls.xml b/docs/howto/AccessControls.xml
new file mode 100644
index 0000000000..13228b7ff0
--- /dev/null
+++ b/docs/howto/AccessControls.xml
@@ -0,0 +1,1309 @@
+<chapter id="AccessControls">
+<chapterinfo>
+	&author.jht;
+	&author.jeremy;
+	<author>&person.jelmer;<contrib>drawing</contrib></author>
+	<pubdate>May 10, 2003</pubdate>
+</chapterinfo>
+<title>File, Directory and Share Access Controls</title>
+
+<para>
+<indexterm><primary>ACLs</primary></indexterm>
+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 unauthorized access.
+</para>
+
+<para>
+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. 
+</para>
+
+<para>
+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 cannot completely hide, even
+though it does try to bridge the chasm to a degree.
+</para>
+
+<para>
+<indexterm><primary>Extended Attributes</primary></indexterm>
+<indexterm><primary>ACLs</primary><secondary>POSIX</secondary></indexterm>
+
+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.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+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 to 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.
+</para>
+
+<sect1>
+<title>Features and Benefits</title>
+
+	<para>
+	Samba offers a lot of flexibility in file system access management. These are the key access control
+	facilities present in Samba today:
+	</para>
+
+	<itemizedlist>
+	<title>Samba Access Control Facilities</title>
+		<listitem><para>
+				<indexterm><primary>permissions</primary><secondary>UNIX file and directory</secondary></indexterm>
+		<emphasis>UNIX File and Directory Permissions</emphasis>
+		</para>
+
+			<para>
+			Samba honors 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.
+			</para>
+		</listitem>
+
+		<listitem><para>
+		<emphasis>Samba Share Definitions</emphasis>
+		</para>
+
+			<para>
+			In configuring share settings and controls in the &smb.conf; file,
+			the network administrator can exercise overrides to native file
+			system permissions and behaviors. This can be handy and convenient
+			to effect behavior that is more like what MS Windows NT users expect
+			but it is seldom the <emphasis>best</emphasis> way to achieve this.
+			The basic options and techniques are described herein.
+			</para>
+		</listitem>
+
+		<listitem><para>
+		<emphasis>Samba Share ACLs</emphasis>
+		<indexterm><primary>ACLs</primary><secondary>share</secondary></indexterm>
+		</para>
+
+			<para>
+			Just like it is possible in MS Windows NT to set ACLs on shares
+			themselves, so it is possible to do this in Samba.
+			Few people make use of this facility, yet it remains one of the
+			easiest ways to affect access controls (restrictions) and can often
+			do so with minimum invasiveness compared with other methods.
+			</para>
+		</listitem>
+
+		<listitem><para>
+				<indexterm><primary>ACLs</primary><secondary>POSIX</secondary></indexterm>
+				<indexterm><primary>ACLs</primary><secondary>Windows</secondary></indexterm>
+		<emphasis>MS Windows ACLs through UNIX POSIX ACLs</emphasis>
+		</para>
+
+			<para>
+			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 also provide
+			this. 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.
+			</para>
+		</listitem>
+	</itemizedlist>
+
+</sect1>
+
+<sect1>
+<title>File System Access Controls</title>
+
+<para>
+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. First we consider what the most significant differences are, then we look
+at how Samba helps to bridge the differences.
+</para>
+
+	<sect2>
+	<title>MS Windows NTFS Comparison with UNIX File Systems</title>
+
+	<para>
+<indexterm><primary>NTFS</primary></indexterm>
+<indexterm><primary>File System</primary></indexterm>
+<indexterm><primary>File System</primary><secondary>UNIX</secondary></indexterm>
+<indexterm><primary>File System</primary><secondary>Windows</secondary></indexterm>
+
+	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
+	behavior that differs from UNIX file system behavior then somehow Samba is responsible for emulating
+	that in a transparent and consistent manner.
+	</para>
+
+	<para>
+	It is good news that Samba does this to a large extent and on top of that provides a high degree
+	of optional configuration to override the default behavior. We look at some of these over-rides,
+	but for the greater part we will stay within the bounds of default behavior. Those wishing to explore
+	the depths of control ability should review the &smb.conf; man page.
+	</para>
+
+	<para>The following compares file system features for UNIX with those of Microsoft Windows NT/200x:
+	<indexterm><primary>File System</primary><secondary>feature comparison</secondary></indexterm>
+	
+	</para>
+
+	<variablelist>
+		<varlistentry>
+			<term>Name Space</term>
+			<listitem>
+		<para>
+		MS Windows NT4/200x/XP files names may be up to 254 characters long, and 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. 
+		</para>
+		<para>
+		What MS Windows calls a folder, UNIX calls a directory.
+		</para>
+			</listitem>
+		</varlistentry>
+
+		<varlistentry>
+			<term>Case Sensitivity</term>
+			<listitem>
+		<para>
+		<indexterm><primary>8.3 file names</primary></indexterm>
+		<indexterm><primary>File System</primary><secondary>case sensitivity</secondary></indexterm>
+		MS Windows file names are generally upper case if made up of 8.3 (8 character file name
+		and 3 character extension. File names that are longer than 8.3 are case preserving and case
+		insensitive.
+		</para>
+
+		<para>
+		UNIX file and directory names are case sensitive and case preserving. Samba implements the
+		MS Windows file name behavior, 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.
+		</para>
+		<para>
+		Consider the following. All are unique UNIX names but one single MS Windows file name:
+		<screen>
+				MYFILE.TXT
+				MyFile.txt
+				myfile.txt
+		</screen></para>
+
+		<para>
+		So clearly, in an MS Windows file name space these three files cannot co-exist, but in UNIX
+		they can.
+		</para>
+		<para>
+		So what should Samba do if all three are present? That which is lexically first will be
+		accessible to MS Windows users, the others are invisible and unaccessible &smbmdash; any
+		other solution would be suicidal.
+		</para>
+			</listitem>
+		</varlistentry>
+
+		<varlistentry>
+			<term>Directory Separators</term>
+			<listitem>
+
+		<para>
+				<indexterm><primary>Directory Separators</primary></indexterm>
+		MS Windows and DOS uses the backslash <constant>\</constant> as a directory delimiter, and UNIX uses
+		the forward-slash <constant>/</constant> as its directory delimiter. This is handled transparently by Samba.
+		</para>
+			</listitem>
+		</varlistentry>
+
+		<varlistentry>
+			<term>Drive Identification</term>
+			<listitem>
+		<para>
+			<indexterm><primary>Drive Identification</primary></indexterm>
+		MS Windows products support a notion of drive letters, like <command>C:</command> to represent
+		disk partitions. UNIX has no concept of separate identifiers for file partitions, each
+		such file system is mounted to become part of the overall directory tree.
+		The UNIX directory tree begins at <constant>/</constant> just like the root of a DOS drive is specified as
+		<constant>C:\</constant>.
+		</para>
+			</listitem>
+		</varlistentry>
+
+		<varlistentry>
+			<term>File Naming Conventions</term>
+			<listitem>
+		<para>
+			<indexterm><primary>File Naming Conventions</primary></indexterm>
+		MS Windows generally never experiences file names that begin with a dot (<constant>.</constant>) while in UNIX these
+		are commonly found in a user's home directory. Files that begin with a dot (<constant>.</constant>) are typically
+		either start-up files for various UNIX applications, or they may be files that contain
+		start-up configuration data.
+		</para>
+			</listitem>
+		</varlistentry>
+
+		<varlistentry>
+			<term>Links and Short-Cuts</term>
+			<listitem>
+		<para>
+		<indexterm><primary>Links</primary><secondary>hard</secondary></indexterm>
+		<indexterm><primary>Links</primary><secondary>soft</secondary></indexterm>
+		<indexterm><primary>Short-Cuts</primary></indexterm>
+		MS Windows make use of <quote>links and short-cuts</quote> 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.
+		</para>
+		<para>
+		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 <quote>soft links.</quote> 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.
+		</para>
+			</listitem>
+		</varlistentry>
+	</variablelist>
+
+	<para>
+	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 and education.
+	</para>
+
+	</sect2>
+
+	<sect2>
+	<title>Managing Directories</title>
+
+	<para>
+	There are three basic operations for managing directories: <command>create, delete, rename</command>.
+	<table frame="all">
+		<title>Managing Directories with UNIX and Windows</title>
+		<tgroup align="center" cols="3">
+		<thead>
+		<row><entry>Action</entry><entry>MS Windows Command</entry><entry>UNIX Command</entry></row>
+		</thead>
+	
+		<tbody>
+			<row><entry>create</entry><entry>md folder</entry><entry>mkdir folder</entry></row>
+			<row><entry>delete</entry><entry>rd folder</entry><entry>rmdir folder</entry></row>
+			<row><entry>rename</entry><entry>rename oldname newname</entry><entry>mv oldname newname</entry></row>
+		</tbody>
+	</tgroup>
+	</table>
+	</para>
+
+	</sect2>
+
+	<sect2>
+	<title>File and Directory Access Control</title>
+
+
+	<para>
+	<indexterm><primary>ACLs</primary><secondary>File System</secondary></indexterm>
+	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).
+	</para>
+
+	<para>
+	UNIX/Linux file and directory access permissions involves setting three primary sets of data and one control set.
+	A UNIX file listing looks as follows:
+<screen>
+&prompt;<userinput>ls -la</userinput>
+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
+&prompt;
+</screen>
+	</para>
+
+	<para>
+	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.
+	</para>
+
+	<para>
+	An overview of the permissions field can be found in <link linkend="access1">Overview of UNIX permissions field</link>.
+	</para>
+
+	<image id="access1" scale="40"><imagedescription>Overview of UNIX permissions field.</imagedescription><imagefile>access1</imagefile></image>
+
+	<para>
+	Any bit flag may be unset. An unset bit flag is the equivalent of <quote>cannot</quote> and is represented as a <quote>-</quote> character.
+
+	<example>
+		<title>Example File</title>
+		<programlisting>
+		-rwxr-x---   Means: The owner (user) can read, write, execute
+		                    the group can read and execute
+		                    everyone else cannot do anything with it.
+		</programlisting>
+	</example>
+
+	</para>
+
+	<para>
+	Additional possibilities in the [type] field are: c = character device, b = block device, p = pipe device, s = UNIX Domain Socket.
+	</para>
+
+	<para>
+	The letters <constant>rwxXst</constant> 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).
+	</para>
+
+	<para>
+	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 <filename>/tmp</filename>, that are world-writable.
+	</para>
+
+	<para>
+	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 helpful in setting up directories 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 whose primary group is not the group that all such users belong to.
+	</para>
+
+	<para>
+	When a directory is set <constant>d-wx--x---</constant> this means that the owner can read and create (write) files in it, but because
+	the (r) read flags are not set, files cannot be listed (seen) in the directory by anyone. The group can read files in the
+	directory but cannot create new files. 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.
+	</para>
+
+	</sect2>
+
+</sect1>
+
+<sect1>
+<title>Share Definition Access Controls</title>
+
+
+<para>
+<indexterm><primary>permissions</primary><secondary>share</secondary></indexterm>
+The following parameters in the &smb.conf; file sections define a share control or effect access controls.
+Before using any of the following options, please refer to the man page for &smb.conf;.
+</para>
+
+	<sect2>
+	<title>User and Group-Based Controls</title>
+
+	<para>
+	User and group-based controls can prove quite useful. In some situations it is distinctly desirable to affect all
+	file system operations as if a single user were doing so. The use of the <smbconfoption><name>force user</name></smbconfoption> and 
+	<smbconfoption><name>force group</name></smbconfoption> behavior will achieve this. In other situations it may be necessary to effect a
+	paranoia level of control to ensure that only particular authorized persons will be able to access a share or
+	its contents. Here the use of the <smbconfoption><name>valid users</name></smbconfoption> or the
+	<smbconfoption><name>invalid users</name></smbconfoption> may be most useful.
+	</para>
+
+	<para>
+	As always, it is highly advisable to use the least difficult to maintain and the least ambiguous method for
+	controlling access. Remember, when you leave the scene someone else will need to provide assistance and
+	if he finds too great a mess or does not understand what you have done, there is risk of
+	Samba being removed and an alternative solution being adopted.
+	</para>
+
+	<para>
+	<link linkend="ugbc">Following table</link> enumerates these controls.
+	</para>
+
+	<table frame='all' pgwide='0' id="ugbc"><title>User and Group Based Controls</title>
+	<tgroup cols='2'>
+		<colspec align="left"/>
+		<colspec align="justify" colwidth="1*"/>
+		<thead>
+		<row>
+			<entry align="center">Control Parameter</entry>
+			<entry align="center">Description - Action - Notes</entry>
+		</row>
+		</thead>
+		<tbody>
+		<row>
+			<entry><smbconfoption><name>admin users</name></smbconfoption></entry>
+			<entry><para>
+			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.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>force group</name></smbconfoption></entry>
+			<entry><para>
+			Specifies a UNIX group name that will be assigned as the default primary group
+			for all users connecting to this service.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>force user</name></smbconfoption></entry>
+			<entry><para>
+			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.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>guest ok</name></smbconfoption></entry>
+			<entry><para>
+			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.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>invalid users</name></smbconfoption></entry>
+			<entry><para>
+			List of users that should not be allowed to login to this service.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>only user</name></smbconfoption></entry>
+			<entry><para>
+			Controls whether connections with usernames not in the user list will be allowed.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>read list</name></smbconfoption></entry>
+			<entry><para>
+			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. 
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>username</name></smbconfoption></entry>
+			<entry><para>
+			Refer to the &smb.conf; man page for more information -- this is a complex and potentially misused parameter.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>valid users</name></smbconfoption></entry>
+			<entry><para>
+			List of users that should be allowed to login to this service.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>write list</name></smbconfoption></entry>
+			<entry><para>
+			List of users that are given read-write access to a service.
+			</para></entry>
+		</row>
+		</tbody>
+	</tgroup>
+	</table>
+
+	</sect2>
+
+	<sect2>
+	<title>File and Directory Permissions-Based Controls</title>
+
+	<para>
+	The following file and directory permission-based controls, if misused, can result in considerable difficulty to
+	diagnose causes of misconfiguration. 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
+	reintroduce them in a controlled way.
+	</para>
+
+	<para>
+	Refer to <link linkend="fdpbc">the following table</link> for information regarding the parameters that may be used to affect file and
+	directory permission-based access controls.
+	</para>
+
+	<table frame='all' id="fdpbc"><title>File and Directory Permission Based Controls</title>
+		<tgroup cols='2'>
+			<colspec align="left"/>
+			<colspec align="justify" colwidth="1*"/>
+		<thead>
+		<row>
+			<entry align="center">Control Parameter</entry>
+			<entry align="center">Description - Action - Notes</entry>
+		</row>
+		</thead>
+		<tbody>
+		<row>
+			<entry><smbconfoption><name>create mask</name></smbconfoption></entry>
+			<entry><para>
+			Refer to the &smb.conf; man page.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>directory mask</name></smbconfoption></entry>
+			<entry><para>
+			The octal modes used when converting DOS modes to UNIX modes when creating UNIX directories.
+			See also: directory security mask.
+			</para></entry></row>
+		<row>
+			<entry><smbconfoption><name>dos filemode</name></smbconfoption></entry>
+			<entry><para>
+			Enabling this parameter allows a user who has write access to the file to modify the permissions on it.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>force create mode</name></smbconfoption></entry>
+			<entry><para>
+			This parameter specifies a set of UNIX mode bit permissions that will always be set on a file created by Samba.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>force directory mode</name></smbconfoption></entry>
+			<entry><para>
+			This parameter specifies a set of UNIX mode bit permissions that will always be set on a directory created by Samba.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>force directory security mode</name></smbconfoption></entry>
+			<entry><para>
+			Controls UNIX permission bits modified when a Windows NT client is manipulating UNIX permissions on a directory.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>force security mode</name></smbconfoption></entry>
+			<entry><para>
+			Controls UNIX permission bits modified when a Windows NT client manipulates UNIX permissions.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>hide unreadable</name></smbconfoption></entry>
+			<entry><para>
+			Prevents clients from seeing the existence of files that cannot be read.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>hide unwriteable files</name></smbconfoption></entry>
+			<entry><para>
+			Prevents clients from seeing the existence of files that cannot be written to. Unwriteable directories are shown as usual. 
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>nt acl support</name></smbconfoption></entry>
+			<entry><para>
+			This parameter controls whether smbd will attempt to map UNIX permissions into Windows NT access control lists.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>security mask</name></smbconfoption></entry>
+			<entry><para>
+			Controls UNIX permission bits modified when a Windows NT client is manipulating the UNIX permissions on a file.
+			</para></entry>
+		</row>
+		</tbody>
+	</tgroup>
+	</table>
+
+	</sect2>
+
+	<sect2>
+	<title>Miscellaneous Controls</title>
+
+	<para>
+	The following are documented because of the prevalence of administrators creating inadvertent barriers to file
+	access by not understanding the full implications of &smb.conf; file settings. See <link linkend="mcoc">following table</link>.
+	</para>
+
+	<table frame='all' id="mcoc"><title>Other Controls</title>
+	<tgroup cols='2'>
+		<colspec align="justify" colwidth="1*"/>
+		<colspec align="justify" colwidth="1*"/>
+		<thead>
+		<row>
+			<entry align="center">Control Parameter</entry>
+			<entry align="center">Description - Action - Notes</entry>
+		</row>
+		</thead>
+		<tbody>
+		<row>
+			<entry><smbconfoption><name>case sensitive</name></smbconfoption>, <smbconfoption><name>default case</name></smbconfoption>, <smbconfoption><name>short preserve case</name></smbconfoption></entry>
+			<entry><para>
+			This means that all file name lookup will be done in a case sensitive manner. 
+			Files will be created with the precise file name Samba received from the MS Windows client.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>csc policy</name></smbconfoption></entry>
+			<entry><para>
+			Client Side Caching Policy - parallels MS Windows client side file caching capabilities.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>dont descend</name></smbconfoption></entry>
+			<entry><para>
+			Allows specifying a comma-delimited list of directories that the server should always show as empty.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>dos filetime resolution</name></smbconfoption></entry>
+			<entry><para>
+			This option is mainly used as a compatibility option for Visual C++ when used against Samba shares.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>dos filetimes</name></smbconfoption></entry>
+			<entry><para>
+			DOS and Windows allow users to change file time stamps if they can write to the file. POSIX semantics prevent this.
+			This option allows DOS and Windows behavior.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>fake oplocks</name></smbconfoption></entry>
+			<entry><para>
+			Oplocks are the way that SMB clients get permission from a server to locally cache file operations. If a server grants an
+			oplock, the client is free to assume that it is the only one accessing the file and it will aggressively cache file data.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>hide dot files</name></smbconfoption>, <smbconfoption><name>hide files</name></smbconfoption>, <smbconfoption><name>veto files</name></smbconfoption></entry>
+			<entry><para>
+			Note: MS Windows Explorer allows over-ride of files marked as hidden so they will still be visible.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>read only</name></smbconfoption></entry>
+			<entry><para>
+			If this parameter is yes, then users of a service may not create or modify files in the service's directory.
+			</para></entry>
+		</row>
+		<row>
+			<entry><smbconfoption><name>veto files</name></smbconfoption></entry>
+			<entry><para>
+			List of files and directories that are neither visible nor accessible.
+			</para></entry>
+		</row>
+		</tbody>
+	</tgroup>
+	</table>
+
+	</sect2>
+
+</sect1>
+
+<sect1>
+<title>Access Controls on Shares</title>
+
+
+	<para>
+<indexterm><primary>permissions</primary><secondary>share ACLs</secondary></indexterm>
+	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 an 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 <constant>Everyone - Full Control</constant> (full control, change and read).
+	</para>
+
+	<para>
+	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.
+	</para>
+
+	<para>
+	Samba stores the per share access control settings in a file called <filename>share_info.tdb</filename>.
+	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 <filename>/usr/local/samba/var</filename>. If the <filename>tdbdump</filename>
+	utility has been compiled and installed on your system, then you can examine the contents of this file
+	by executing: <command>tdbdump share_info.tdb</command> in the directory containing the tdb files.
+	</para>
+
+	<sect2>
+	<title>Share Permissions Management</title>
+
+		<para>
+		The best tool for the task is platform dependant. Choose the best tool for your environment.
+		</para>
+
+			<sect3>
+			<title>Windows NT4 Workstation/Server</title>
+			<para>
+			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 &smbmdash; see details below.
+			</para>
+
+			<?latex \newpage ?>
+
+			<procedure>
+			<title>Instructions</title>
+			<step><para>
+			Launch the <application>NT4 Server Manager</application>, click on the Samba server you want to administer. From the menu
+			select <guimenu>Computer</guimenu>, then click on <guimenuitem>Shared Directories</guimenuitem>.
+			</para></step>
+
+			<step><para>
+			Click on the share that you wish to manage, then click the <guilabel>Properties</guilabel> tab. then click
+			the <guilabel>Permissions</guilabel> tab. Now you can add or change access control settings as you wish.
+			</para></step>
+			</procedure>
+
+			</sect3>
+
+			<sect3>
+			<title>Windows 200x/XP</title>
+
+			<para>
+			On <application>MS Windows NT4/200x/XP</application> 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 <guimenuitem>Sharing</guimenuitem>, then click on <guilabel>Permissions</guilabel>. The default 
+			Windows NT4/200x permission allows <quote>Everyone</quote> full control on the share.
+			</para>
+
+			<para>
+			MS Windows 200x and later versions come with a tool called the <application>Computer Management</application> snap-in for the
+			Microsoft Management Console (MMC). This tool is located by clicking on <guimenu>Control Panel ->
+			Administrative Tools -> Computer Management</guimenu>.
+			</para>
+
+			<procedure>
+			<title>Instructions</title>
+			<step><para>
+			After launching the MMC with the Computer Management snap-in, click the menu item <guimenuitem>Action</guimenuitem>,
+			and select <guilabel>Connect to another computer</guilabel>. 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 are already logged in with administrative privilege, this step is not offered.
+			</para></step>
+
+			<step><para>
+			If the Samba server is not shown in the <guilabel>Select Computer</guilabel> box, type in the name of the target
+			Samba server in the field <guilabel>Name:</guilabel>. Now click the on <guibutton>[+]</guibutton> next to 
+			<guilabel>System Tools</guilabel>, then on the <guibutton>[+]</guibutton> next to <guilabel>Shared Folders</guilabel> in the 
+			left panel.
+			</para></step>
+
+			<step><para>
+			In the right panel, double-click on the share on which you wish to set access control permissions.
+			Then click the tab <guilabel>Share Permissions</guilabel>. It is now possible to add access control entities
+			to the shared folder. Remember to set what type of access (full control, change, read) you
+			wish to assign for each entry.
+			</para></step>
+			</procedure>
+
+			<warning>
+			<para>
+			Be careful. If you take away all permissions from the <constant>Everyone</constant> user without removing this user,
+			effectively no user will be able to access the share. This is a result of what is known as
+			ACL precedence. Everyone with <emphasis>no access</emphasis> means that <constant>MaryK</constant> who is part of the group 
+			<constant>Everyone</constant> will have no access even if she is given explicit full control access.
+			</para>
+			</warning>
+
+			</sect3>
+		</sect2>
+
+</sect1>
+
+<sect1>
+<title>MS Windows Access Control Lists and UNIX Interoperability</title>
+
+	<sect2>
+		<title>Managing UNIX Permissions Using NT Security Dialogs</title>
+
+
+		<para>
+<indexterm><primary>permissions</primary><secondary>file/directory ACLs</secondary></indexterm>
+		Windows NT clients can use their native security settings dialog box to view and modify the
+		underlying UNIX permissions.
+		</para>
+
+		<para>
+		This ability is careful not to compromise the security of the UNIX host on which Samba is running, and 
+		still obeys all the file permission rules that a Samba administrator can set.
+		</para>
+
+		<para>
+		Samba does not attempt to go beyond POSIX ACLs, so the various finer-grained access control
+		options provided in Windows are actually ignored.
+		</para> 
+
+		<note>
+		<para>
+		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.
+		</para>
+		</note>
+	</sect2>
+
+	<sect2>
+		<title>Viewing File Security on a Samba Share</title>
+
+		<para>
+		From an NT4/2000/XP client, right click on any file or directory in a Samba-mounted drive letter
+		or UNC path. When the menu pops up, click on the <guilabel>Properties</guilabel> entry at the bottom
+		of the menu. This brings up the file <constant>Properties</constant> dialog box. Click on the 
+		<guilabel>Security</guilabel> tab and you will see three buttons: <guibutton>Permissions</guibutton>,
+		<guibutton>Auditing</guibutton>, and <guibutton>Ownership</guibutton>. The <guibutton>Auditing</guibutton>
+		button will cause either an error message <errorname>`A requested privilege is not held by the client'</errorname>
+		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 <guibutton>Add</guibutton>
+		button, will not currently allow a list of users to be seen.
+		</para>
+
+	</sect2>
+
+	<sect2>
+		<title>Viewing File Ownership</title>
+
+		<para>
+		Clicking on the <guibutton>Ownership</guibutton> button brings up a dialog box telling you who owns
+		the given file. The owner name will be displayed like this:
+		</para>
+
+		<para>
+		<command><quote>SERVER\user (Long name)</quote></command>
+		</para>
+
+		<para>
+		<replaceable>SERVER</replaceable> is the NetBIOS name of the Samba server, <replaceable>user</replaceable>
+		is the user name of the UNIX user who owns the file, and <replaceable>(Long name)</replaceable> is the
+		descriptive string identifying the user (normally found in the GECOS field of the UNIX password database).
+		Click on the <guibutton>Close </guibutton> button to remove this dialog.
+		</para>
+
+		<para>
+		If the parameter <smbconfoption><name>nt acl support</name></smbconfoption> is set to <constant>false</constant>,
+		the file owner will be shown as the NT user <emphasis>Everyone</emphasis>.
+		</para>
+
+		<para>
+		The <guibutton>Take Ownership</guibutton> button will not allow you to change the ownership of this file to
+		yourself (clicking 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 <emphasis>root</emphasis> 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.</para>
+
+		<para>
+		There is an NT <command>chown</command> 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 <application>Seclib</application> NT security library written
+		by Jeremy Allison of the Samba Team, and is available from the main Samba FTP site.</para>
+
+	</sect2>
+
+	<sect2>
+		<title>Viewing File or Directory Permissions</title>
+
+		<para>
+		The third button is the <guibutton>Permissions</guibutton> 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 like this:
+		</para>
+
+		<para><command><replaceable>SERVER</replaceable>\
+				<replaceable>user</replaceable> 
+				<replaceable>(Long name)</replaceable></command></para>
+
+		<para>Where <replaceable>SERVER</replaceable> is the NetBIOS name of the Samba server,
+		<replaceable>user</replaceable> is the user name of the UNIX user who owns the file, and
+		<replaceable>(Long name)</replaceable> is the descriptive string identifying the user (normally found in the
+		GECOS field of the UNIX password database).</para>
+
+		<para>
+		If the parameter <smbconfoption><name>nt acl support</name></smbconfoption> is set to <constant>false</constant>,
+		the file owner will be shown as the NT user <constant>Everyone</constant> and the permissions will be
+		shown as NT <quote>Full Control</quote>.
+		</para>
+
+
+		<para>
+		The permissions field is displayed differently for files and directories, so I'll describe the way file permissions 
+		are displayed first.
+		</para>
+
+		<sect3>
+			<title>File Permissions</title>
+
+			<para>The standard UNIX user/group/world triplet and the corresponding <constant>read, write, execute</constant> permissions 
+			triplets are mapped by Samba into a three element NT ACL with the <quote>r</quote>, <quote>w</quote> and <quote>x</quote> bits mapped into the corresponding 
+			NT permissions. The UNIX world permissions are mapped into the global NT group <constant>Everyone</constant>, followed 
+			by the list of permissions allowed for UNIX world. The UNIX owner and group permissions are displayed as an NT 
+			<guiicon>user</guiicon> icon and an NT <guiicon>local group</guiicon> icon, respectively, followed by the list 
+			of permissions allowed for the UNIX user and group.</para>
+
+			<para>Because many UNIX permission sets do not map into common NT names such as <constant>read</constant>,
+			<constant>change</constant> or <constant>full control</constant>, usually the permissions will be prefixed
+			by the words <constant>Special Access</constant> in the NT display list.</para>
+
+			<para>But what happens if the file has no permissions allowed for a particular UNIX user group or world component? In order 
+			to  allow <quote>no permissions</quote> to be seen and modified Samba then overloads the NT <constant>Take Ownership</constant> ACL attribute 
+			(which has no meaning in UNIX) and reports a component with no permissions as having the NT <command>O</command> bit set. 
+			This was chosen, of course, to make it look like a zero, meaning zero permissions. More details on the decision behind this is 
+			given below.</para>
+		</sect3>
+		
+		<sect3>
+			<title>Directory Permissions</title>
+
+			<para>Directories on an NT NTFS file system have two different sets of permissions. The first set is the ACL set on the
+			directory itself, which is usually displayed in the first set of parentheses in the normal <constant>RW</constant> 
+			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.</para>
+
+			<para>The second set of directory permissions has no real meaning in the UNIX permissions world and represents the <constant>
+			inherited</constant> permissions that any file created within this directory would inherit.</para>
+
+			<para>Samba synthesizes 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.</para>
+		</sect3>
+	</sect2>
+		
+	<sect2>
+		<title>Modifying File or Directory Permissions</title>
+
+		<para>Modifying file and directory permissions is as simple 
+		as changing the displayed permissions in the dialog box, and 
+		clicking on <guibutton>OK</guibutton>. 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.</para>
+
+		<para>If the parameter <smbconfoption><name>nt acl support</name></smbconfoption>
+		is set to <constant>false</constant>, any attempt to set 
+		security permissions will fail with an <errorname>`Access Denied'
+		</errorname> message.</para>
+
+		<para>The first thing to note is that the <guibutton>Add</guibutton> 
+		button will not return a list of users in Samba (it will give 
+		an error message saying <errorname>`The remote procedure call failed 
+		and did not execute'</errorname>). 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.</para>
+
+		<para>If a permission triplet (either user, group, or world) 
+		is removed from the list of permissions in the NT dialog box, 
+		then when the <guibutton>OK</guibutton> button is pressed it will 
+		be applied as <quote>no permissions</quote> on the UNIX side. If you then 
+		view the permissions again, the <quote>no permissions</quote> entry will appear 
+		as the NT <command>O</command> 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.</para>
+
+		<para>As UNIX supports only the <quote>r</quote>, <quote>w</quote> and <quote>x</quote> bits of 
+		an NT ACL, if other NT security attributes such as <constant>Delete Access</constant> are
+		selected they will be ignored when applied on the Samba server.</para>
+
+		<para>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 un-check the <guilabel>Replace 
+		permissions on existing files</guilabel> check-box in the NT 
+		dialog before clicking on <guibutton>OK</guibutton>.</para>
+
+		<para>If you wish to remove all permissions from a 
+		user/group/world  component, you may either highlight the 
+		component and click on the <guibutton>Remove</guibutton> button, 
+		or set the component to only have the special <constant>Take
+		Ownership</constant> permission (displayed as <command>O
+		</command>) highlighted.</para>
+	</sect2>
+
+	<sect2>
+		<title>Interaction with the Standard Samba <quote>create mask</quote> Parameters</title>
+
+		<para>There are four parameters that control interaction with the standard Samba <parameter>create mask</parameter> parameters.
+		These are:
+
+		<itemizedlist>
+			<listitem><smbconfoption><name>security mask</name></smbconfoption></listitem>
+			<listitem><smbconfoption><name>force security mode</name></smbconfoption></listitem>
+			<listitem><smbconfoption><name>directory security mask</name></smbconfoption></listitem>
+			<listitem><smbconfoption><name>force directory security mode</name></smbconfoption></listitem>
+		</itemizedlist>
+
+		</para>
+
+		<para>Once a user clicks on <guibutton>OK</guibutton> to apply the 
+		permissions, Samba maps the given permissions into a user/group/world 
+		r/w/x triplet set, and then checks the changed permissions for a 
+		file against the bits set in the  
+		<smbconfoption><name>security mask</name></smbconfoption> parameter. Any bits that 
+		were changed that are not set to <quote>1</quote> in this parameter are left alone 
+		in the file permissions.</para>
+
+		<para>Essentially, zero bits in the <smbconfoption><name>security mask</name></smbconfoption>
+		may be treated as a set of bits the user is <emphasis>not</emphasis> 
+		allowed to change, and one bits are those the user is allowed to change.
+		</para>
+
+		<para>If not explicitly set, this parameter defaults to the same value as 
+		the <smbconfoption><name>create mask</name></smbconfoption> parameter. To allow a user to modify all the
+		user/group/world permissions on a file, set this parameter to 0777.
+		</para>
+
+		<para>Next Samba checks the changed permissions for a file against the bits set in the 
+		<smbconfoption><name>force security mode</name></smbconfoption> parameter. Any bits 
+		that were changed that correspond to bits set to <quote>1</quote> in this parameter 
+		are forced to be set.</para>
+
+		<para>Essentially, bits set in the <parameter>force security mode</parameter> parameter
+		may be treated as a set of bits that, when modifying security on a file, the user has always set to be <quote>on</quote>.</para>
+
+		<para>If not explicitly set, this parameter defaults to the same value 
+		as the <smbconfoption><name>force create mode</name></smbconfoption> parameter.
+		To allow a user to modify all the user/group/world permissions on a file
+		with no restrictions set this parameter to 000. The
+		<smbconfoption><name>security mask</name></smbconfoption> and <parameter>force 
+		security mode</parameter> parameters are applied to the change 
+		request in that order.</para>
+
+		<para>For a directory, Samba will perform the same operations as 
+		described above for a file except it uses the parameter <parameter>
+		directory security mask</parameter> instead of <parameter>security 
+		mask</parameter>, and <parameter>force directory security mode
+		</parameter> parameter instead of <parameter>force security mode
+		</parameter>.</para>
+
+		<para>The <smbconfoption><name>directory security mask</name></smbconfoption> parameter 
+		by default is set to the same value as the <parameter>directory mask
+		</parameter> parameter and the <parameter>force directory security 
+		mode</parameter> parameter by default is set to the same value as 
+		the <smbconfoption><name>force directory mode</name></smbconfoption> parameter.
+		In this way Samba enforces the permission restrictions that 
+		an administrator can set on a Samba share, while still allowing users 
+		to modify the permission bits within that restriction.</para>
+
+		<para>If you want to set up a share that allows users full control
+		in modifying the permission bits on their files and directories and
+		does not force any particular bits to be set <quote>on</quote>, then set the following
+		parameters in the &smb.conf; file in that share-specific section:
+		</para>
+
+		<smbconfblock>
+			<smbconfoption><name>security mask</name><value>0777</value></smbconfoption>
+			<smbconfoption><name>force security mode</name><value>0</value></smbconfoption>
+			<smbconfoption><name>directory security mask</name><value>0777</value></smbconfoption>
+			<smbconfoption><name>force directory security mode</name><value>0</value></smbconfoption>
+		</smbconfblock>
+	</sect2>
+
+	<sect2>
+		<title>Interaction with the Standard Samba File Attribute Mapping</title>
+
+		<note>
+		<para>Samba maps some of the DOS attribute bits (such as <quote>read 
+		only</quote>) 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.
+		</para>
+		</note>
+
+		<para>If a file has no UNIX read access for the owner, it will show up
+		as <quote>read only</quote> in the standard file attributes tabbed dialog.
+		Unfortunately, this dialog is the same one that contains the security information
+		in another tab.</para>
+
+		<para>What this can mean is that if the owner changes the permissions
+		to allow himself read access using the security dialog, clicks on
+		<guibutton>OK</guibutton> to get back to the standard attributes tab 
+		dialog, and clicks on <guibutton>OK</guibutton> 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 on <guibutton>OK</guibutton> to get back to the 
+		attributes dialog, you should always press <guibutton>Cancel</guibutton> 
+		rather than <guibutton>OK</guibutton> to ensure that your changes 
+		are not overridden.</para>
+	</sect2>
+</sect1>
+
+<sect1>
+<title>Common Errors</title>
+
+<para>
+File, directory and share access problems are common on the mailing list. The following
+are examples taken from the mailing list in recent times.
+</para>
+
+
+	<sect2>
+	<title>Users Cannot Write to a Public Share</title>
+
+	<para>
+	<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 the server to
+	<userinput>chgrp -R users *</userinput> and <userinput>chown -R nobody *</userinput> to allow others users to change the file.
+	</quote>
+	</para>
+
+	<para>
+	There are many ways to solve this problem and here are a few hints:
+	</para>
+
+	<procedure>
+		<step>
+			<para>
+			Go to the top of the directory that is shared.
+			</para>
+		</step>
+
+		<step>
+			<para>
+			Set the ownership to what ever public owner and group you want
+<screen>
+&prompt;find 'directory_name' -type d -exec chown user.group {}\;
+&prompt;find 'directory_name' -type d -exec chmod 1775 'directory_name'
+&prompt;find 'directory_name' -type f -exec chmod 0775 {} \;
+&prompt;find 'directory_name' -type f -exec chown user.group {}\;
+</screen>
+			</para>
+
+			<note><para>
+			The above will set the <constant>sticky bit</constant> 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.
+			</para></note>
+		</step>
+		<step>
+			<para>
+
+			Directory is: <replaceable>/foodbar</replaceable>
+<screen>
+&prompt;<userinput>chown jack.engr /foodbar</userinput>
+</screen>
+			</para>
+
+			<note><para>
+				<para>This is the same as doing:</para>
+<screen>
+&prompt;<userinput>chown jack /foodbar</userinput>
+&prompt;<userinput>chgrp engr /foodbar</userinput>
+</screen>
+			</para></note>
+		</step>
+		<step>
+			<para>Now type: 
+
+<screen>
+&prompt;<userinput>chmod 6775 /foodbar</userinput>
+&prompt;<userinput>ls -al /foodbar/..</userinput>
+</screen>
+
+			</para>
+		
+			<para>You should see:
+<screen>
+drwsrwsr-x  2 jack  engr    48 2003-02-04 09:55 foodbar
+</screen>
+			</para>
+		</step>
+		<step>
+
+		<para>Now type:
+<screen>
+&prompt;<userinput>su - jill</userinput>
+&prompt;<userinput>cd /foodbar</userinput>
+&prompt;<userinput>touch Afile</userinput>
+&prompt;<userinput>ls -al</userinput>
+</screen>
+		</para>
+
+		<para>
+		You should see that the file <filename>Afile</filename> created by Jill will have ownership
+		and permissions of Jack, as follows:
+<screen>
+-rw-r--r--  1 jack  engr     0 2003-02-04 09:57 Afile
+</screen>
+		</para>
+		</step>
+
+		<step>
+		<para>
+		Now in your &smb.conf; for the share add:
+		<smbconfblock>
+<smbconfoption><name>force create mode</name><value>0775</value></smbconfoption>
+<smbconfoption><name>force directory mode</name><value>6775</value></smbconfoption>
+		</smbconfblock>
+		</para>
+
+		<note><para>
+		These procedures are needed only if your users are not members of the group
+		you have used. That is if within the OS do not have write permission on the directory.
+		</para>
+		</note>
+		
+		<para>
+		An alternative is to set in the &smb.conf; entry for the share:
+		<smbconfblock>
+<smbconfoption><name>force user</name><value>jack</value></smbconfoption>
+<smbconfoption><name>force group</name><value>engr</value></smbconfoption>
+		</smbconfblock>
+		</para>
+	</step>
+	</procedure>
+	</sect2>
+
+
+	<sect2>
+		<title>File Operations Done as <emphasis>root</emphasis> with <emphasis>force user</emphasis> Set</title>
+
+		<para>
+		When you have a user in <smbconfoption><name>admin users</name></smbconfoption>, Samba will always do file operations for
+		this user as <emphasis>root</emphasis>, even if <smbconfoption><name>force user</name></smbconfoption> has been set.
+		</para>
+	</sect2>
+	
+	<sect2>
+		<title>MS Word with Samba Changes Owner of File</title>
+
+		<para>
+		<emphasis>Question:</emphasis> <quote>When user B saves a word document that is owned by user A the updated file is now owned by user B.
+		Why is Samba doing this? How do I fix this?</quote>
+		</para>
+
+		<para>
+		<emphasis>Answer:</emphasis> Word does the following when you modify/change a Word document: MS 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.
+		</para>
+
+		<para>
+		There is a work-around to solve the permissions problem. That work-around involves understanding how you can manage file
+		system behavior from within the &smb.conf; file, as well as understanding how UNIX file systems work. Set on the directory
+		in which you are changing Word documents: <command>chmod g+s `directory_name'</command> This ensures that all files will
+		be created with the group that owns the directory. In &smb.conf; share declaration section set:
+		</para>
+
+		<para>
+		<smbconfblock>
+                <smbconfoption><name>force create mode</name><value>0660</value></smbconfoption>
+                <smbconfoption><name>force directory mode</name><value>0770</value></smbconfoption>
+		</smbconfblock>
+		</para>
+
+		<para>
+		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.
+		</para>
+		
+	</sect2>
+
+</sect1>
+
+</chapter>