docs-xml/smbdotconf/protocol/aclcheckpermissions.xml

   1 <samba:parameter name="acl check permissions"
   2                  context="S"
   3                  type="boolean"
   4                  advanced="1" wizard="1"
   5                  xmlns:samba="http://www.samba.org/samba/DTD/samba-doc">
   6 <description>
   7     <para>Please note this parameter is now deprecated in Samba 3.6.2 and will be removed
   8     in a future version of Samba.
   9     </para>
  10     <para>This boolean parameter controls what <citerefentry><refentrytitle>smbd</refentrytitle>
  11     <manvolnum>8</manvolnum></citerefentry> does on receiving a protocol request of "open for delete"
  12     from a Windows client. If a Windows client doesn't have permissions to delete a file then they
  13     expect this to be denied at open time. POSIX systems normally only detect restrictions on delete by
  14     actually attempting to delete the file or directory. As Windows clients can (and do) "back out" a
  15     delete request by unsetting the "delete on close" bit Samba cannot delete the file immediately
  16     on "open for delete" request as we cannot restore such a deleted file. With this parameter set to
  17     true (the default) then smbd checks the file system permissions directly on "open for delete" and denies the
  18     request without actually deleting the file if the file system permissions would seem to deny it.
  19     This is not perfect, as it's possible a user could have deleted a file without Samba being able to
  20     check the permissions correctly, but it is close enough to Windows semantics for mostly correct
  21     behaviour. Samba will correctly check POSIX ACL semantics in this case.
  22     </para>
  23     <para>If this parameter is set to "false" Samba doesn't check permissions on "open for delete"
  24     and allows the open. If the user doesn't have permission to delete the file this will only be
  25     discovered at close time, which is too late for the Windows user tools to display an error message
  26     to the user. The symptom of this is files that appear to have been deleted "magically" re-appearing
  27     on a Windows explorer refresh. This is an extremely advanced protocol option which should not
  28     need to be changed. This parameter was introduced in its final form in 3.0.21, an earlier version
  29     with slightly different semantics was introduced in 3.0.20. That older version is not documented here.
  30     </para>
  31 </description>
  32 <value type="default">yes</value>
  33 </samba:parameter>