HP StoreAll Storage - Manual (Page 92)

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 CIFS inherits permissions on files accessed from Linux applications
To avoid the CIFS server 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 CIFS 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 CIFS 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 CIFS
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 CIFS client side. Using this mechanism, a Windows
user can set the files to be inaccessible to the CIFS users of the directory tree while opening them
up to the Linux users of the directory tree.
Troubleshooting CIFS
Changes to user permissions do not take effect immediately
The CIFS 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.
Robocopy errors occur during node failover or failback
If Robocopy is in use on a client while a file serving node is failed over or failed back, the
application repeatedly retries to access the file and reports the error The process cannot
access the file because it is being used by another process
. These errors
92 Using CIFS