Filter
Top Products
Chapter 2 NAS Head 2-61
2.12 NFS Issues
NFS root user doesn't have appropriate access.
StorEdge implements a feature known as “root squash”. When a user connects as
root (UID 0) from an NFS client, StorEdge causes the UID to be mapped to UID
60001, the “nobody” account. In order for an NFS client to have root access to
StorEdge, you must create a trusted hosts entry, or explicitly define root access for a
particular export.
To test whether you have root access: create a file with the touch command, then use
ls –ln filename to view the ownership. If the owner is UID 60001, then correct as
above.
NFS root user can't change ownership.
NFS root user can't change security.
This typically occurs when a file or directory has been created or modified by a
Windows client. Windows uses complex security descriptors, known as ACLs or
Access Control Lists. These cannot always be accurately represented using NFS
security attributes. Therefore, to prevent NFS users from circumventing these
security descriptors, modification of security or ownership is not permitted on files
with ACLs.
It is possible to remove ACL information for a single file, or for an entire volume.
Removing the ACL information allows the security and ownership for these objects
to be edited from NFS clients once again, with appropriate permissions and
ownership.
This functionality is only available at the StorEdge CLI (command line interface).
1. To access the StorEdge CLI, connect to the StorEdge via Telnet, and type “admin”
at the [menu] prompt and enter the administrator password.
2. At the CLI, enter “chsmb <filename>” or “chsmb <volumename>”.
For <filename>, use a full path, including volume. A directory is acceptable for
<filename>, but chsmb can not be run recursively. A warning is displayed only
when a <volumename> argument is used.
It is also possible to modify this behavior as a system policy. Generally, this is not
recommended in environments where Windows security is important.