more updates and autogen

(This used to be commit 2d3429cfe2d19b667400e408a4947efd160d99c0)

4 files changed, 1123 insertions, 309 deletions

diff --git a/docs/docbook/howto/DOMAIN_MEMBER.sgml b/docs/docbook/howto/DOMAIN_MEMBER.sgml
index bdb8fd8635..888b801742 100644
--- a/docs/docbook/howto/DOMAIN_MEMBER.sgml
+++ b/docs/docbook/howto/DOMAIN_MEMBER.sgml
@@ -1,15 +1,10 @@
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
 
-<book>
-
-<bookinfo>
-	<author><firstname>Jeremy</firstname><surname>Allison</surname></author>
-	<pubdate>7th Oct 1999</pubdate>
-</bookinfo>
+<article>
 
 <sect1>
 
-	<title>Joining an NT Domain with Samba 2.2</emphasis></title>
+	<title>Joining an NT Domain with Samba 2.2</title>
 
 	<para>In order for a Samba-2 server to join an NT domain, 
 	you must first add the NetBIOS name of the Samba server to the 
@@ -165,4 +160,4 @@
 	the NIS/NT Samba</ulink>.</para>
 
 </sect1>
-</book>
+</article>
diff --git a/docs/docbook/howto/NT_Security.sgml b/docs/docbook/howto/NT_Security.sgml
new file mode 100644
index 0000000000..62550bfaa6
--- /dev/null
+++ b/docs/docbook/howto/NT_Security.sgml
@@ -0,0 +1,342 @@
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
+
+<article>
+
+
+<sect1>
+	<title>Viewing and changing UNIX permissions using the NT 
+	security dialogs</title>
+
+
+	<para>New in the Samba 2.0.4 release is the ability for Windows 
+	NT clients to use their native security settings dialog box to 
+	view and modify the underlying UNIX permissions.</para>
+
+	<para>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.</para>
+
+	<para>In Samba 2.0.4 and above the default value of the 
+	parameter <ulink url="smb.conf.5.html#NTACLSUPPOR"><parameter>
+	nt acl support</parameter></ulink> has been changed from 
+	<constant>false</constant> to <constant>true</constant>, so 
+ 	manipulation of permissions is turned on by default.</para>
+</sect1>
+
+<sect1>
+	<title>How to view file security on a Samba share</title>
+
+	<para>From an NT 4.0 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 <emphasis>Properties</emphasis> entry at the bottom of 
+	the menu. This brings up the normal file properties dialog
+	box, but with Samba 2.0.4 this will have a new tab along the top
+	marked <emphasis>Security</emphasis>. Click on this tab and you 
+	will see three buttons, <emphasis>Permissions</emphasis>, 	
+	<emphasis>Auditing</emphasis>, and <emphasis>Ownership</emphasis>. 
+	The <emphasis>Auditing</emphasis> 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 <command>Add</command> button will not currently 
+	allow a list of users to be seen.</para>
+
+</sect1>
+<sect1>
+	<title>Viewing file ownership</title>
+
+	<para>Clicking on the <command>"Ownership"</command> button 
+	brings up a dialog box telling you who owns the given file. The 
+	owner name will be of the form :</para>
+
+	<para><command>"SERVER\user (Long name)"</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 discriptive string identifying the user (normally found in the
+	GECOS field of the UNIX password database). Click on the <command>Close
+	</command> button to remove this dialog.</para>
+
+	<para>If the parameter <parameter>nt acl support</parameter>
+	is set to <constant>false</constant> then the file owner will 
+	be shown as the NT user <command>"Everyone"</command>.</para>
+
+	<para>The <command>Take Ownership</command> 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 privilaged 
+	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 chown command that will work with Samba 
+	and allow a user with Administrator privillage connected 
+	to a Samba 2.0.4 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 <emphasis>Seclib
+	</emphasis> NT security library written by Jeremy Allison of 
+	the Samba Team, available from the main Samba ftp site.</para>
+
+</sect1>
+
+<sect1>
+	<title>Viewing file or directory permissions</title>
+
+	<para>The third button is the <command>"Permissions"</command> 
+	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 :</para>
+
+	<para><command>"SERVER\user (Long name)"</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 discriptive string identifying the user (normally found in the
+	GECOS field of the UNIX password database).</para>
+
+	<para>If the parameter <parameter>nt acl support</parameter>
+	is set to <constant>false</constant> then the file owner will 
+	be shown as the NT user <command>"Everyone"</command> and the 
+	permissions will be shown as NT "Full Control".</para>
+
+
+	<para>The permissions field is displayed differently for files 
+	and directories, so I'll describe the way file permissions 
+	are displayed first.</para>
+
+	<sect2>
+		<title>File Permissions</title>
+
+		<para>The standard UNIX user/group/world triple and 
+		the correspinding "read", "write", "execute" permissions 
+		triples 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 <command>Everyone</command>, followed 
+		by the list of permissions allowed for UNIX world. The UNIX 
+		owner and group permissions are displayed as an NT 
+		<command>user</command> icon and an NT <command>local 
+		group</command> icon respectively followed by the list 
+	 	of permissions allowed for the UNIX user and group.</para>
+
+		<para>As many UNIX permission sets don't map into common 
+		NT names such as <command>"read"</command>, <command>
+		"change"</command> or <command>"full control"</command> then 
+		usually the permissions will be prefixed by the words <command>
+		"Special Access"</command> 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 "no permissions" to be seen and modified then Samba 
+		overloads the NT <command>"Take Ownership"</command> 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 will 
+		be given below.</para>
+	</sect2>
+	
+	<sect2>
+		<title>Directory Permissions</title>
+
+		<para>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 <command>"RW"</command> 
+		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 <command>
+		"inherited"</command> permissions that any file created within 
+		this directory would inherit.</para>
+
+		<para>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.</para>
+	</sect2>
+</sect1>
+	
+<sect1>
+	<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 the <command>OK</command> 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.</para>
+
+	<para>If the parameter <parameter>nt acl support</parameter>
+	is set to <constant>false</constant> then any attempt to set 
+	security permissions will fail with an <command>"Access Denied"
+	</command> message.</para>
+
+	<para>The first thing to note is that the <command>"Add"</command> 
+	button will not return a list of users in Samba 2.0.4 (it will give 
+	an error message of <command>"The remote proceedure call failed 
+	and did not execute"</command>). 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 triple (either user, group, or world) 
+	is removed from the list of permissions in the NT dialog box, 
+	then when the <command>"OK"</command> 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 <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 triple component.</para>
+
+	<para>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.</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 uncheck the <command>"Replace 
+	permissions on existing files"</command> checkbox in the NT 
+	dialog before clicking <command>"OK"</command>.</para>
+
+	<para>If you wish to remove all permissions from a 
+	user/group/world  component then you may either highlight the 
+	component and click the <command>"Remove"</command> button, 
+	or set the component to only have the special <command>"Take
+	Ownership"</command> permission (dsplayed as <command>"O"
+	</command>) highlighted.</para>
+</sect1>
+
+<sect1>
+	<title>Interaction with the standard Samba create mask 
+	parameters</title>
+
+	<para>Note that with Samba 2.0.5 there are four new parameters 
+	to control this interaction.  These are :</para>
+
+	<para><parameter>security mask</parameter></para>
+	<para><parameter>force security mode</parameter></para>
+	<para><parameter>directory security mask</parameter></para>
+	<para><parameter>force directory security mode</parameter></para>
+
+	<para>Once a user clicks <command>"OK"</command> to apply the 
+	permissions Samba maps the given permissions into a user/group/world 
+	r/w/x triple set, and then will check the changed permissions for a 
+	file against the bits set in the <ulink url="smb.conf.5.html#SECURITYMASK"> 
+	<parameter>security mask</parameter></ulink> parameter. Any bits that 
+	were changed that are not set to '1' in this parameter are left alone 
+	in the file permissions.</para>
+
+	<para>Essentially, zero bits in the <parameter>security mask</parameter>
+	mask 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 set explicitly this parameter is set to the same value as 
+	the <ulink url="smb.conf.5.html#CREATEMASK"><parameter>create mask
+	</parameter></ulink> parameter to provide compatibility with Samba 2.0.4 
+	where this permission change facility was introduced. 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 <ulink url="smb.conf.5.html#FORCESECURITYMODE">
+	<parameter>force security mode</parameter></ulink> parameter. Any bits 
+	that were changed that correspond to bits set to '1' 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 'on'.</para>
+
+	<para>If not set explicitly this parameter is set to the same value 
+	as the <ulink url="smb.conf.5.html#FORCECREATEMODE"><parameter>force 
+	create mode</parameter></ulink> parameter to provide compatibility
+	with Samba 2.0.4 where the permission change facility was introduced.
+	To allow a user to modify all the user/group/world permissions on a file,
+	with no restrictions set this parameter to 000.</para>
+
+	<para>The <parameter>security mask</parameter> 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 using 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 <parameter>directory security mask</parameter> 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 <parameter>force directory mode</parameter> parameter to provide 
+	compatibility with Samba 2.0.4 where the permission change facility 
+	was introduced.</para>
+
+	<para>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.</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
+	doesn't force any particular bits to be set 'on', then set the following
+	parameters in the <ulink url="smb.conf.5.html"><filename>smb.conf(5)
+	</filename></ulink> file in that share specific section :</para>
+
+	<para><parameter>security mask = 0777</parameter></para>
+	<para><parameter>force security mode = 0</parameter></para>
+	<para><parameter>directory security mask = 0777</parameter></para>
+	<para><parameter>force directory security mode = 0</parameter></para>
+
+	<para>As described, in Samba 2.0.4 the parameters :</para>
+
+	<para><parameter>create mask</parameter></para>
+	<para><parameter>force create mode</parameter></para>
+	<para><parameter>directory mask</parameter></para>
+	<para><parameter>force directory mode</parameter></para>
+
+	<para>were used instead of the parameters discussed here.</para>
+</sect1>
+
+<sect1>
+	<title>Interaction with the standard Samba file attribute 
+	mapping</title>
+
+	<para>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.
+	</para>
+
+	<para>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.</para>
+
+	<para>What this can mean is that if the owner changes the permissions
+	to allow themselves read access using the security dialog, clicks
+	<command>"OK"</command> to get back to the standard attributes tab 
+	dialog, and then clicks <command>"OK"</command> 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 <command>"OK"</command> to get back to the 
+	attributes dialog you should always hit <command>"Cancel"</command> 
+	rather than <command>"OK"</command> to ensure that your changes 
+	are not overridden.</para>
+</sect1>
+
+</article>
diff --git a/docs/htmldocs/DOMAIN_MEMBER.html b/docs/htmldocs/DOMAIN_MEMBER.html
index 3830c3dac6..6ae8e7a49d 100644
--- a/docs/htmldocs/DOMAIN_MEMBER.html
+++ b/docs/htmldocs/DOMAIN_MEMBER.html
@@ -6,62 +6,20 @@
 NAME="GENERATOR"
 CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD
 ><BODY
-CLASS="BOOK"
+CLASS="ARTICLE"
 BGCOLOR="#FFFFFF"
 TEXT="#000000"
 LINK="#0000FF"
 VLINK="#840084"
 ALINK="#0000FF"
 ><DIV
-CLASS="BOOK"
-><A
-NAME="AEN1"
-></A
-><DIV
-CLASS="TITLEPAGE"
-><H3
-CLASS="AUTHOR"
-><A
-NAME="AEN3"
->Jeremy Allison</A
-></H3
-><HR></DIV
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
-><A
-HREF="#AEN7"
-></A
-></DT
-><DD
-><DL
-><DT
-><A
-HREF="#AEN8"
->Joining an NT Domain with Samba 2.2</A
-></DT
-><DT
-><A
-HREF="#AEN71"
->Why is this better than security = server?</A
-></DT
-></DL
-></DD
-></DL
-></DIV
-><DIV
 CLASS="ARTICLE"
 ><DIV
 CLASS="SECT1"
 ><H1
 CLASS="SECT1"
 ><A
-NAME="AEN8"
+NAME="AEN2"
 >Joining an NT Domain with Samba 2.2</A
 ></H1
 ><P
@@ -284,7 +242,7 @@ CLASS="SECT1"
 ><HR><H1
 CLASS="SECT1"
 ><A
-NAME="AEN71"
+NAME="AEN65"
 >Why is this better than security = server?</A
 ></H1
 ><P
@@ -357,7 +315,6 @@ TARGET="_top"
 >.</P
 ></DIV
 ></DIV
-></DIV
 ></BODY
 ></HTML
 >
\ No newline at end of file
diff --git a/docs/htmldocs/NT_Security.html b/docs/htmldocs/NT_Security.html
index eb4d3a2355..8615a7f0da 100644
--- a/docs/htmldocs/NT_Security.html
+++ b/docs/htmldocs/NT_Security.html
@@ -1,254 +1,774 @@
-
-
-
-
-
-
-<html><head><title>Viewing and changing UNIX permissions using the NT security dialogs in Samba 2.0.4</title>
-
-<link rev="made" href="mailto:samba@samba.org">
-</head>
-<body>
-
-<hr>
-
-<h1>Viewing and changing UNIX permissions using the NT security dialogs in Samba 2.0.4</h1>
-<h2>Jeremy Allison, Samba Team</h2>
-<h2>12th April 1999</h2>
-
-<h1>Table of Contents </h1><p></p>
- 
-<p><hr><p><br>
-<p><center><strong>Viewing and changing UNIX permissions using the NT security dialogs</strong> </center><br>
-<center><strong>-------------------------------------------------------------------</strong> </center>
-<p>New in the <strong>Samba 2.0.4</strong> release is the
-ability for Windows NT clients to use their native security
-settings dialog box to view and modify the underlying UNIX
-permissions.
-<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>In Samba 2.0.4 and above the default value of the parameter
-<a href="smb.conf.5.html#ntaclsupport"><strong>"nt acl support"</strong></a> has been
-changed from "false" to "true", so manipulation of permissions is
-turned on by default.
-<p><strong>How to view file security on a Samba share</strong><br>
-<strong>------------------------------------------</strong>
-<p>From an NT 4.0 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 <code>Properties</code> entry at the 
-bottom of the menu. This brings up the normal file properties dialog
-box, but with Samba 2.0.4 this will have a new tab along the top
-marked <code>Security</code>. Click on this tab and you will see three buttons,
-<em>Permissions</em>, <em>Auditing</em>, and <em>Ownership</em>. The <em>Auditing</em>
-button will cause either an error message <code>"A requested privilege is
-not held by the client"</code> 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 <code>Add</code> button
-will not currently allow a list of users to be seen.
-<p><strong>Viewing file ownership</strong><br>
-<strong>----------------------</strong>
-<p>Clicking on the <code>"Ownership"</code> button brings up a dialog box telling
-you who owns the given file. The owner name will be of the form :
-<p><code>"SERVER\user (Long name)"</code>
-<p>Where <code>SERVER</code> is the NetBIOS name of the Samba server, <code>user</code>
-is the user name of the UNIX user who owns the file, and <code>(Long name)</code>
-is the discriptive string identifying the user (normally found in the
-GECOS field of the UNIX password database). Click on the <code>Close</code>
-button to remove this dialog.
-<p>If the parameter <a href="smb.conf.5.html#ntaclsupport"><strong>"nt acl support"</strong></a>
-is set to "false" then the file owner will be shown as the NT user
-<code>"Everyone"</code>.
-<p>The <code>Take Ownership</code> 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 privilaged operation in UNIX, available
-only to the <em>root</em> 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>There is an NT chown command that will work with Samba and allow
-a user with Administrator privillage connected to a Samba 2.0.4
-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 <strong>Seclib</strong> NT security library written by Jeremy
-Allison of the Samba Team, available from the main Samba ftp site.
-<p><strong>Viewing file or directory permissions</strong><br>
-<strong>-------------------------------------</strong>
-<p>The third button is the <code>"Permissions"</code> 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><code>"SERVER\user (Long name)"</code>
-<p>Where <code>SERVER</code> is the NetBIOS name of the Samba server, <code>user</code>
-is the user name of the UNIX user who owns the file, and <code>(Long name)</code>
-is the discriptive string identifying the user (normally found in the
-GECOS field of the UNIX password database).
-<p>If the parameter <a href="smb.conf.5.html#ntaclsupport"><strong>"nt acl support"</strong></a>
-is set to "false" then the file owner will be shown as the NT user
-<code>"Everyone"</code> and the permissions will be shown as NT <code>"Full Control"</code>.
-<p>The permissions field is displayed differently for files and directories,
-so I'll describe the way file permissions are displayed first.
-<p><strong>File Permissions</strong><br>
-<strong>----------------</strong>
-<p>The standard UNIX user/group/world triple and the correspinding
-"read", "write", "execute" permissions triples 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 <code>Everyone</code>, followed by the list of permissions
-allowed for UNIX world. The UNIX owner and group permissions
-are displayed as an NT <code>user</code> icon and an NT <code>local group</code> icon
-respectively followed by the list of permissions allowed for the
-UNIX user and group.
-<p>As many UNIX permission sets don't map into common NT names such as
-<code>"read"</code>, <code>"change"</code> or <code>"full control"</code> then usually the permissions
-will be prefixed by the words <code>"Special Access"</code> in the NT display 
-list.
-<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 <code>"Take Ownership"</code> ACL attribute (which has no meaning in
-UNIX) and reports a component with no permissions as having the NT
-<code>"O"</code> 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><strong>Directory Permissions</strong><br>
-<strong>---------------------</strong>
-<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 <code>"RW"</code> 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>The second set of directory permissions has no real meaning in the
-UNIX permissions world and represents the <code>"inherited"</code> permissions
-that any file created within this directory would inherit.
-<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><strong>Modifying file or directory permissions</strong><br>
-<strong>---------------------------------------</strong>
-<p>Modifying file and directory permissions is as simple as changing
-the displayed permissions in the dialog box, and clicking the <code>OK</code>
-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>If the parameter <a href="smb.conf.5.html#ntaclsupport"><strong>"nt acl support"</strong></a>
-is set to "false" then any attempt to set security permissions will
-fail with an <code>"Access Denied"</code> message.
-<p>The first thing to note is that the <code>"Add"</code> button will not return
-a list of users in Samba 2.0.4 (it will give an error message of
-<code>"The remote proceedure call failed and did not execute"</code>). 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>If a permission triple (either user, group, or world) is removed from
-the list of permissions in the NT dialog box, then when the <code>"OK"</code>
-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 <code>"O"</code> flag, as described above. This allows you
-to add permissions back to a file or directory once you have removed
-them from a triple component.
-<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>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 <code>"Replace permissions on existing files"</code> checkbox
-in the NT dialog before clicking <code>"OK"</code>.
-<p>If you wish to remove all permissions from a user/group/world 
-component then you may either highlight the component and click
-the <code>"Remove"</code> button, or set the component to only have the special
-<code>"Take Ownership"</code> permission (dsplayed as <code>"O"</code>) highlighted.
-<p><strong>Interaction with the standard Samba create mask parameters</strong><br>
-<strong>----------------------------------------------------------</strong>
-<p>Note that with Samba 2.0.5 there are four new parameters to
-control this interaction.
-<p>These are :
-<p><code>security mask</code>
-<code>force security mode</code>
-<code>directory security mask</code>
-<code>force directory security mode</code>
-<p>Once a user clicks <code>"OK"</code> to apply the permissions Samba maps
-the given permissions into a user/group/world r/w/x triple set,
-and then will check the changed permissions for a file against
-the bits set in the <a href="smb.conf.5.html#securitymask"><strong>"security mask"</strong></a>
-parameter. Any bits that were changed that are not set to '1'
-in this parameter are left alone in the file permissions.
-<p>Essentially, zero bits in the <a href="smb.conf.5.html#securitymask"><strong>"security mask"</strong></a>
-mask may be treated as a set of bits the user is <em>not</em> allowed to change,
-and one bits are those the user is allowed to change.
-<p>If not set explicitly this parameter is set to the same value as the
-<a href="smb.conf.5.html#createmask"><strong>"create mask"</strong></a> parameter to provide compatibility
-with Samba 2.0.4 where this permission change facility was introduced.
-To allow a user to modify all the user/group/world permissions on a file,
-set this parameter to 0777.
-<p>Next Samba checks the changed permissions for a file against the
-bits set in the <a href="smb.conf.5.html#forcesecuritymode"><strong>"force security mode"</strong></a>
-parameter. Any bits that were changed that correspond to bits set
-to '1' in this parameter are forced to be set.
-<p>Essentially, bits set in the <a href="smb.conf.5.html#forcesecuritymode"><strong>"force security mode"</strong></a>
-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>If not set explicitly this parameter is set to the same value as the
-<a href="smb.conf.5.html#forcecreatemode"><strong>"force create mode"</strong></a> parameter to provide compatibility
-with Samba 2.0.4 where the permission change facility was introduced.
-To allow a user to modify all the user/group/world permissions on a file,
-with no restrictions set this parameter to 000.
-<p>The <a href="smb.conf.5.html#securitymask"><strong>"security mask"</strong></a> and
-<a href="smb.conf.5.html#forcesecuritymode"><strong>"force security mode"</strong></a> parameters
-are applied to the change request in that order.
-<p>For a directory Samba will perform the same operations as described above
-for a file except using the parameter <a href="smb.conf.5.html#directorysecuritymask"><strong>"directory security mask"</strong></a>
-instead of <a href="smb.conf.5.html#securitymask"><strong>"security mask"</strong></a>, and 
-<a href="smb.conf.5.html#forcedirectorysecuritymode"><strong>"force directory security mode"</strong></a> parameter instead
-of <a href="smb.conf.5.html#forcesecuritymode"><strong>"force security mode"</strong></a>.
-<p>The <a href="smb.conf.5.html#directorysecuritymask"><strong>"directory security mask"</strong></a>
-parameter by default is set to the same value as the <a href="smb.conf.5.html#directorymask"><strong>"directory mask"</strong></a>
-parameter and the <a href="smb.conf.5.html#forcedirectorysecuritymode"><strong>"force directory security mode"</strong></a>
-parameter by default is set to the same value as the 
-iurl(<strong>"force directory mode"</strong>)(smb.conf.5.html#forcedirectorymode) parameter
-to provide compatibility with Samba 2.0.4 where the permission change facility was introduced.
-<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>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 <a href="smb.conf.5.html"><strong>smb.conf.5</strong></a> file in
-that share specific section :
-<p><code>security mask = 0777</code>
-<code>force security mode = 0</code>
-<code>directory security mask = 0777</code>
-<code>force directory security mode = 0</code>
-<p>As described, in Samba 2.0.4 the parameters :
-<p><code>create mask</code>
-<code>force create mode</code>
-<code>directory mask</code>
-<code>force directory mode</code>
-<p>were used instead of the parameters discussed here.
-<p><strong>Interaction with the standard Samba file attribute mapping</strong><br>
-<strong>----------------------------------------------------------</strong>
-<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>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>What this can mean is that if the owner changes the permissions
-to allow themselves read access using the security dialog, clicks
-<code>"OK"</code> to get back to the standard attributes tab dialog, and
-then clicks <code>"OK"</code> 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 <code>"OK"</code> to get back to the attributes dialog you
-should always hit <code>"Cancel"</code> rather than <code>"OK"</code> to ensure
-that your changes are not overridden.
-</body>
-</html>
+<HTML
+><HEAD
+><TITLE
+></TITLE
+><META
+NAME="GENERATOR"
+CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD
+><BODY
+CLASS="ARTICLE"
+BGCOLOR="#FFFFFF"
+TEXT="#000000"
+LINK="#0000FF"
+VLINK="#840084"
+ALINK="#0000FF"
+><DIV
+CLASS="ARTICLE"
+><DIV
+CLASS="SECT1"
+><H1
+CLASS="SECT1"
+><A
+NAME="AEN2"
+>Viewing and changing UNIX permissions using the NT 
+	security dialogs</A
+></H1
+><P
+>New in the Samba 2.0.4 release is the ability for Windows 
+	NT clients to 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
+>In Samba 2.0.4 and above the default value of the 
+	parameter <A
+HREF="smb.conf.5.html#NTACLSUPPOR"
+TARGET="_top"
+><TT
+CLASS="PARAMETER"
+><I
+>	nt acl support</I
+></TT
+></A
+> has been changed from 
+	<TT
+CLASS="CONSTANT"
+>false</TT
+> to <TT
+CLASS="CONSTANT"
+>true</TT
+>, so 
+ 	manipulation of permissions is turned on by default.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><HR><H1
+CLASS="SECT1"
+><A
+NAME="AEN11"
+>How to view file security on a Samba share</A
+></H1
+><P
+>From an NT 4.0 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 <I
+CLASS="EMPHASIS"
+>Properties</I
+> entry at the bottom of 
+	the menu. This brings up the normal file properties dialog
+	box, but with Samba 2.0.4 this will have a new tab along the top
+	marked <I
+CLASS="EMPHASIS"
+>Security</I
+>. Click on this tab and you 
+	will see three buttons, <I
+CLASS="EMPHASIS"
+>Permissions</I
+>, 	
+	<I
+CLASS="EMPHASIS"
+>Auditing</I
+>, and <I
+CLASS="EMPHASIS"
+>Ownership</I
+>. 
+	The <I
+CLASS="EMPHASIS"
+>Auditing</I
+> 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 <B
+CLASS="COMMAND"
+>Add</B
+> button will not currently 
+	allow a list of users to be seen.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><HR><H1
+CLASS="SECT1"
+><A
+NAME="AEN22"
+>Viewing file ownership</A
+></H1
+><P
+>Clicking on the <B
+CLASS="COMMAND"
+>"Ownership"</B
+> 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 <TT
+CLASS="REPLACEABLE"
+><I
+>SERVER</I
+></TT
+> is the NetBIOS name of 
+	the Samba server, <TT
+CLASS="REPLACEABLE"
+><I
+>user</I
+></TT
+> is the user name of 
+	the UNIX user who owns the file, and <TT
+CLASS="REPLACEABLE"
+><I
+>(Long name)</I
+></TT
+>
+	is the discriptive string identifying the user (normally found in the
+	GECOS field of the UNIX password database). Click on the <B
+CLASS="COMMAND"
+>Close
+	</B
+> button to remove this dialog.</P
+><P
+>If the parameter <TT
+CLASS="PARAMETER"
+><I
+>nt acl support</I
+></TT
+>
+	is set to <TT
+CLASS="CONSTANT"
+>false</TT
+> then the file owner will 
+	be shown as the NT user <B
+CLASS="COMMAND"
+>"Everyone"</B
+>.</P
+><P
+>The <B
+CLASS="COMMAND"
+>Take Ownership</B
+> 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 privilaged 
+	operation in UNIX, available only to the <I
+CLASS="EMPHASIS"
+>root</I
+> 
+	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 privillage connected 
+	to a Samba 2.0.4 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 <I
+CLASS="EMPHASIS"
+>Seclib
+	</I
+> NT security library written by Jeremy Allison of 
+	the Samba Team, available from the main Samba ftp site.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><HR><H1
+CLASS="SECT1"
+><A
+NAME="AEN42"
+>Viewing file or directory permissions</A
+></H1
+><P
+>The third button is the <B
+CLASS="COMMAND"
+>"Permissions"</B
+> 
+	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"
+>"SERVER\user (Long name)"</B
+></P
+><P
+>Where <TT
+CLASS="REPLACEABLE"
+><I
+>SERVER</I
+></TT
+> is the NetBIOS name of 
+	the Samba server, <TT
+CLASS="REPLACEABLE"
+><I
+>user</I
+></TT
+> is the user name of 
+	the UNIX user who owns the file, and <TT
+CLASS="REPLACEABLE"
+><I
+>(Long name)</I
+></TT
+>
+	is the discriptive string identifying the user (normally found in the
+	GECOS field of the UNIX password database).</P
+><P
+>If the parameter <TT
+CLASS="PARAMETER"
+><I
+>nt acl support</I
+></TT
+>
+	is set to <TT
+CLASS="CONSTANT"
+>false</TT
+> then the file owner will 
+	be shown as the NT user <B
+CLASS="COMMAND"
+>"Everyone"</B
+> 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="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN57"
+>File Permissions</A
+></H2
+><P
+>The standard UNIX user/group/world triple and 
+		the correspinding "read", "write", "execute" permissions 
+		triples 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 <B
+CLASS="COMMAND"
+>Everyone</B
+>, followed 
+		by the list of permissions allowed for UNIX world. The UNIX 
+		owner and group permissions are displayed as an NT 
+		<B
+CLASS="COMMAND"
+>user</B
+> icon and an NT <B
+CLASS="COMMAND"
+>local 
+		group</B
+> 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 <B
+CLASS="COMMAND"
+>"read"</B
+>, <B
+CLASS="COMMAND"
+>		"change"</B
+> or <B
+CLASS="COMMAND"
+>"full control"</B
+> then 
+		usually the permissions will be prefixed by the words <B
+CLASS="COMMAND"
+>		"Special Access"</B
+> 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="SECT2"
+><HR><H2
+CLASS="SECT2"
+><A
+NAME="AEN71"
+>Directory Permissions</A
+></H2
+><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 <B
+CLASS="COMMAND"
+>"RW"</B
+> 
+		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 <B
+CLASS="COMMAND"
+>		"inherited"</B
+> 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="SECT1"
+><HR><H1
+CLASS="SECT1"
+><A
+NAME="AEN78"
+>Modifying file or directory permissions</A
+></H1
+><P
+>Modifying file and directory permissions is as simple 
+	as changing the displayed permissions in the dialog box, and 
+	clicking the <B
+CLASS="COMMAND"
+>OK</B
+> 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 <TT
+CLASS="PARAMETER"
+><I
+>nt acl support</I
+></TT
+>
+	is set to <TT
+CLASS="CONSTANT"
+>false</TT
+> then any attempt to set 
+	security permissions will fail with an <B
+CLASS="COMMAND"
+>"Access Denied"
+	</B
+> message.</P
+><P
+>The first thing to note is that the <B
+CLASS="COMMAND"
+>"Add"</B
+> 
+	button will not return a list of users in Samba 2.0.4 (it will give 
+	an error message of <B
+CLASS="COMMAND"
+>"The remote proceedure call failed 
+	and did not execute"</B
+>). 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 triple (either user, group, or world) 
+	is removed from the list of permissions in the NT dialog box, 
+	then when the <B
+CLASS="COMMAND"
+>"OK"</B
+> 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 triple 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 <B
+CLASS="COMMAND"
+>"Replace 
+	permissions on existing files"</B
+> checkbox in the NT 
+	dialog before clicking <B
+CLASS="COMMAND"
+>"OK"</B
+>.</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 <B
+CLASS="COMMAND"
+>"Remove"</B
+> button, 
+	or set the component to only have the special <B
+CLASS="COMMAND"
+>"Take
+	Ownership"</B
+> permission (dsplayed as <B
+CLASS="COMMAND"
+>"O"
+	</B
+>) highlighted.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><HR><H1
+CLASS="SECT1"
+><A
+NAME="AEN100"
+>Interaction with the standard Samba create mask 
+	parameters</A
+></H1
+><P
+>Note that with Samba 2.0.5 there are four new parameters 
+	to control this interaction.  These are :</P
+><P
+><TT
+CLASS="PARAMETER"
+><I
+>security mask</I
+></TT
+></P
+><P
+><TT
+CLASS="PARAMETER"
+><I
+>force security mode</I
+></TT
+></P
+><P
+><TT
+CLASS="PARAMETER"
+><I
+>directory security mask</I
+></TT
+></P
+><P
+><TT
+CLASS="PARAMETER"
+><I
+>force directory security mode</I
+></TT
+></P
+><P
+>Once a user clicks <B
+CLASS="COMMAND"
+>"OK"</B
+> to apply the 
+	permissions Samba maps the given permissions into a user/group/world 
+	r/w/x triple set, and then will check the changed permissions for a 
+	file against the bits set in the <A
+HREF="smb.conf.5.html#SECURITYMASK"
+TARGET="_top"
+> 
+	<TT
+CLASS="PARAMETER"
+><I
+>security mask</I
+></TT
+></A
+> 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 <TT
+CLASS="PARAMETER"
+><I
+>security mask</I
+></TT
+>
+	mask may be treated as a set of bits the user is <I
+CLASS="EMPHASIS"
+>not</I
+> 
+	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
+HREF="smb.conf.5.html#CREATEMASK"
+TARGET="_top"
+><TT
+CLASS="PARAMETER"
+><I
+>create mask
+	</I
+></TT
+></A
+> parameter to provide compatibility with Samba 2.0.4 
+	where this permission change facility was introduced. 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
+HREF="smb.conf.5.html#FORCESECURITYMODE"
+TARGET="_top"
+>	<TT
+CLASS="PARAMETER"
+><I
+>force security mode</I
+></TT
+></A
+> 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 <TT
+CLASS="PARAMETER"
+><I
+>force security mode
+	</I
+></TT
+> 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
+HREF="smb.conf.5.html#FORCECREATEMODE"
+TARGET="_top"
+><TT
+CLASS="PARAMETER"
+><I
+>force 
+	create mode</I
+></TT
+></A
+> parameter to provide compatibility
+	with Samba 2.0.4 where the permission change facility was introduced.
+	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 <TT
+CLASS="PARAMETER"
+><I
+>security mask</I
+></TT
+> and <TT
+CLASS="PARAMETER"
+><I
+>force 
+	security mode</I
+></TT
+> 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 <TT
+CLASS="PARAMETER"
+><I
+>	directory security mask</I
+></TT
+> instead of <TT
+CLASS="PARAMETER"
+><I
+>security 
+	mask</I
+></TT
+>, and <TT
+CLASS="PARAMETER"
+><I
+>force directory security mode
+	</I
+></TT
+> parameter instead of <TT
+CLASS="PARAMETER"
+><I
+>force security mode
+	</I
+></TT
+>.</P
+><P
+>The <TT
+CLASS="PARAMETER"
+><I
+>directory security mask</I
+></TT
+> parameter 
+	by default is set to the same value as the <TT
+CLASS="PARAMETER"
+><I
+>directory mask
+	</I
+></TT
+> parameter and the <TT
+CLASS="PARAMETER"
+><I
+>force directory security 
+	mode</I
+></TT
+> parameter by default is set to the same value as 
+ 	the <TT
+CLASS="PARAMETER"
+><I
+>force directory mode</I
+></TT
+> parameter to provide 
+	compatibility with Samba 2.0.4 where the permission change facility 
+	was introduced.</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 <A
+HREF="smb.conf.5.html"
+TARGET="_top"
+><TT
+CLASS="FILENAME"
+>smb.conf(5)
+	</TT
+></A
+> file in that share specific section :</P
+><P
+><TT
+CLASS="PARAMETER"
+><I
+>security mask = 0777</I
+></TT
+></P
+><P
+><TT
+CLASS="PARAMETER"
+><I
+>force security mode = 0</I
+></TT
+></P
+><P
+><TT
+CLASS="PARAMETER"
+><I
+>directory security mask = 0777</I
+></TT
+></P
+><P
+><TT
+CLASS="PARAMETER"
+><I
+>force directory security mode = 0</I
+></TT
+></P
+><P
+>As described, in Samba 2.0.4 the parameters :</P
+><P
+><TT
+CLASS="PARAMETER"
+><I
+>create mask</I
+></TT
+></P
+><P
+><TT
+CLASS="PARAMETER"
+><I
+>force create mode</I
+></TT
+></P
+><P
+><TT
+CLASS="PARAMETER"
+><I
+>directory mask</I
+></TT
+></P
+><P
+><TT
+CLASS="PARAMETER"
+><I
+>force directory mode</I
+></TT
+></P
+><P
+>were used instead of the parameters discussed here.</P
+></DIV
+><DIV
+CLASS="SECT1"
+><HR><H1
+CLASS="SECT1"
+><A
+NAME="AEN164"
+>Interaction with the standard Samba file attribute 
+	mapping</A
+></H1
+><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
+><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
+	<B
+CLASS="COMMAND"
+>"OK"</B
+> to get back to the standard attributes tab 
+	dialog, and then clicks <B
+CLASS="COMMAND"
+>"OK"</B
+> 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 <B
+CLASS="COMMAND"
+>"OK"</B
+> to get back to the 
+	attributes dialog you should always hit <B
+CLASS="COMMAND"
+>"Cancel"</B
+> 
+	rather than <B
+CLASS="COMMAND"
+>"OK"</B
+> to ensure that your changes 
+	are not overridden.</P
+></DIV
+></DIV
+></BODY
+></HTML
+>
\ No newline at end of file