6.3 HP StoreAll Storage File System User Guide (TA768-96093, June 2013)

Working with new files and directories
The inheritance rules of Windows assume that all directories are created on a Windows machine,
where they inherit ACLs from their parent; the top level of a directory tree (the root of the file system)
is assigned ACLs by the file system formatting process from the defaults for the system.
This process is not in place on file serving nodes. Instead, when you create a share on a node,
the share does not have any inherited ACLs from the root of the file system in which it is created.
This leads to strange behavior when a Windows client attempts to use permissions to control access
to a file in such a directory. The usual CREATOR/OWNER and EVERYBODY ACLs (which are a
part of the typical Windows ACLS inheritance ACL set) do not exist on the containing directory for
the share, and are not inherited downward into the share directory tree. For true Windows-like
behavior, the creator of a share must access the root of the share and set the desired ACLs on it
manually (using Windows Explorer or a command line tool such as ICACLS). This process is
somewhat unnatural for Linux administrators, but should be fairly normal for Windows administrators.
Generally, the administrator will need to create a CREATOR/OWNER ACL that is inheritable on
the share directory, and then create an inheritable ACL that controls default access to the files in
the directory tree.
Changing the way SMB inherits permissions on files accessed from Linux applications
To prevent the SMB server from modifying file permissions on directory trees that a user wants to
access from Linux applications (so keeping permissions other than 700 on a file in the directory
tree), a user can set the setgid bit in the Linux permissions mask on the directory tree. When the
setgid bit is set, the SMB server honors that bit, and any new files in the directory inherit the
parent directory permission bits and group that created the directory. This maintains group access
for new files created in that directory tree until setgid is turned off in the tree. That is, Linux-style
permissions semantics are kept on the files in that tree, allowing SMB users to modify files in the
directory while NFS users maintain their access though their normal group permissions.
For example, if a user wants all files in a particular tree to be accessible by a set of Linux users
(say, through NFS), the user should set the setgid bit (through local Linux mechanisms) on the
top level directory for a share (in addition to setting the desired group permissions, for example
770). Once that is done, new files in the directory will be accessible to the group that creates the
directory and the permission bits on files in that directory tree will not be modified by the SMB
server. Files that existed in the directory before the setgid bit was set are not affected by the
change in the containing directory; the user must manually set the group and permissions on files
that already existed in the directory tree.
This capability can be used to facilitate cross-protocol sharing of files. Note that this does not affect
the permissions inheritance and settings on the SMB client side. Using this mechanism, a Windows
user can set the files to be inaccessible to the SMB users of the directory tree while opening them
up to the Linux users of the directory tree.
Troubleshooting SMB
Changes to user permissions do not take effect immediately
The SMB implementation maintains an authentication cache that is set to four hours. If a user is
authenticated to a share, and the user's permissions are then changed, the old permissions will
remain in effect until the cache expires, at four hours after the authentication. The next time the
user is encountered, the new, correct value will be read and written to the cache for the next four
hours.
This is not a common occurrence. However, to avoid the situation, use the following guidelines
when changing user permissions:
• After a user is authenticated to a share, wait four hours before modifying the user's permissions.
• Conversely, it is safe to modify the permissions of a user who has not been authenticated in
the previous four hours.
102 Using SMB