6.0 HP X9000 File Serving Software File System User Guide (TA768-96043, October 2011)

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
occur for 15 to 20 minutes. The client's copy will then continue without error if the retry timeout
has not expired. To work around this situation, take one of these steps:
• Stop and restart the Likewise process on the affected file serving node:
# /opt/likewise/bin/lwsm stop lwreg && /etc/init.d/lwsmd stop
# /etc/init.d/lwsmd start && /opt/likewise/bin/lwsm start srvsvc
• Power down the file serving node before failing it over, and do failback operations only during
off hours.
The following xcopy and robocopy options are recommended for copying files from a client to
a highly available CIFS server:
Troubleshooting CIFS 73