Lines Matching full:client

4 NFSv4 client identifier
7 This document explains how the NFSv4 protocol identifies client
10 on each client. These can be set by administrators, scripts
14 There are risks if a client's NFSv4 identifier and its principal
25 Simply put, an NFSv4 server creates a lease for each NFSv4 client.
26 The server collects each client's file open and lock state under
27 the lease for that client.
29 The client is responsible for periodically renewing its leases.
31 guarantees the file locks the client has created remain in place.
33 If a client stops renewing its lease (for example, if it crashes),
34 the NFSv4 protocol allows the server to remove the client's open
35 and lock state after a certain period of time. When a client
40 In addition, each NFSv4 server manages a persistent list of client
47 NFSv4 client identifiers
50 Each NFSv4 client presents an identifier to NFSv4 servers so that
51 they can associate the client with its lease. Each client's
57     server to distinguish successive boot epochs of the same client.
64 flavor that the client used when presenting it. Servers use this
66 sent by the client. Effectively this principal is a third element of
72   - The "co_ownerid" string identifies the client during reboot
73     recovery, therefore the string is persistent across client
75   - The "co_ownerid" string helps servers distinguish the client
81     the client itself.
83     before the client attempts NFSv4 mounts after a restart.
91 assign a unique lease to each client. Under this scheme, there are
98 client presents a different boot verifier, so it appears to the
99 server as if there is one client that is rebooting frequently.
100 Neither client can maintain open or lock state in this scenario.
103 distinct principals, the server is likely to allow the first client
107 If a client's "co_ownerid" string or principal are not stable,
108 state recovery after a server or client reboot is not guaranteed.
109 If a client unexpectedly restarts but presents a different
111 the client's previous open and lock state. This blocks access to
114 If the server restarts and a client presents a changed "co_ownerid"
116 client to reclaim its open and lock state, and may give those locks
123 Selecting an appropriate client identifier
126 By default, the Linux NFSv4 client implementation constructs its
128 the client's UTS node name (the same node name, incidentally, that
140     client instances with the same host name.
175 If NFS with Kerberos is not configured, a Linux NFSv4 client uses
176 AUTH_SYS and UID 0 as the principal part of its client identity.
179 client configurations that have no local persistent storage.
183 When a Kerberos keytab is present on a Linux NFS client, the client
186 control this behavior. Alternately, a single-user client with a
187 Kerberos principal can use that principal in place of the client's
190 Using Kerberos for this purpose enables the client and server to
192 Additionally, the Linux NFS client uses the RPCSEC_GSS security
198 The Linux NFSv4 client establishes a single lease on each NFSv4
199 server it accesses. NFSv4 mounts from a Linux NFSv4 client of a
202 Once a client establishes open and lock state, the NFSv4 protocol
205 running applications. The Linux NFSv4 client facilitates state