Browsing Romanian translation

18.

<b>No subtree check</b>
<p>
This option disables subtree checking, which has mild security implications, but can improve reliability is some circumstances.
</p>
<p>
If a subdirectory of a filesystem is exported, but the whole filesystem is not, then whenever a NFS request arrives, the server must check not only that the accessed file is in the appropriate filesystem (which is easy) but also that it is in the exported tree (which is harder). This check is called the subtree_check.
</p>
<p>
In order to perform this check, the server must include some information about the location of the file in the "filehandle" that is given to the client. This can cause problems with accessing files that are renamed while a client has them open (though in many simple cases it will still work).
</p>
<p>
subtree checking is also used to make sure that files inside directories to which only root has access can only be accessed if the filesystem is exported with no_root_squash (see below), even the file itself allows more general access.
</p>
<p>
As a general guide, a home directory filesystem, which is normally exported at the root and may see lots of file renames, should be exported with subtree checking disabled. A filesystem which is mostly read-only, and at least does not see many file renames (e.g. /usr or /var) and for which subdirectories may be exported, should probably be exported with subtree checks enabled.
</p>

19.

Insecure loc&ks

20.

<b>Insecure locks</b>
<p>
This option tells the NFS server not to require authentication of locking requests (i.e. requests which use the NLM protocol). Normally the NFS server will require a lock request to hold a credential for a user who has read access to the file. With this flag no access checks will be performed.
</p>
<p>
Early NFS client implementations did not send credentials with lock requests, and many current NFS clients still exist which are based on the old implementations. Use this flag if you find that you can only lock files which are world readable.
</p>

21.

User Mapping

22.

All s&quash

23.

<b>All squash</b>
<p>
Map all uids and gids to the anonymous user. Useful for NFS-exported public FTP directories, news spool directories, etc. </p>

24.

No &root squash

25.

<b>No root squash</b>
<p>
Turn of root squashing. This option is mainly useful for diskless clients.
</p>
<i>root squashing</i>
<p>
Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids that might be equally sensitive, such as user bin.
</p>

26.

Anonym. &UID:

27.

<b>Anonym. UID/GID</b> <p> These options explicitly set the uid and gid of the anonymous account. This option is primarily useful for PC/NFS clients, where you might want all requests appear to be from one user. </p>