Found wdiff, but it reported no recognisable version. Falling back to builtin diff colouring... --- 1/draft-pre-ch-18-rename.txt 2008-04-18 12:57:02.704056100 -0700 +++ 2/draft-ietf-nfsv4-minorversion1-22.txt 2008-04-18 12:57:03.204786100 -0700 @@ -1,16 +1,16 @@ NFSv4 S. Shepler Internet-Draft M. Eisler Intended status: Standards Track D. Noveck -Expires: October 13, 2008 Editors - April 11, 2008 +Expires: October 20, 2008 Editors + April 18, 2008 NFS Version 4 Minor Version 1 draft-ietf-nfsv4-minorversion1-22.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. @@ -24,21 +24,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on October 13, 2008. + This Internet-Draft will expire on October 20, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This Internet-Draft describes NFS version 4 minor version one, including features retained from the base protocol and protocol extensions made subsequently. Major extensions introduced in NFS @@ -72,343 +72,343 @@ 2.3. COMPOUND and CB_COMPOUND . . . . . . . . . . . . . . . . 22 2.4. Client Identifiers and Client Owners . . . . . . . . . . 23 2.4.1. Upgrade from NFSv4.0 to NFSv4.1 . . . . . . . . . . 27 2.4.2. Server Release of Client ID . . . . . . . . . . . . 27 2.4.3. Resolving Client Owner Conflicts . . . . . . . . . . 27 2.5. Server Owners . . . . . . . . . . . . . . . . . . . . . 29 2.6. Security Service Negotiation . . . . . . . . . . . . . . 29 2.6.1. NFSv4.1 Security Tuples . . . . . . . . . . . . . . 30 2.6.2. SECINFO and SECINFO_NO_NAME . . . . . . . . . . . . 30 2.6.3. Security Error . . . . . . . . . . . . . . . . . . . 30 - 2.7. Minor Versioning . . . . . . . . . . . . . . . . . . . . 33 - 2.8. Non-RPC-based Security Services . . . . . . . . . . . . 36 - 2.8.1. Authorization . . . . . . . . . . . . . . . . . . . 36 - 2.8.2. Auditing . . . . . . . . . . . . . . . . . . . . . . 36 - 2.8.3. Intrusion Detection . . . . . . . . . . . . . . . . 37 - 2.9. Transport Layers . . . . . . . . . . . . . . . . . . . . 37 - 2.9.1. REQUIRED and RECOMMENDED Properties of Transports . 37 - 2.9.2. Client and Server Transport Behavior . . . . . . . . 37 - 2.9.3. Ports . . . . . . . . . . . . . . . . . . . . . . . 39 - 2.10. Session . . . . . . . . . . . . . . . . . . . . . . . . 39 - 2.10.1. Motivation and Overview . . . . . . . . . . . . . . 39 - 2.10.2. NFSv4 Integration . . . . . . . . . . . . . . . . . 40 - 2.10.3. Channels . . . . . . . . . . . . . . . . . . . . . . 42 - 2.10.4. Trunking . . . . . . . . . . . . . . . . . . . . . . 43 - 2.10.5. Exactly Once Semantics . . . . . . . . . . . . . . . 46 - 2.10.6. RDMA Considerations . . . . . . . . . . . . . . . . 59 - 2.10.7. Sessions Security . . . . . . . . . . . . . . . . . 62 - 2.10.8. The SSV GSS Mechanism . . . . . . . . . . . . . . . 67 - 2.10.9. Session Mechanics - Steady State . . . . . . . . . . 71 - 2.10.10. Session Inactivity Timer . . . . . . . . . . . . . . 73 - 2.10.11. Session Mechanics - Recovery . . . . . . . . . . . . 73 - 2.10.12. Parallel NFS and Sessions . . . . . . . . . . . . . 77 - 3. Protocol Constants and Data Types . . . . . . . . . . . . . . 77 - 3.1. Basic Constants . . . . . . . . . . . . . . . . . . . . 77 - 3.2. Basic Data Types . . . . . . . . . . . . . . . . . . . . 78 - 3.3. Structured Data Types . . . . . . . . . . . . . . . . . 80 - 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 89 - 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 89 - 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 90 - 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 90 - 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 90 - 4.2.1. General Properties of a Filehandle . . . . . . . . . 91 - 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 92 - 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 92 - 4.3. One Method of Constructing a Volatile Filehandle . . . . 93 - 4.4. Client Recovery from Filehandle Expiration . . . . . . . 94 - 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 95 - 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 96 - 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 96 - 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 97 - 5.4. Classification of Attributes . . . . . . . . . . . . . . 98 - 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 99 - 5.6. REQUIRED Attributes - List and Definition References . . 99 + 2.7. Minor Versioning . . . . . . . . . . . . . . . . . . . . 35 + 2.8. Non-RPC-based Security Services . . . . . . . . . . . . 37 + 2.8.1. Authorization . . . . . . . . . . . . . . . . . . . 37 + 2.8.2. Auditing . . . . . . . . . . . . . . . . . . . . . . 38 + 2.8.3. Intrusion Detection . . . . . . . . . . . . . . . . 38 + 2.9. Transport Layers . . . . . . . . . . . . . . . . . . . . 38 + 2.9.1. REQUIRED and RECOMMENDED Properties of Transports . 38 + 2.9.2. Client and Server Transport Behavior . . . . . . . . 39 + 2.9.3. Ports . . . . . . . . . . . . . . . . . . . . . . . 40 + 2.10. Session . . . . . . . . . . . . . . . . . . . . . . . . 40 + 2.10.1. Motivation and Overview . . . . . . . . . . . . . . 40 + 2.10.2. NFSv4 Integration . . . . . . . . . . . . . . . . . 42 + 2.10.3. Channels . . . . . . . . . . . . . . . . . . . . . . 43 + 2.10.4. Trunking . . . . . . . . . . . . . . . . . . . . . . 44 + 2.10.5. Exactly Once Semantics . . . . . . . . . . . . . . . 47 + 2.10.6. RDMA Considerations . . . . . . . . . . . . . . . . 60 + 2.10.7. Sessions Security . . . . . . . . . . . . . . . . . 63 + 2.10.8. The SSV GSS Mechanism . . . . . . . . . . . . . . . 68 + 2.10.9. Session Mechanics - Steady State . . . . . . . . . . 72 + 2.10.10. Session Inactivity Timer . . . . . . . . . . . . . . 74 + 2.10.11. Session Mechanics - Recovery . . . . . . . . . . . . 74 + 2.10.12. Parallel NFS and Sessions . . . . . . . . . . . . . 78 + 3. Protocol Constants and Data Types . . . . . . . . . . . . . . 78 + 3.1. Basic Constants . . . . . . . . . . . . . . . . . . . . 78 + 3.2. Basic Data Types . . . . . . . . . . . . . . . . . . . . 79 + 3.3. Structured Data Types . . . . . . . . . . . . . . . . . 81 + 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 90 + 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 90 + 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 91 + 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 91 + 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 91 + 4.2.1. General Properties of a Filehandle . . . . . . . . . 92 + 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 93 + 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 93 + 4.3. One Method of Constructing a Volatile Filehandle . . . . 94 + 4.4. Client Recovery from Filehandle Expiration . . . . . . . 95 + 5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 96 + 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 97 + 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 97 + 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 98 + 5.4. Classification of Attributes . . . . . . . . . . . . . . 99 + 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 100 + 5.6. REQUIRED Attributes - List and Definition References . . 100 5.7. RECOMMENDED Attributes - List and Definition - References . . . . . . . . . . . . . . . . . . . . . . . 100 - 5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 102 - 5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 102 + References . . . . . . . . . . . . . . . . . . . . . . . 101 + 5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 103 + 5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 103 5.8.2. Definitions of Uncategorized RECOMMENDED - Attributes . . . . . . . . . . . . . . . . . . . . . 104 - 5.9. Interpreting owner and owner_group . . . . . . . . . . . 111 - 5.10. Character Case Attributes . . . . . . . . . . . . . . . 113 - 5.11. Directory Notification Attributes . . . . . . . . . . . 113 - 5.12. pNFS Attribute Definitions . . . . . . . . . . . . . . . 113 - 5.13. Retention Attributes . . . . . . . . . . . . . . . . . . 115 - 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 118 - 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 118 - 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 119 - 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 119 - 6.2.2. Attribute 58: dacl . . . . . . . . . . . . . . . . . 134 - 6.2.3. Attribute 59: sacl . . . . . . . . . . . . . . . . . 134 - 6.2.4. Attribute 33: mode . . . . . . . . . . . . . . . . . 134 - 6.2.5. Attribute 74: mode_set_masked . . . . . . . . . . . 135 - 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 136 - 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 136 - 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 137 - 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 138 - 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 138 - 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 140 - 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 140 - 7. Single-server Namespace . . . . . . . . . . . . . . . . . . . 144 - 7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 144 - 7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 145 - 7.3. Server Pseudo File System . . . . . . . . . . . . . . . 145 - 7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 146 - 7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 146 - 7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 146 - 7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 147 - 7.8. Security Policy and Namespace Presentation . . . . . . . 147 - 8. State Management . . . . . . . . . . . . . . . . . . . . . . 148 - 8.1. Client and Session ID . . . . . . . . . . . . . . . . . 149 - 8.2. Stateid Definition . . . . . . . . . . . . . . . . . . . 149 - 8.2.1. Stateid Types . . . . . . . . . . . . . . . . . . . 150 - 8.2.2. Stateid Structure . . . . . . . . . . . . . . . . . 151 - 8.2.3. Special Stateids . . . . . . . . . . . . . . . . . . 152 - 8.2.4. Stateid Lifetime and Validation . . . . . . . . . . 154 - 8.2.5. Stateid Use for I/O Operations . . . . . . . . . . . 157 - 8.2.6. Stateid Use for SETATTR Operations . . . . . . . . . 158 - 8.3. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 158 - 8.4. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 160 - 8.4.1. Client Failure and Recovery . . . . . . . . . . . . 161 - 8.4.2. Server Failure and Recovery . . . . . . . . . . . . 161 - 8.4.3. Network Partitions and Recovery . . . . . . . . . . 165 - 8.5. Server Revocation of Locks . . . . . . . . . . . . . . . 170 - 8.6. Short and Long Leases . . . . . . . . . . . . . . . . . 171 + Attributes . . . . . . . . . . . . . . . . . . . . . 105 + 5.9. Interpreting owner and owner_group . . . . . . . . . . . 112 + 5.10. Character Case Attributes . . . . . . . . . . . . . . . 114 + 5.11. Directory Notification Attributes . . . . . . . . . . . 114 + 5.12. pNFS Attribute Definitions . . . . . . . . . . . . . . . 114 + 5.13. Retention Attributes . . . . . . . . . . . . . . . . . . 116 + 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 119 + 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 119 + 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 120 + 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 120 + 6.2.2. Attribute 58: dacl . . . . . . . . . . . . . . . . . 135 + 6.2.3. Attribute 59: sacl . . . . . . . . . . . . . . . . . 135 + 6.2.4. Attribute 33: mode . . . . . . . . . . . . . . . . . 135 + 6.2.5. Attribute 74: mode_set_masked . . . . . . . . . . . 136 + 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 137 + 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 137 + 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 138 + 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 139 + 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 139 + 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 141 + 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 141 + 7. Single-server Namespace . . . . . . . . . . . . . . . . . . . 145 + 7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 145 + 7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 146 + 7.3. Server Pseudo File System . . . . . . . . . . . . . . . 146 + 7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 147 + 7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 147 + 7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 147 + 7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 148 + 7.8. Security Policy and Namespace Presentation . . . . . . . 148 + 8. State Management . . . . . . . . . . . . . . . . . . . . . . 149 + 8.1. Client and Session ID . . . . . . . . . . . . . . . . . 150 + 8.2. Stateid Definition . . . . . . . . . . . . . . . . . . . 150 + 8.2.1. Stateid Types . . . . . . . . . . . . . . . . . . . 151 + 8.2.2. Stateid Structure . . . . . . . . . . . . . . . . . 152 + 8.2.3. Special Stateids . . . . . . . . . . . . . . . . . . 153 + 8.2.4. Stateid Lifetime and Validation . . . . . . . . . . 155 + 8.2.5. Stateid Use for I/O Operations . . . . . . . . . . . 158 + 8.2.6. Stateid Use for SETATTR Operations . . . . . . . . . 159 + 8.3. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 159 + 8.4. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 161 + 8.4.1. Client Failure and Recovery . . . . . . . . . . . . 162 + 8.4.2. Server Failure and Recovery . . . . . . . . . . . . 162 + 8.4.3. Network Partitions and Recovery . . . . . . . . . . 166 + 8.5. Server Revocation of Locks . . . . . . . . . . . . . . . 171 + 8.6. Short and Long Leases . . . . . . . . . . . . . . . . . 172 8.7. Clocks, Propagation Delay, and Calculating Lease - Expiration . . . . . . . . . . . . . . . . . . . . . . . 171 - 8.8. Obsolete Locking Infrastructure From NFSv4.0 . . . . . . 172 - 9. File Locking and Share Reservations . . . . . . . . . . . . . 173 - 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 173 - 9.1.1. State-owner Definition . . . . . . . . . . . . . . . 173 - 9.1.2. Use of the Stateid and Locking . . . . . . . . . . . 174 - 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 177 - 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 177 - 9.4. Stateid Seqid Values and Byte-Range Locks . . . . . . . 178 - 9.5. Issues with Multiple Open-Owners . . . . . . . . . . . . 178 - 9.6. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 179 - 9.7. Share Reservations . . . . . . . . . . . . . . . . . . . 180 - 9.8. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 180 - 9.9. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 181 - 9.10. Parallel OPENs . . . . . . . . . . . . . . . . . . . . . 182 - 9.11. Reclaim of Open and Byte-Range Locks . . . . . . . . . . 183 - 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 183 - 10.1. Performance Challenges for Client-Side Caching . . . . . 184 - 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 185 - 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 187 - 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 189 - 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 189 - 10.3.2. Data Caching and File Locking . . . . . . . . . . . 190 - 10.3.3. Data Caching and Mandatory File Locking . . . . . . 192 - 10.3.4. Data Caching and File Identity . . . . . . . . . . . 192 - 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 194 - 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 196 - 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 197 - 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 198 - 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 201 - 10.4.5. Clients that Fail to Honor Delegation Recalls . . . 203 - 10.4.6. Delegation Revocation . . . . . . . . . . . . . . . 203 - 10.4.7. Delegations via WANT_DELEGATION . . . . . . . . . . 204 - 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 205 - 10.5.1. Revocation Recovery for Write Open Delegation . . . 205 - 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 206 - 10.7. Data and Metadata Caching and Memory Mapped Files . . . 208 + Expiration . . . . . . . . . . . . . . . . . . . . . . . 172 + 8.8. Obsolete Locking Infrastructure From NFSv4.0 . . . . . . 173 + 9. File Locking and Share Reservations . . . . . . . . . . . . . 174 + 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 174 + 9.1.1. State-owner Definition . . . . . . . . . . . . . . . 174 + 9.1.2. Use of the Stateid and Locking . . . . . . . . . . . 175 + 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 178 + 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 178 + 9.4. Stateid Seqid Values and Byte-Range Locks . . . . . . . 179 + 9.5. Issues with Multiple Open-Owners . . . . . . . . . . . . 179 + 9.6. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 180 + 9.7. Share Reservations . . . . . . . . . . . . . . . . . . . 181 + 9.8. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 181 + 9.9. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 182 + 9.10. Parallel OPENs . . . . . . . . . . . . . . . . . . . . . 183 + 9.11. Reclaim of Open and Byte-Range Locks . . . . . . . . . . 184 + 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 184 + 10.1. Performance Challenges for Client-Side Caching . . . . . 185 + 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 186 + 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 188 + 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 190 + 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 190 + 10.3.2. Data Caching and File Locking . . . . . . . . . . . 191 + 10.3.3. Data Caching and Mandatory File Locking . . . . . . 193 + 10.3.4. Data Caching and File Identity . . . . . . . . . . . 193 + 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 195 + 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 197 + 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 198 + 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 199 + 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 202 + 10.4.5. Clients that Fail to Honor Delegation Recalls . . . 204 + 10.4.6. Delegation Revocation . . . . . . . . . . . . . . . 204 + 10.4.7. Delegations via WANT_DELEGATION . . . . . . . . . . 205 + 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 206 + 10.5.1. Revocation Recovery for Write Open Delegation . . . 206 + 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 207 + 10.7. Data and Metadata Caching and Memory Mapped Files . . . 209 10.8. Name and Directory Caching without Directory - Delegations . . . . . . . . . . . . . . . . . . . . . . 210 - 10.8.1. Name Caching . . . . . . . . . . . . . . . . . . . . 210 - 10.8.2. Directory Caching . . . . . . . . . . . . . . . . . 212 - 10.9. Directory Delegations . . . . . . . . . . . . . . . . . 213 - 10.9.1. Introduction to Directory Delegations . . . . . . . 213 - 10.9.2. Directory Delegation Design . . . . . . . . . . . . 214 - 10.9.3. Attributes in Support of Directory Notifications . . 215 - 10.9.4. Directory Delegation Recall . . . . . . . . . . . . 215 - 10.9.5. Directory Delegation Recovery . . . . . . . . . . . 216 - 11. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 216 - 11.1. Location Attributes . . . . . . . . . . . . . . . . . . 216 - 11.2. File System Presence or Absence . . . . . . . . . . . . 217 - 11.3. Getting Attributes for an Absent File System . . . . . . 218 - 11.3.1. GETATTR Within an Absent File System . . . . . . . . 218 - 11.3.2. READDIR and Absent File Systems . . . . . . . . . . 219 - 11.4. Uses of Location Information . . . . . . . . . . . . . . 220 - 11.4.1. File System Replication . . . . . . . . . . . . . . 221 - 11.4.2. File System Migration . . . . . . . . . . . . . . . 221 - 11.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 223 - 11.5. Location Entries and Server Identity . . . . . . . . . . 224 - 11.6. Additional Client-side Considerations . . . . . . . . . 225 - 11.7. Effecting File System Transitions . . . . . . . . . . . 225 - 11.7.1. File System Transitions and Simultaneous Access . . 227 - 11.7.2. Simultaneous Use and Transparent Transitions . . . . 227 - 11.7.3. Filehandles and File System Transitions . . . . . . 230 - 11.7.4. Fileids and File System Transitions . . . . . . . . 230 - 11.7.5. Fsids and File System Transitions . . . . . . . . . 232 - 11.7.6. The Change Attribute and File System Transitions . . 232 - 11.7.7. Lock State and File System Transitions . . . . . . . 233 - 11.7.8. Write Verifiers and File System Transitions . . . . 237 + Delegations . . . . . . . . . . . . . . . . . . . . . . 211 + 10.8.1. Name Caching . . . . . . . . . . . . . . . . . . . . 211 + 10.8.2. Directory Caching . . . . . . . . . . . . . . . . . 213 + 10.9. Directory Delegations . . . . . . . . . . . . . . . . . 214 + 10.9.1. Introduction to Directory Delegations . . . . . . . 214 + 10.9.2. Directory Delegation Design . . . . . . . . . . . . 215 + 10.9.3. Attributes in Support of Directory Notifications . . 216 + 10.9.4. Directory Delegation Recall . . . . . . . . . . . . 216 + 10.9.5. Directory Delegation Recovery . . . . . . . . . . . 217 + 11. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 217 + 11.1. Location Attributes . . . . . . . . . . . . . . . . . . 217 + 11.2. File System Presence or Absence . . . . . . . . . . . . 218 + 11.3. Getting Attributes for an Absent File System . . . . . . 219 + 11.3.1. GETATTR Within an Absent File System . . . . . . . . 219 + 11.3.2. READDIR and Absent File Systems . . . . . . . . . . 220 + 11.4. Uses of Location Information . . . . . . . . . . . . . . 221 + 11.4.1. File System Replication . . . . . . . . . . . . . . 222 + 11.4.2. File System Migration . . . . . . . . . . . . . . . 222 + 11.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 224 + 11.5. Location Entries and Server Identity . . . . . . . . . . 225 + 11.6. Additional Client-side Considerations . . . . . . . . . 226 + 11.7. Effecting File System Transitions . . . . . . . . . . . 226 + 11.7.1. File System Transitions and Simultaneous Access . . 228 + 11.7.2. Simultaneous Use and Transparent Transitions . . . . 228 + 11.7.3. Filehandles and File System Transitions . . . . . . 231 + 11.7.4. Fileids and File System Transitions . . . . . . . . 231 + 11.7.5. Fsids and File System Transitions . . . . . . . . . 233 + 11.7.6. The Change Attribute and File System Transitions . . 233 + 11.7.7. Lock State and File System Transitions . . . . . . . 234 + 11.7.8. Write Verifiers and File System Transitions . . . . 238 11.7.9. Readdir Cookies and Verifiers and File System - Transitions . . . . . . . . . . . . . . . . . . . . 237 - 11.7.10. File System Data and File System Transitions . . . . 237 - 11.8. Effecting File System Referrals . . . . . . . . . . . . 239 - 11.8.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 239 - 11.8.2. Referral Example (READDIR) . . . . . . . . . . . . . 243 - 11.9. The Attribute fs_locations . . . . . . . . . . . . . . . 245 - 11.10. The Attribute fs_locations_info . . . . . . . . . . . . 248 - 11.10.1. The fs_locations_server4 Structure . . . . . . . . . 252 - 11.10.2. The fs_locations_info4 Structure . . . . . . . . . . 257 - 11.10.3. The fs_locations_item4 Structure . . . . . . . . . . 258 - 11.11. The Attribute fs_status . . . . . . . . . . . . . . . . 260 - 12. Parallel NFS (pNFS) . . . . . . . . . . . . . . . . . . . . . 264 - 12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 264 - 12.2. pNFS Definitions . . . . . . . . . . . . . . . . . . . . 265 - 12.2.1. Metadata . . . . . . . . . . . . . . . . . . . . . . 266 - 12.2.2. Metadata Server . . . . . . . . . . . . . . . . . . 266 - 12.2.3. pNFS Client . . . . . . . . . . . . . . . . . . . . 266 - 12.2.4. Storage Device . . . . . . . . . . . . . . . . . . . 266 - 12.2.5. Storage Protocol . . . . . . . . . . . . . . . . . . 266 - 12.2.6. Control Protocol . . . . . . . . . . . . . . . . . . 267 - 12.2.7. Layout Types . . . . . . . . . . . . . . . . . . . . 267 - 12.2.8. Layout . . . . . . . . . . . . . . . . . . . . . . . 268 - 12.2.9. Layout Iomode . . . . . . . . . . . . . . . . . . . 268 - 12.2.10. Device IDs . . . . . . . . . . . . . . . . . . . . . 269 - 12.3. pNFS Operations . . . . . . . . . . . . . . . . . . . . 270 - 12.4. pNFS Attributes . . . . . . . . . . . . . . . . . . . . 271 - 12.5. Layout Semantics . . . . . . . . . . . . . . . . . . . . 271 - 12.5.1. Guarantees Provided by Layouts . . . . . . . . . . . 271 - 12.5.2. Getting a Layout . . . . . . . . . . . . . . . . . . 272 - 12.5.3. Layout Stateid . . . . . . . . . . . . . . . . . . . 273 - 12.5.4. Committing a Layout . . . . . . . . . . . . . . . . 274 - 12.5.5. Recalling a Layout . . . . . . . . . . . . . . . . . 278 - 12.5.6. Revoking Layouts . . . . . . . . . . . . . . . . . . 285 - 12.5.7. Metadata Server Write Propagation . . . . . . . . . 285 - 12.6. pNFS Mechanics . . . . . . . . . . . . . . . . . . . . . 286 - 12.7. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 287 - 12.7.1. Recovery from Client Restart . . . . . . . . . . . . 287 - 12.7.2. Dealing with Lease Expiration on the Client . . . . 288 + Transitions . . . . . . . . . . . . . . . . . . . . 238 + 11.7.10. File System Data and File System Transitions . . . . 238 + 11.8. Effecting File System Referrals . . . . . . . . . . . . 240 + 11.8.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 240 + 11.8.2. Referral Example (READDIR) . . . . . . . . . . . . . 244 + 11.9. The Attribute fs_locations . . . . . . . . . . . . . . . 246 + 11.10. The Attribute fs_locations_info . . . . . . . . . . . . 249 + 11.10.1. The fs_locations_server4 Structure . . . . . . . . . 253 + 11.10.2. The fs_locations_info4 Structure . . . . . . . . . . 258 + 11.10.3. The fs_locations_item4 Structure . . . . . . . . . . 259 + 11.11. The Attribute fs_status . . . . . . . . . . . . . . . . 261 + 12. Parallel NFS (pNFS) . . . . . . . . . . . . . . . . . . . . . 265 + 12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 265 + 12.2. pNFS Definitions . . . . . . . . . . . . . . . . . . . . 266 + 12.2.1. Metadata . . . . . . . . . . . . . . . . . . . . . . 267 + 12.2.2. Metadata Server . . . . . . . . . . . . . . . . . . 267 + 12.2.3. pNFS Client . . . . . . . . . . . . . . . . . . . . 267 + 12.2.4. Storage Device . . . . . . . . . . . . . . . . . . . 267 + 12.2.5. Storage Protocol . . . . . . . . . . . . . . . . . . 267 + 12.2.6. Control Protocol . . . . . . . . . . . . . . . . . . 268 + 12.2.7. Layout Types . . . . . . . . . . . . . . . . . . . . 268 + 12.2.8. Layout . . . . . . . . . . . . . . . . . . . . . . . 269 + 12.2.9. Layout Iomode . . . . . . . . . . . . . . . . . . . 269 + 12.2.10. Device IDs . . . . . . . . . . . . . . . . . . . . . 270 + 12.3. pNFS Operations . . . . . . . . . . . . . . . . . . . . 271 + 12.4. pNFS Attributes . . . . . . . . . . . . . . . . . . . . 272 + 12.5. Layout Semantics . . . . . . . . . . . . . . . . . . . . 272 + 12.5.1. Guarantees Provided by Layouts . . . . . . . . . . . 272 + 12.5.2. Getting a Layout . . . . . . . . . . . . . . . . . . 273 + 12.5.3. Layout Stateid . . . . . . . . . . . . . . . . . . . 274 + 12.5.4. Committing a Layout . . . . . . . . . . . . . . . . 275 + 12.5.5. Recalling a Layout . . . . . . . . . . . . . . . . . 279 + 12.5.6. Revoking Layouts . . . . . . . . . . . . . . . . . . 286 + 12.5.7. Metadata Server Write Propagation . . . . . . . . . 286 + 12.6. pNFS Mechanics . . . . . . . . . . . . . . . . . . . . . 287 + 12.7. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 288 + 12.7.1. Recovery from Client Restart . . . . . . . . . . . . 288 + 12.7.2. Dealing with Lease Expiration on the Client . . . . 289 12.7.3. Dealing with Loss of Layout State on the Metadata - Server . . . . . . . . . . . . . . . . . . . . . . . 289 - 12.7.4. Recovery from Metadata Server Restart . . . . . . . 289 - 12.7.5. Operations During Metadata Server Grace Period . . . 291 - 12.7.6. Storage Device Recovery . . . . . . . . . . . . . . 292 - 12.8. Metadata and Storage Device Roles . . . . . . . . . . . 292 - 12.9. Security Considerations for pNFS . . . . . . . . . . . . 293 - 13. PNFS: NFSv4.1 File Layout Type . . . . . . . . . . . . . . . 294 - 13.1. Client ID and Session Considerations . . . . . . . . . . 294 - 13.1.1. Sessions Considerations for Data Servers . . . . . . 296 - 13.2. File Layout Definitions . . . . . . . . . . . . . . . . 297 - 13.3. File Layout Data Types . . . . . . . . . . . . . . . . . 297 - 13.4. Interpreting the File Layout . . . . . . . . . . . . . . 301 - 13.4.1. Determining the Stripe Unit Number . . . . . . . . . 301 - 13.4.2. Interpreting the File Layout Using Sparse Packing . 301 - 13.4.3. Interpreting the File Layout Using Dense Packing . . 304 - 13.4.4. Sparse and Dense Stripe Unit Packing . . . . . . . . 306 - 13.5. Data Server Multipathing . . . . . . . . . . . . . . . . 308 - 13.6. Operations Sent to NFSv4.1 Data Servers . . . . . . . . 309 - 13.7. COMMIT Through Metadata Server . . . . . . . . . . . . . 311 - 13.8. The Layout Iomode . . . . . . . . . . . . . . . . . . . 313 - 13.9. Metadata and Data Server State Coordination . . . . . . 313 - 13.9.1. Global Stateid Requirements . . . . . . . . . . . . 313 - 13.9.2. Data Server State Propagation . . . . . . . . . . . 314 - 13.10. Data Server Component File Size . . . . . . . . . . . . 316 - 13.11. Layout Revocation and Fencing . . . . . . . . . . . . . 317 - 13.12. Security Considerations for the File Layout Type . . . . 317 - 14. Internationalization . . . . . . . . . . . . . . . . . . . . 318 - 14.1. Stringprep profile for the utf8str_cs type . . . . . . . 319 - 14.2. Stringprep profile for the utf8str_cis type . . . . . . 321 - 14.3. Stringprep profile for the utf8str_mixed type . . . . . 322 - 14.4. UTF-8 Capabilities . . . . . . . . . . . . . . . . . . . 324 - 14.5. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 324 - 15. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 325 - 15.1. Error Definitions . . . . . . . . . . . . . . . . . . . 325 - 15.1.1. General Errors . . . . . . . . . . . . . . . . . . . 327 - 15.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 329 - 15.1.3. Compound Structure Errors . . . . . . . . . . . . . 330 - 15.1.4. File System Errors . . . . . . . . . . . . . . . . . 332 - 15.1.5. State Management Errors . . . . . . . . . . . . . . 334 - 15.1.6. Security Errors . . . . . . . . . . . . . . . . . . 335 - 15.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 335 - 15.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 336 - 15.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 337 - 15.1.10. pNFS Errors . . . . . . . . . . . . . . . . . . . . 338 - 15.1.11. Session Use Errors . . . . . . . . . . . . . . . . . 339 - 15.1.12. Session Management Errors . . . . . . . . . . . . . 341 - 15.1.13. Client Management Errors . . . . . . . . . . . . . . 341 - 15.1.14. Delegation Errors . . . . . . . . . . . . . . . . . 342 - 15.1.15. Attribute Handling Errors . . . . . . . . . . . . . 342 - 15.1.16. Obsoleted Errors . . . . . . . . . . . . . . . . . . 343 - 15.2. Operations and their valid errors . . . . . . . . . . . 344 - 15.3. Callback operations and their valid errors . . . . . . . 360 - 15.4. Errors and the operations that use them . . . . . . . . 362 - 16. NFSv4.1 Procedures . . . . . . . . . . . . . . . . . . . . . 376 - 16.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 376 - 16.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 377 - 17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 388 - 18. NFSv4.1 Operations . . . . . . . . . . . . . . . . . . . . . 391 - 18.1. Operation 3: ACCESS - Check Access Rights . . . . . . . 391 - 18.2. Operation 4: CLOSE - Close File . . . . . . . . . . . . 397 - 18.3. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 398 - 18.4. Operation 6: CREATE - Create a Non-Regular File Object . 401 + Server . . . . . . . . . . . . . . . . . . . . . . . 290 + 12.7.4. Recovery from Metadata Server Restart . . . . . . . 290 + 12.7.5. Operations During Metadata Server Grace Period . . . 292 + 12.7.6. Storage Device Recovery . . . . . . . . . . . . . . 293 + 12.8. Metadata and Storage Device Roles . . . . . . . . . . . 293 + 12.9. Security Considerations for pNFS . . . . . . . . . . . . 294 + 13. PNFS: NFSv4.1 File Layout Type . . . . . . . . . . . . . . . 295 + 13.1. Client ID and Session Considerations . . . . . . . . . . 295 + 13.1.1. Sessions Considerations for Data Servers . . . . . . 297 + 13.2. File Layout Definitions . . . . . . . . . . . . . . . . 298 + 13.3. File Layout Data Types . . . . . . . . . . . . . . . . . 298 + 13.4. Interpreting the File Layout . . . . . . . . . . . . . . 302 + 13.4.1. Determining the Stripe Unit Number . . . . . . . . . 302 + 13.4.2. Interpreting the File Layout Using Sparse Packing . 302 + 13.4.3. Interpreting the File Layout Using Dense Packing . . 305 + 13.4.4. Sparse and Dense Stripe Unit Packing . . . . . . . . 307 + 13.5. Data Server Multipathing . . . . . . . . . . . . . . . . 309 + 13.6. Operations Sent to NFSv4.1 Data Servers . . . . . . . . 310 + 13.7. COMMIT Through Metadata Server . . . . . . . . . . . . . 312 + 13.8. The Layout Iomode . . . . . . . . . . . . . . . . . . . 314 + 13.9. Metadata and Data Server State Coordination . . . . . . 314 + 13.9.1. Global Stateid Requirements . . . . . . . . . . . . 314 + 13.9.2. Data Server State Propagation . . . . . . . . . . . 315 + 13.10. Data Server Component File Size . . . . . . . . . . . . 317 + 13.11. Layout Revocation and Fencing . . . . . . . . . . . . . 318 + 13.12. Security Considerations for the File Layout Type . . . . 318 + 14. Internationalization . . . . . . . . . . . . . . . . . . . . 319 + 14.1. Stringprep profile for the utf8str_cs type . . . . . . . 320 + 14.2. Stringprep profile for the utf8str_cis type . . . . . . 322 + 14.3. Stringprep profile for the utf8str_mixed type . . . . . 323 + 14.4. UTF-8 Capabilities . . . . . . . . . . . . . . . . . . . 325 + 14.5. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 325 + 15. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 326 + 15.1. Error Definitions . . . . . . . . . . . . . . . . . . . 326 + 15.1.1. General Errors . . . . . . . . . . . . . . . . . . . 328 + 15.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 330 + 15.1.3. Compound Structure Errors . . . . . . . . . . . . . 331 + 15.1.4. File System Errors . . . . . . . . . . . . . . . . . 333 + 15.1.5. State Management Errors . . . . . . . . . . . . . . 335 + 15.1.6. Security Errors . . . . . . . . . . . . . . . . . . 336 + 15.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 336 + 15.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 337 + 15.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 338 + 15.1.10. pNFS Errors . . . . . . . . . . . . . . . . . . . . 339 + 15.1.11. Session Use Errors . . . . . . . . . . . . . . . . . 340 + 15.1.12. Session Management Errors . . . . . . . . . . . . . 342 + 15.1.13. Client Management Errors . . . . . . . . . . . . . . 342 + 15.1.14. Delegation Errors . . . . . . . . . . . . . . . . . 343 + 15.1.15. Attribute Handling Errors . . . . . . . . . . . . . 343 + 15.1.16. Obsoleted Errors . . . . . . . . . . . . . . . . . . 344 + 15.2. Operations and their valid errors . . . . . . . . . . . 345 + 15.3. Callback operations and their valid errors . . . . . . . 361 + 15.4. Errors and the operations that use them . . . . . . . . 363 + 16. NFSv4.1 Procedures . . . . . . . . . . . . . . . . . . . . . 377 + 16.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 377 + 16.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 378 + 17. Operations: REQUIRED, RECOMMENDED, or OPTIONAL . . . . . . . 389 + 18. NFSv4.1 Operations . . . . . . . . . . . . . . . . . . . . . 392 + 18.1. Operation 3: ACCESS - Check Access Rights . . . . . . . 392 + 18.2. Operation 4: CLOSE - Close File . . . . . . . . . . . . 398 + 18.3. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 399 + 18.4. Operation 6: CREATE - Create a Non-Regular File Object . 402 18.5. Operation 7: DELEGPURGE - Purge Delegations Awaiting - Recovery . . . . . . . . . . . . . . . . . . . . . . . . 404 - 18.6. Operation 8: DELEGRETURN - Return Delegation . . . . . . 405 - 18.7. Operation 9: GETATTR - Get Attributes . . . . . . . . . 405 - 18.8. Operation 10: GETFH - Get Current Filehandle . . . . . . 407 - 18.9. Operation 11: LINK - Create Link to a File . . . . . . . 408 - 18.10. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 411 - 18.11. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 415 - 18.12. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 416 - 18.13. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 418 - 18.14. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 419 + Recovery . . . . . . . . . . . . . . . . . . . . . . . . 405 + 18.6. Operation 8: DELEGRETURN - Return Delegation . . . . . . 406 + 18.7. Operation 9: GETATTR - Get Attributes . . . . . . . . . 406 + 18.8. Operation 10: GETFH - Get Current Filehandle . . . . . . 408 + 18.9. Operation 11: LINK - Create Link to a File . . . . . . . 409 + 18.10. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 412 + 18.11. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 416 + 18.12. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 417 + 18.13. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 419 + 18.14. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 420 18.15. Operation 17: NVERIFY - Verify Difference in - Attributes . . . . . . . . . . . . . . . . . . . . . . . 421 - 18.16. Operation 18: OPEN - Open a Regular File . . . . . . . . 422 + Attributes . . . . . . . . . . . . . . . . . . . . . . . 422 + 18.16. Operation 18: OPEN - Open a Regular File . . . . . . . . 423 18.17. Operation 19: OPENATTR - Open Named Attribute - Directory . . . . . . . . . . . . . . . . . . . . . . . 441 - 18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 442 - 18.19. Operation 22: PUTFH - Set Current Filehandle . . . . . . 444 - 18.20. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 444 - 18.21. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 446 - 18.22. Operation 25: READ - Read from File . . . . . . . . . . 447 - 18.23. Operation 26: READDIR - Read Directory . . . . . . . . . 449 - 18.24. Operation 27: READLINK - Read Symbolic Link . . . . . . 453 - 18.25. Operation 28: REMOVE - Remove File System Object . . . . 454 - 18.26. Operation 29: RENAME - Rename Directory Entry . . . . . 456 - 18.27. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 460 - 18.28. Operation 32: SAVEFH - Save Current Filehandle . . . . . 461 - 18.29. Operation 33: SECINFO - Obtain Available Security . . . 462 - 18.30. Operation 34: SETATTR - Set Attributes . . . . . . . . . 465 - 18.31. Operation 37: VERIFY - Verify Same Attributes . . . . . 468 - 18.32. Operation 38: WRITE - Write to File . . . . . . . . . . 469 - 18.33. Operation 40: BACKCHANNEL_CTL - Backchannel control . . 474 - 18.34. Operation 41: BIND_CONN_TO_SESSION . . . . . . . . . . . 475 - 18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 478 + Directory . . . . . . . . . . . . . . . . . . . . . . . 442 + 18.18. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 443 + 18.19. Operation 22: PUTFH - Set Current Filehandle . . . . . . 445 + 18.20. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 445 + 18.21. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 447 + 18.22. Operation 25: READ - Read from File . . . . . . . . . . 448 + 18.23. Operation 26: READDIR - Read Directory . . . . . . . . . 450 + 18.24. Operation 27: READLINK - Read Symbolic Link . . . . . . 454 + 18.25. Operation 28: REMOVE - Remove File System Object . . . . 455 + 18.26. Operation 29: RENAME - Rename Directory Entry . . . . . 457 + 18.27. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 461 + 18.28. Operation 32: SAVEFH - Save Current Filehandle . . . . . 462 + 18.29. Operation 33: SECINFO - Obtain Available Security . . . 463 + 18.30. Operation 34: SETATTR - Set Attributes . . . . . . . . . 467 + 18.31. Operation 37: VERIFY - Verify Same Attributes . . . . . 470 + 18.32. Operation 38: WRITE - Write to File . . . . . . . . . . 471 + 18.33. Operation 40: BACKCHANNEL_CTL - Backchannel control . . 475 + 18.34. Operation 41: BIND_CONN_TO_SESSION . . . . . . . . . . . 477 + 18.35. Operation 42: EXCHANGE_ID - Instantiate Client ID . . . 479 18.36. Operation 43: CREATE_SESSION - Create New Session and - Confirm Client ID . . . . . . . . . . . . . . . . . . . 494 + Confirm Client ID . . . . . . . . . . . . . . . . . . . 495 18.37. Operation 44: DESTROY_SESSION - Destroy existing - session . . . . . . . . . . . . . . . . . . . . . . . . 504 + session . . . . . . . . . . . . . . . . . . . . . . . . 505 18.38. Operation 45: FREE_STATEID - Free stateid with no - locks . . . . . . . . . . . . . . . . . . . . . . . . . 506 + locks . . . . . . . . . . . . . . . . . . . . . . . . . 507 18.39. Operation 46: GET_DIR_DELEGATION - Get a directory - delegation . . . . . . . . . . . . . . . . . . . . . . . 507 - 18.40. Operation 47: GETDEVICEINFO - Get Device Information . . 511 + delegation . . . . . . . . . . . . . . . . . . . . . . . 508 + 18.40. Operation 47: GETDEVICEINFO - Get Device Information . . 512 18.41. Operation 48: GETDEVICELIST - Get All Device Mappings - for a File System . . . . . . . . . . . . . . . . . . . 513 + for a File System . . . . . . . . . . . . . . . . . . . 514 18.42. Operation 49: LAYOUTCOMMIT - Commit writes made using - a layout . . . . . . . . . . . . . . . . . . . . . . . . 515 - 18.43. Operation 50: LAYOUTGET - Get Layout Information . . . . 518 + a layout . . . . . . . . . . . . . . . . . . . . . . . . 516 + 18.43. Operation 50: LAYOUTGET - Get Layout Information . . . . 519 18.44. Operation 51: LAYOUTRETURN - Release Layout - Information . . . . . . . . . . . . . . . . . . . . . . 522 + Information . . . . . . . . . . . . . . . . . . . . . . 523 18.45. Operation 52: SECINFO_NO_NAME - Get Security on - Unnamed Object . . . . . . . . . . . . . . . . . . . . . 527 + Unnamed Object . . . . . . . . . . . . . . . . . . . . . 528 18.46. Operation 53: SEQUENCE - Supply per-procedure - sequencing and control . . . . . . . . . . . . . . . . . 528 - 18.47. Operation 54: SET_SSV - Update SSV for a Client ID . . . 534 + sequencing and control . . . . . . . . . . . . . . . . . 529 + 18.47. Operation 54: SET_SSV - Update SSV for a Client ID . . . 535 18.48. Operation 55: TEST_STATEID - Test stateids for - validity . . . . . . . . . . . . . . . . . . . . . . . . 536 - 18.49. Operation 56: WANT_DELEGATION - Request Delegation . . . 538 + validity . . . . . . . . . . . . . . . . . . . . . . . . 537 + 18.49. Operation 56: WANT_DELEGATION - Request Delegation . . . 539 18.50. Operation 57: DESTROY_CLIENTID - Destroy existing client ID . . . . . . . . . . . . . . . . . . . . . . . 542 18.51. Operation 58: RECLAIM_COMPLETE - Indicates Reclaims Finished . . . . . . . . . . . . . . . . . . . . . . . . 542 18.52. Operation 10044: ILLEGAL - Illegal operation . . . . . . 545 19. NFSv4.1 Callback Procedures . . . . . . . . . . . . . . . . . 545 19.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 546 19.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 546 20. NFSv4.1 Callback Operations . . . . . . . . . . . . . . . . . 550 20.1. Operation 3: CB_GETATTR - Get Attributes . . . . . . . . 550 @@ -1383,43 +1383,54 @@ communication with the server, the client may receive an NFS error of NFS4ERR_WRONGSEC. This error allows the server to notify the client that the security tuple currently being used contravenes the server's security policy. The client is then responsible for determining (see Section 2.6.3.1) what security tuples are available at the server and choosing one which is appropriate for the client. 2.6.3.1. Using NFS4ERR_WRONGSEC, SECINFO, and SECINFO_NO_NAME This section explains of the mechanics of NFSv4.1 security - negotiation. The term "put filehandle operation" refers to - PUTROOTFH, PUTPUBFH, PUTFH, and RESTOREFH. + negotiation. -2.6.3.1.1. Put Filehandle Operation + SAVEFH +2.6.3.1.1. Put Filehandle Operations - The client is saving a filehandle for a future RESTOREFH. The server - MUST NOT return NFS4ERR_WRONGSEC to either the put filehandle - operation or SAVEFH. + The term "put filehandle operation" refers to PUTROOTFH, PUTPUBFH, + PUTFH, and RESTOREFH. Each of the subsections herein describes how + the server handles a subseries of operations that starts with a put + filehandle operation. -2.6.3.1.2. Two or More Put Filehandle Operations +2.6.3.1.1.1. Put Filehandle Operation + SAVEFH + + The client is saving a filehandle for a future RESTOREFH, LINK, or + RENAME. SAVEFH MUST NOT return NFS4ERR_WRONGSEC. To determine + whether the put filehandle operation returns NFS4ERR_WRONGSEC or not, + the server implementation pretends SAVEFH is not in the series of + operations and examines which of the situations described in the + other subsections of Section 2.6.3.1.1 apply. + +2.6.3.1.1.2. Two or More Put Filehandle Operations For a series of N put filehandle operations, the server MUST NOT return NFS4ERR_WRONGSEC to the first N-1 put filehandle operations. The N'th put filehandle operation is handled as if it is the first in a subseries of operations. For example if the server received PUTFH, PUTROOTFH, LOOKUP, then the PUTFH is ignored for NFS4ERR_WRONGSEC purposes, and the PUTROOTFH, LOOKUP subseries is processed as - according to Section 2.6.3.1.3. + according to Section 2.6.3.1.1.3. -2.6.3.1.3. Put Filehandle Operation + LOOKUP (or OPEN by Name) +2.6.3.1.1.3. Put Filehandle Operation + LOOKUP (or OPEN of an Existing + Name) This situation also applies to a put filehandle operation followed by - a LOOKUP or an OPEN operation that specifies a component name. + a LOOKUP or an OPEN operation that specifies an existing component + name. In this situation, the client is potentially crossing a security policy boundary, and the set of security tuples the parent directory supports may differ from those of the child. The server implementation may decide whether to impose any restrictions on security policy administration. There are at least three approaches (sec_policy_child is the tuple set of the child export, sec_policy_parent is that of the parent). a) sec_policy_child <= sec_policy_parent (<= for subset). This @@ -1431,57 +1442,58 @@ {} for the empty set). This means that the security tuples specified on the security policy of a child directory always has a non empty intersection with that of the parent. c) sec_policy_child ^ sec_policy_parent == {}. This means that the set of tuples specified on the security policy of a child directory may not intersect with that of the parent. In other words, there are no restrictions on how the system administrator may set up these tuples. - For a server to support approach (b) (when client chooses a flavor - that is not a member of sec_policy_parent) and (c), the put - filehandle operation must NOT return NFS4ERR_WRONGSEC when there is a - security tuple mismatch. Instead, it should be returned from the - LOOKUP (or OPEN by component name) that follows. + In order for a server to support approaches (b) (for the case when a + client chooses a flavor that is not a member of sec_policy_parent) + and (c), the put filehandle operation cannot return NFS4ERR_WRONGSEC + when there is a security tuple mismatch. Instead, it should be + returned from the LOOKUP (or OPEN by existing component name) that + follows. Since the above guideline does not contradict approach (a), it should be followed in general. Even if approach (a) is implemented, it is possible for the security tuple used to be acceptable for the target of LOOKUP but not for the filehandles used in the put filehandle operation. The put filehandle operation could be a PUTROOTFH or PUTPUBFH, where the client cannot know the security tuples for the root or public filehandle. Or the security policy for the filehandle used by the put filehandle operation could have changed since the time the filehandle was obtained. Therefore, an NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC in response to the put filehandle operation if the operation is immediately followed by a LOOKUP or an OPEN by component name. -2.6.3.1.4. Put Filehandle Operation + LOOKUPP +2.6.3.1.1.4. Put Filehandle Operation + LOOKUPP Since SECINFO only works its way down, there is no way LOOKUPP can return NFS4ERR_WRONGSEC without SECINFO_NO_NAME. SECINFO_NO_NAME solves this issue via style SECINFO_STYLE4_PARENT, which works in the - opposite direction as SECINFO. As with Section 2.6.3.1.3, a put + opposite direction as SECINFO. As with Section 2.6.3.1.1.3, a put filehandle operation that is followed by a LOOKUPP MUST NOT return NFS4ERR_WRONGSEC. If the server does not support SECINFO_NO_NAME, the client's only recourse is to send the put filehandle operation, LOOKUPP, GETFH sequence of operations with every security tuple it supports. Regardless of whether SECINFO_NO_NAME is supported, an NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC in response to a put filehandle operation if the operation is immediately followed by a LOOKUPP. -2.6.3.1.5. Put Filehandle Operation + SECINFO/SECINFO_NO_NAME +2.6.3.1.1.5. Put Filehandle Operation + SECINFO/SECINFO_NO_NAME A security sensitive client is allowed to choose a strong security tuple when querying a server to determine a file object's permitted security tuples. The security tuple chosen by the client does not have to be included in the tuple list of the security policy of the either parent directory indicated in the put filehandle operation, or the child file object indicated in SECINFO (or any parent directory indicated in SECINFO_NO_NAME). Of course the server has to be configured for whatever security tuple the client selects, otherwise the request will fail at RPC layer with an appropriate authentication @@ -1491,54 +1503,91 @@ SECINFO or SECINFO_NO_NAME and those supported by the security policy. But in practice, the client may start looking for strong flavors from those supported by the security policy, followed by those in the REQUIRED set. The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC to a put filehandle operation that is immediately followed by SECINFO or SECINFO_NO_NAME. The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC from SECINFO or SECINFO_NO_NAME. -2.6.3.1.6. Put Filehandle Operation + Nothing +2.6.3.1.1.6. Put Filehandle Operation + Nothing The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC. -2.6.3.1.7. Put Filehandle Operation + Anything Else +2.6.3.1.1.7. Put Filehandle Operation + Anything Else "Anything Else" includes OPEN by filehandle. The security policy enforcement applies to the filehandle specified in the put filehandle operation. Therefore the put filehandle operation must return NFS4ERR_WRONGSEC when there is a security tuple mismatch. This avoids the complexity adding NFS4ERR_WRONGSEC as an allowable error to every other operation. A COMPOUND containing the series put filehandle operation + SECINFO_NO_NAME (style SECINFO_STYLE4_CURRENT_FH) is an efficient way for the client to recover from NFS4ERR_WRONGSEC. The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC to any operation other than a put filehandle operation, LOOKUP, LOOKUPP, and OPEN (by component name). -2.6.3.1.8. Operations after SECINFO and SECINFO_NO_NAME +2.6.3.1.1.8. Operations after SECINFO and SECINFO_NO_NAME Suppose a client sends a COMPOUND procedure containing the series SEQUENCE, PUTFH, SECINFO_NONAME, READ, and suppose the security tuple used does not match that required for the target file. By rule (see - Section 2.6.3.1.5), neither PUTFH nor SECINFO_NO_NAME can return - NFS4ERR_WRONGSEC. By rule (see Section 2.6.3.1.7), READ cannot + Section 2.6.3.1.1.5), neither PUTFH nor SECINFO_NO_NAME can return + NFS4ERR_WRONGSEC. By rule (see Section 2.6.3.1.1.7), READ cannot return NFS4ERR_WRONGSEC. The issue is resolved by the fact that SECINFO and SECINFO_NO_NAME consume the current filehandle (note that this is a change from NFSv4.0). This leaves no current filehandle for READ to use, and READ returns NFS4ERR_NOFILEHANDLE. +2.6.3.1.2. LINK and RENAME + + The LINK and RENAME operations use both the current and saved + filehandles. When the current filehandle is injected into a series + of operations via a put filehandle operation, the server MUST return + NFS4ERR_WRONGSEC, per Section 2.6.3.1.1. LINK and RENAME MAY return + NFS4ERR_WRONGSEC if the security policy of the saved filehandle + rejects the security flavor used in the COMPOUND request's + credentials. If the server does so, then if there is no intersection + between the security policies of saved and current filehandles, this + means it will be impossible for client to perform the intended LINK + or RENAME operation. + + For example, suppose the client sends this COMPOUND request: + SEQUENCE, PUTFH bFH, SAVEFH, PUTFH aFH, RENAME "c" "d", where + filehandles bFH and aFH refer to different directories. Suppose no + common security tuple exists between the security policies of aFH and + bFH. If the client sends the request using credentials acceptable to + bFH's security policy but not aFH's policy, then the PUTFH aFH + operation will fail with NFS4ERR_WRONGSEC. After a SECINFO_NO_NAME + request, the client sends SEQUENCE, PUTFH bFH, SAVEFH, PUTFH aFH, + RENAME "c" "d", using credentials acceptable to aFH's security + policy, but not bFH's policy. The server returns NFS4ERR_WRONGSEC on + the RENAME operation. + + To prevent a client from an endless sequence of a request containing + LINK or RENAME, followed by a request containing SECINFO_NO_NAME, the + server MUST detect when the security policies of the current and + saved filehandles have no mutually acceptable security tuple, and + MUST NOT NFS4ERR_WRONGSEC in that situation. Instead the server MUST + return NFS4ERR_XDEV. + + Thus while a server MAY return NFS4ERR_WRONGSEC from LINK and RENAME, + the server implementor may reasonably decide the consequences are not + worth the security benefits, and so allow the security policy of the + current filehandle to override that of the saved filehandle. + 2.7. Minor Versioning To address the requirement of an NFS protocol that can evolve as the need arises, the NFSv4.1 protocol contains the rules and framework to allow for future minor changes or versioning. The base assumption with respect to minor versioning is that any future accepted minor version must follow the IETF process and be documented in a standards track RFC. Therefore, each minor version number will correspond to an RFC. Minor version zero of the NFSv4 @@ -4628,121 +4675,121 @@ hte columns of the table are: o Name: the name of attribute o Id: the number assigned to the attribute. In the event of conflicts between the assigned number and [12], the latter is authoritative. o Data Type: The XDR data type of the attribute. - o Acc: Access allowed. RD means read-only (GETATTR may retrieve, - SETATTR may not set). WR means write-only (SETATTR may set, - GETATTR may not retrieve). R/W means SETATTR may set, and GETATTR - may retrieve the attribute. + o Acc: Access allowed to the attribute. R means read-only (GETATTR + may retrieve, SETATTR may not set). W means write-only (SETATTR + may set, GETATTR may not retrieve). R W means read/write (GETATTR + may retrieve, SETATTR may set). o Defined in: the section of this specification that describes the attribute. +--------------------+----+------------+-----+------------------+ | Name | Id | Data Type | Acc | Defined in: | +--------------------+----+------------+-----+------------------+ - | supported_attrs | 0 | bitmap4 | RD | Section 5.8.1.1 | - | type | 1 | nfs_ftype4 | RD | Section 5.8.1.2 | - | fh_expire_type | 2 | uint32_t | RD | Section 5.8.1.3 | - | change | 3 | uint64_t | RD | Section 5.8.1.4 | - | size | 4 | uint64_t | R/W | Section 5.8.1.5 | - | link_support | 5 | bool | RD | Section 5.8.1.6 | - | symlink_support | 6 | bool | RD | Section 5.8.1.7 | - | named_attr | 7 | bool | RD | Section 5.8.1.8 | - | fsid | 8 | fsid4 | RD | Section 5.8.1.9 | - | unique_handles | 9 | bool | RD | Section 5.8.1.10 | - | lease_time | 10 | nfs_lease4 | RD | Section 5.8.1.11 | - | rdattr_error | 11 | enum | RD | Section 5.8.1.12 | - | filehandle | 19 | nfs_fh4 | RD | Section 5.8.1.13 | - | suppattr_exclcreat | 75 | bitmap4 | RD | Section 5.8.1.14 | + | supported_attrs | 0 | bitmap4 | R | Section 5.8.1.1 | + | type | 1 | nfs_ftype4 | R | Section 5.8.1.2 | + | fh_expire_type | 2 | uint32_t | R | Section 5.8.1.3 | + | change | 3 | uint64_t | R | Section 5.8.1.4 | + | size | 4 | uint64_t | R W | Section 5.8.1.5 | + | link_support | 5 | bool | R | Section 5.8.1.6 | + | symlink_support | 6 | bool | R | Section 5.8.1.7 | + | named_attr | 7 | bool | R | Section 5.8.1.8 | + | fsid | 8 | fsid4 | R | Section 5.8.1.9 | + | unique_handles | 9 | bool | R | Section 5.8.1.10 | + | lease_time | 10 | nfs_lease4 | R | Section 5.8.1.11 | + | rdattr_error | 11 | enum | R | Section 5.8.1.12 | + | filehandle | 19 | nfs_fh4 | R | Section 5.8.1.13 | + | suppattr_exclcreat | 75 | bitmap4 | R | Section 5.8.1.14 | +--------------------+----+------------+-----+------------------+ Table 4 5.7. RECOMMENDED Attributes - List and Definition References The RECOMMENDED attributes are defined in Table 5. The meanings of the column headers are the same as Table 4; see Section 5.6 for the meanings. +--------------------+----+----------------+-----+------------------+ | Name | Id | Data Type | Acc | Defined in: | +--------------------+----+----------------+-----+------------------+ - | acl | 12 | nfsace4<> | R/W | Section 6.2.1 | - | aclsupport | 13 | uint32_t | RD | Section 6.2.1.2 | - | archive | 14 | bool | R/W | Section 5.8.2.1 | - | cansettime | 15 | bool | RD | Section 5.8.2.2 | - | case_insensitive | 16 | bool | RD | Section 5.8.2.3 | - | case_preserving | 17 | bool | RD | Section 5.8.2.4 | - | change_policy | 60 | chg_policy4 | RD | Section 5.8.2.5 | - | chown_restricted | 18 | bool | RD | Section 5.8.2.6 | - | dacl | 58 | nfsacl41 | R/W | Section 6.2.2 | - | dir_notif_delay | 56 | nfstime4 | RD | Section 5.11.1 | - | dirent_notif_delay | 57 | nfstime4 | RD | Section 5.11.2 | - | fileid | 20 | uint64_t | RD | Section 5.8.2.7 | - | files_avail | 21 | uint64_t | RD | Section 5.8.2.8 | - | files_free | 22 | uint64_t | RD | Section 5.8.2.9 | - | files_total | 23 | uint64_t | RD | Section 5.8.2.10 | - | fs_charset_cap | 76 | uint32_t | RD | Section 5.8.2.11 | - | fs_layout_type | 62 | layouttype4<> | RD | Section 5.12.1 | - | fs_locations | 24 | fs_locations | RD | Section 5.8.2.12 | - | fs_locations_info | 67 | * | RD | Section 5.8.2.13 | - | fs_status | 61 | fs4_status | RD | Section 5.8.2.14 | - | hidden | 25 | bool | R/W | Section 5.8.2.15 | - | homogeneous | 26 | bool | RD | Section 5.8.2.16 | - | layout_alignment | 66 | uint32_t | RD | Section 5.12.2 | - | layout_blksize | 65 | uint32_t | RD | Section 5.12.3 | - | layout_hint | 63 | layouthint4 | WRT | Section 5.12.4 | - | layout_type | 64 | layouttype4<> | RD | Section 5.12.5 | - | maxfilesize | 27 | uint64_t | RD | Section 5.8.2.17 | - | maxlink | 28 | uint32_t | RD | Section 5.8.2.18 | - | maxname | 29 | uint32_t | RD | Section 5.8.2.19 | - | maxread | 30 | uint64_t | RD | Section 5.8.2.20 | - | maxwrite | 31 | uint64_t | RD | Section 5.8.2.21 | - | mdsthreshold | 68 | mdsthreshold4 | RD | Section 5.12.6 | - | mimetype | 32 | utf8<> | R/W | Section 5.8.2.22 | - | mode | 33 | mode4 | R/W | Section 6.2.4 | - | mode_set_masked | 74 | mode_masked4 | WRT | Section 6.2.5 | - | mounted_on_fileid | 55 | uint64_t | RD | Section 5.8.2.23 | - | no_trunc | 34 | bool | RD | Section 5.8.2.24 | - | numlinks | 35 | uint32_t | RD | Section 5.8.2.25 | - | owner | 36 | utf8<> | R/W | Section 5.8.2.26 | - | owner_group | 37 | utf8<> | R/W | Section 5.8.2.27 | - | quota_avail_hard | 38 | uint64_t | RD | Section 5.8.2.28 | - | quota_avail_soft | 39 | uint64_t | RD | Section 5.8.2.29 | - | quota_used | 40 | uint64_t | RD | Section 5.8.2.30 | - | rawdev | 41 | specdata4 | RD | Section 5.8.2.31 | - | retentevt_get | 71 | retention_get4 | RD | Section 5.13.3 | - | retentevt_set | 72 | retention_set4 | WRT | Section 5.13.4 | - | retention_get | 69 | retention_get4 | RD | Section 5.13.1 | - | retention_hold | 73 | uint64_t | R/W | Section 5.13.5 | - | retention_set | 70 | retention_set4 | WRT | Section 5.13.2 | - | sacl | 59 | nfsacl41 | R/W | Section 6.2.3 | - | space_avail | 42 | uint64_t | RD | Section 5.8.2.32 | - | space_free | 43 | uint64_t | RD | Section 5.8.2.33 | - | space_total | 44 | uint64_t | RD | Section 5.8.2.34 | - | space_used | 45 | uint64_t | RD | Section 5.8.2.35 | - | system | 46 | bool | R/W | Section 5.8.2.36 | - | time_access | 47 | nfstime4 | RD | Section 5.8.2.37 | - | time_access_set | 48 | settime4 | WRT | Section 5.8.2.38 | - | time_backup | 49 | nfstime4 | R/W | Section 5.8.2.39 | - | time_create | 50 | nfstime4 | R/W | Section 5.8.2.40 | - | time_delta | 51 | nfstime4 | RD | Section 5.8.2.41 | - | time_metadata | 52 | nfstime4 | RD | Section 5.8.2.42 | - | time_modify | 53 | nfstime4 | RD | Section 5.8.2.43 | - | time_modify_set | 54 | settime4 | WRT | Section 5.8.2.44 | + | acl | 12 | nfsace4<> | R W | Section 6.2.1 | + | aclsupport | 13 | uint32_t | R | Section 6.2.1.2 | + | archive | 14 | bool | R W | Section 5.8.2.1 | + | cansettime | 15 | bool | R | Section 5.8.2.2 | + | case_insensitive | 16 | bool | R | Section 5.8.2.3 | + | case_preserving | 17 | bool | R | Section 5.8.2.4 | + | change_policy | 60 | chg_policy4 | R | Section 5.8.2.5 | + | chown_restricted | 18 | bool | R | Section 5.8.2.6 | + | dacl | 58 | nfsacl41 | R W | Section 6.2.2 | + | dir_notif_delay | 56 | nfstime4 | R | Section 5.11.1 | + | dirent_notif_delay | 57 | nfstime4 | R | Section 5.11.2 | + | fileid | 20 | uint64_t | R | Section 5.8.2.7 | + | files_avail | 21 | uint64_t | R | Section 5.8.2.8 | + | files_free | 22 | uint64_t | R | Section 5.8.2.9 | + | files_total | 23 | uint64_t | R | Section 5.8.2.10 | + | fs_charset_cap | 76 | uint32_t | R | Section 5.8.2.11 | + | fs_layout_type | 62 | layouttype4<> | R | Section 5.12.1 | + | fs_locations | 24 | fs_locations | R | Section 5.8.2.12 | + | fs_locations_info | 67 | * | R | Section 5.8.2.13 | + | fs_status | 61 | fs4_status | R | Section 5.8.2.14 | + | hidden | 25 | bool | R W | Section 5.8.2.15 | + | homogeneous | 26 | bool | R | Section 5.8.2.16 | + | layout_alignment | 66 | uint32_t | R | Section 5.12.2 | + | layout_blksize | 65 | uint32_t | R | Section 5.12.3 | + | layout_hint | 63 | layouthint4 | W | Section 5.12.4 | + | layout_type | 64 | layouttype4<> | R | Section 5.12.5 | + | maxfilesize | 27 | uint64_t | R | Section 5.8.2.17 | + | maxlink | 28 | uint32_t | R | Section 5.8.2.18 | + | maxname | 29 | uint32_t | R | Section 5.8.2.19 | + | maxread | 30 | uint64_t | R | Section 5.8.2.20 | + | maxwrite | 31 | uint64_t | R | Section 5.8.2.21 | + | mdsthreshold | 68 | mdsthreshold4 | R | Section 5.12.6 | + | mimetype | 32 | utf8<> | R W | Section 5.8.2.22 | + | mode | 33 | mode4 | R W | Section 6.2.4 | + | mode_set_masked | 74 | mode_masked4 | W | Section 6.2.5 | + | mounted_on_fileid | 55 | uint64_t | R | Section 5.8.2.23 | + | no_trunc | 34 | bool | R | Section 5.8.2.24 | + | numlinks | 35 | uint32_t | R | Section 5.8.2.25 | + | owner | 36 | utf8<> | R W | Section 5.8.2.26 | + | owner_group | 37 | utf8<> | R W | Section 5.8.2.27 | + | quota_avail_hard | 38 | uint64_t | R | Section 5.8.2.28 | + | quota_avail_soft | 39 | uint64_t | R | Section 5.8.2.29 | + | quota_used | 40 | uint64_t | R | Section 5.8.2.30 | + | rawdev | 41 | specdata4 | R | Section 5.8.2.31 | + | retentevt_get | 71 | retention_get4 | R | Section 5.13.3 | + | retentevt_set | 72 | retention_set4 | W | Section 5.13.4 | + | retention_get | 69 | retention_get4 | R | Section 5.13.1 | + | retention_hold | 73 | uint64_t | R W | Section 5.13.5 | + | retention_set | 70 | retention_set4 | W | Section 5.13.2 | + | sacl | 59 | nfsacl41 | R W | Section 6.2.3 | + | space_avail | 42 | uint64_t | R | Section 5.8.2.32 | + | space_free | 43 | uint64_t | R | Section 5.8.2.33 | + | space_total | 44 | uint64_t | R | Section 5.8.2.34 | + | space_used | 45 | uint64_t | R | Section 5.8.2.35 | + | system | 46 | bool | R W | Section 5.8.2.36 | + | time_access | 47 | nfstime4 | R | Section 5.8.2.37 | + | time_access_set | 48 | settime4 | W | Section 5.8.2.38 | + | time_backup | 49 | nfstime4 | R W | Section 5.8.2.39 | + | time_create | 50 | nfstime4 | R W | Section 5.8.2.40 | + | time_delta | 51 | nfstime4 | R | Section 5.8.2.41 | + | time_metadata | 52 | nfstime4 | R | Section 5.8.2.42 | + | time_modify | 53 | nfstime4 | R | Section 5.8.2.43 | + | time_modify_set | 54 | settime4 | W | Section 5.8.2.44 | +--------------------+----+----------------+-----+------------------+ Table 5 * fs_locations_info4 5.8. Attribute Definitions 5.8.1. Definitions of REQUIRED Attributes @@ -16458,21 +16505,22 @@ | | NFS4ERR_ISDIR, NFS4ERR_IO, NFS4ERR_MLINK, | | | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, | | | NFS4ERR_NOTDIR, NFS4ERR_NOTSUPP, | | | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REQ_TOO_BIG, NFS4ERR_ROFS, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SYMLINK, NFS4ERR_TOO_MANY_OPS, | - | | NFS4ERR_WRONG_TYPE, NFS4ERR_XDEV | + | | NFS4ERR_WRONGSEC, NFS4ERR_WRONG_TYPE, | + | | NFS4ERR_XDEV | | LOCK | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_RANGE, | | | NFS4ERR_BAD_STATEID, NFS4ERR_DEADLOCK, | | | NFS4ERR_DEADSESSION, NFS4ERR_DELAY, | | | NFS4ERR_DENIED, NFS4ERR_EXPIRED, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_INVAL, NFS4ERR_ISDIR, | | | NFS4ERR_LOCK_NOTSUPP, NFS4ERR_LOCK_RANGE, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_NO_GRACE, NFS4ERR_OLD_STATEID, | @@ -16695,21 +16743,22 @@ | | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, | | | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, | | | NFS4ERR_NOTEMPTY, | | | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REQ_TOO_BIG, NFS4ERR_ROFS, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | - | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_XDEV | + | | NFS4ERR_TOO_MANY_OPS, NFS4ERR_WRONGSEC, | + | | NFS4ERR_XDEV | | RENEW | NFS4ERR_NOTSUPP | | RESTOREFH | NFS4ERR_DEADSESSION, NFS4ERR_FHEXPIRED, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_OP_NOT_IN_SESSION, | | | NFS4ERR_REP_TOO_BIG, | | | NFS4ERR_REP_TOO_BIG_TO_CACHE, | | | NFS4ERR_REQ_TOO_BIG, NFS4ERR_SERVERFAULT, | | | NFS4ERR_STALE, NFS4ERR_TOO_MANY_OPS, | | | NFS4ERR_WRONGSEC | | SAVEFH | NFS4ERR_DEADSESSION, NFS4ERR_FHEXPIRED, | @@ -17477,23 +17526,23 @@ | | SECINFO, SECINFO_NO_NAME, | | | SEQUENCE, SETATTR, SET_SSV, | | | TEST_STATEID, VERIFY, | | | WANT_DELEGATION, WRITE | | NFS4ERR_UNKNOWN_LAYOUTTYPE | CB_LAYOUTRECALL, | | | GETDEVICEINFO, GETDEVICELIST, | | | LAYOUTCOMMIT, LAYOUTGET, | | | LAYOUTRETURN, NVERIFY, | | | SETATTR, VERIFY | | NFS4ERR_UNSAFE_COMPOUND | CREATE, OPEN, OPENATTR | - | NFS4ERR_WRONGSEC | LOOKUP, LOOKUPP, OPEN, PUTFH, | - | | PUTPUBFH, PUTROOTFH, | - | | RESTOREFH | + | NFS4ERR_WRONGSEC | LINK, LOOKUP, LOOKUPP, OPEN, | + | | PUTFH, PUTPUBFH, PUTROOTFH, | + | | RENAME, RESTOREFH | | NFS4ERR_WRONG_CRED | CLOSE, CREATE_SESSION, | | | DELEGPURGE, DELEGRETURN, | | | DESTROY_CLIENTID, | | | DESTROY_SESSION, | | | FREE_STATEID, LAYOUTCOMMIT, | | | LAYOUTRETURN, LOCK, LOCKT, | | | LOCKU, OPEN_DOWNGRADE, | | | RECLAIM_COMPLETE | | NFS4ERR_WRONG_TYPE | CB_LAYOUTRECALL, | | | CB_PUSH_DELEG, COMMIT, | @@ -19587,21 +19636,21 @@ Contrast this with NFSv3, which would first send a GETATTR in one request/reply round trip, and then if attributes indicated that the client's cache was stale, then send a READ in another request/reply round trip. In the case that a RECOMMENDED attribute is specified in the NVERIFY operation and the server does not support that attribute for the file system object, the error NFS4ERR_ATTRNOTSUPP is returned to the client. - When the attribute rdattr_error or any write-only attribute (e.g. + When the attribute rdattr_error or any set-only attribute (e.g. time_modify_set) is specified, the error NFS4ERR_INVAL is returned to the client. 18.16. Operation 18: OPEN - Open a Regular File 18.16.1. ARGUMENTS /* * Various definitions for OPEN */ @@ -20595,30 +20644,30 @@ Valid values for the share_deny field are: OPEN4_SHARE_DENY_NONE, OPEN4_SHARE_DENY_READ, OPEN4_SHARE_DENY_WRITE, or OPEN4_SHARE_DENY_BOTH. If the client specifies other values, the server MUST reply with NFS4ERR_INVAL. After checking for valid values of share_access and share_deny, the server replaces the current access and deny modes on the file with share_access and share_deny subject to the following constraints: - o The bits in share_access MUST equal the union of the share_access - bits (not including OPEN4_SHARE_WANT_* bits) specified for some - subset of the OPENs in effect for the current open-owner on the - current file. - - o The bits in share_deny MUST equal the union of the share_deny bits + o The bits in share_access SHOULD equal the union of the + share_access bits (not including OPEN4_SHARE_WANT_* bits) specified for some subset of the OPENs in effect for the current open-owner on the current file. - If the above constraints are not respected, the server MUST return + o The bits in share_deny SHOULD equal the union of the share_deny + bits specified for some subset of the OPENs in effect for the + current open-owner on the current file. + + If the above constraints are not respected, the server SHOULD return the error NFS4ERR_INVAL. Since share_access and share_deny bits should be subsets of those already granted, short of a defect in the client or server implementation, it is not possible for the OPEN_DOWNGRADE request to be denied because of conflicting share reservations. The seqid argument is not used in NFSv4.1, MAY be any value, and MUST be ignored by the server. On success, the current filehandle retains its value. @@ -21241,141 +21290,139 @@ default: void; }; 18.26.3. DESCRIPTION The RENAME operation renames the object identified by oldname in the source directory corresponding to the saved filehandle, as set by the SAVEFH operation, to newname in the target directory corresponding to the current filehandle. The operation is required to be atomic to - the client. Source and target directories must reside on the same + the client. Source and target directories MUST reside on the same file system on the server. On success, the current filehandle will continue to be the target directory. If the target directory already contains an entry with the name, - newname, the source object must be compatible with the target: either - both are non-directories or both are directories and the target must + newname, the source object MUST be compatible with the target: either + both are non-directories or both are directories and the target MUST be empty. If compatible, the existing target is removed before the rename occurs or preferably as part of the rename and atomic with it. See Section 18.25.4 for client and server actions whenever a target is removed. Note however that when the removal is performed atomically with the rename, certain parts of the removal described there are integrated with the rename. For example, notification of the removal will not be via a NOTIFY4_REMOVE_ENTRY but will be indicated as part of the NOTIFY4_ADD_ENTRY or NOTIFY4_RENAME_ENTRY generated by the rename. If the source object and the target are not compatible or if the target is a directory but not empty, the server will return the error, NFS4ERR_EXIST. If oldname and newname both refer to the same file (e.g. they might - be hard links of each other), then RENAME MUST perform no action and - return NFS4_OK. + be hard links of each other), then unless the file is open (see + Section 18.26.4), RENAME MUST perform no action and return NFS4_OK. For both directories involved in the RENAME, the server returns change_info4 information. With the atomic field of the change_info4 data type, the server will indicate if the before and after change attributes were obtained atomically with respect to the rename. - If the oldname refers to a named attribute and the saved and current + If oldname refers to a named attribute and the saved and current filehandles refer to different file system objects, the server will return NFS4ERR_XDEV just as if the saved and current filehandles represented directories on different file systems. - If the oldname or newname has a length of 0 (zero), or if oldname or - newname does not obey the UTF-8 definition, the error NFS4ERR_INVAL + If oldname or newname have a length of 0 (zero), or if oldname or + newname do not obey the UTF-8 definition, the error NFS4ERR_INVAL will be returned. 18.26.4. IMPLEMENTATION The server MAY impose restrictions on the RENAME operation such that RENAME may not be done when the file being renamed is open or when that open is done by particular protocols, or with particular options or access modes. Similar restrictions may be applied when a file exists with the target name and is open. When RENAME is rejected because of such restrictions, the error NFS4ERR_FILE_OPEN is returned. When oldname and rename refer to the same file and that file is open - is such a fashion that RENAME would normally be rejected with - NFS4ERR_FILE_OPEN, it SHOULD be rejected and the error returned in - the same way as would have been done if oldname and newname did not - refer to the same file. + in a fashion such that RENAME would normally be rejected with + NFS4ERR_FILE_OPEN if oldname and newname were different files, then + RENAME SHOULD be rejected with NFS4ERR_FILE_OPEN. If a server does implement such restrictions and those restrictions include cases of NFSv4 opens preventing successful execution of a rename, the server needs to recall any delegations which could hide - the existence of opens relevant to that decision. This is because of - the fact that when a client holds a delegation, the server need not - have accurate picture of the opens for that client, since the client - may execute OPENs and CLOSEs locally. The RENAME operation must be - delayed only until a definitive result can be obtained. For example, - if there are multiple delegations and one of them establishes an open + the existence of opens relevant to that decision. This is because + when a client holds a delegation, the server might not have an + accurate account of the opens for that client, since the client may + execute OPENs and CLOSEs locally. The RENAME operation need only be + delayed until a definitive result can be obtained. For example, if + there are multiple delegations and one of them establishes an open whose presence would prevent the rename, given the server's semantics, NFS4ERR_FILE_OPEN may be returned to the caller as soon as that delegation is returned without waiting for other delegations to be returned. Similarly, if such opens are not associated with delegations, NFS4ERR_FILE_OPEN can be returned immediately with no delegation recall being done. - If the current filehandle or the saved filehandle designates a + If the current filehandle or the saved filehandle designate a directory for which another client holds a directory delegation, - then, unless the delegation is such that the situation can be - resolved by sending a notification, the delegation must be recalled, - and the operation cannot proceed until the delegation is returned or - revoked. Except where this happens very quickly, one or more - NFS4ERR_DELAY errors will be returned to requests made while - delegation remains outstanding. + then, unless the situation can be resolved by sending a notification, + the delegation MUST be recalled, and the operation cannot proceed + until the delegation is returned or revoked. Except where this + happens very quickly, one or more NFS4ERR_DELAY errors will be + returned to requests made while delegation remains outstanding. When the current and saved filehandles are the same and they designate a directory for which one or more directory delegations exist, then, when those delegations request such notifications, a notification of type NOTIFY4_RENAME_ENTRY will be generated as a result of this operation. When oldname and rename refer to the same - file, it is not required that such a notification be generated. When - a file is removed because it has the same name as the target, if that - removal is done atomically with the rename, a NOTIFY4_REMOVE_ENTRY - notification will not be generated. Instead, the deletion of the - file will be reported as part of the NOTIFY4_RENAME_ENTRY - notification. + file, no notification is generated (because as Section 18.26.3 + states, the server MUST take no action). When a file is removed + because it has the same name as the target, if that removal is done + atomically with the rename, a NOTIFY4_REMOVE_ENTRY notification will + not be generated. Instead, the deletion of the file will be reported + as part of the NOTIFY4_RENAME_ENTRY notification. When the current and saved filehandles are not the same: o If the current filehandle designates a directory for which one or more directory delegations exist, then, when those delegations request such notifications, NOTIFY4_ADD_ENTRY will be generated as a result of this operation. When a file is removed because it has the same name as the target, if that removal is done atomically with the rename, a NOTIFY4_REMOVE_ENTRY notification will not be generated. Instead, the deletion of the file will be reported as part of the NOTIFY4_ADD_ENTRY notification. o If the saved filehandle designates a directory for which one or more directory delegations exist, then, when those delegations request such notifications, NOTIFY4_REMOVE_ENTRY will be generated as a result of this operation. - If the object being renamed has a file delegation which is held by a - client other than the one doing the RENAME, the delegation(s) must be + If the object being renamed has file delegations held by clients + other than the one doing the RENAME, the delegations MUST be recalled, and the operation cannot proceed until each such delegation is returned or revoked. Note that in the case of multiply linked files, the delegation recall requirement applies even if the delegation was obtained through a different name than the one being renamed. In all cases in which delegations are recalled, the server is likely to return one or more NFS4ERR_DELAY error while the delegation(s) remains outstanding, although it may, if the returns happen quickly, not do that. The RENAME operation must be atomic to the client. The statement - "source and target directories must reside on the same file system on + "source and target directories MUST reside on the same file system on the server" means that the fsid fields in the attributes for the directories are the same. If they reside on different file systems, the error, NFS4ERR_XDEV, is returned. Based on the value of the fh_expire_type attribute for the object, the filehandle may or may not expire on a RENAME. However, server implementors are strongly encouraged to attempt to keep filehandles from expiring in this fashion. On some servers, the file names "." and ".." are illegal as either @@ -21505,108 +21552,136 @@ default: void; }; 18.29.3. DESCRIPTION The SECINFO operation is used by the client to obtain a list of valid RPC authentication flavors for a specific directory filehandle, file name pair. SECINFO should apply the same access methodology used for LOOKUP when evaluating the name. Therefore, if the requester does - not have the appropriate access to LOOKUP the name then SECINFO must + not have the appropriate access to LOOKUP the name then SECINFO MUST behave the same way and return NFS4ERR_ACCESS. The result will contain an array which represents the security mechanisms available, with an order corresponding to the server's preferences, the most preferred being first in the array. The client is free to pick whatever security mechanism it both desires and supports, or to pick in the server's preference order the first one it supports. The array entries are represented by the secinfo4 structure. The field 'flavor' will contain a value of AUTH_NONE, AUTH_SYS (as defined in RFC1831 [3]), or RPCSEC_GSS (as defined in - RFC2203 [4]). The field flavor can also any other security flavor + RFC2203 [4]). The field flavor can also be any other security flavor registered with IANA. For the flavors AUTH_NONE and AUTH_SYS, no additional security information is returned. The same is true of many (if not most) other security flavors, including AUTH_DH. For a return value of RPCSEC_GSS, a security triple is returned that contains the mechanism object id (as defined in RFC2743 [7]), the quality of protection (as defined in RFC2743 [7]) and the service type (as defined in RFC2203 [4]). It is possible for SECINFO to return multiple entries with flavor equal to RPCSEC_GSS with different security triple values. On success, the current filehandle is consumed (see - Section 2.6.3.1.8), and if the next operation after SECINFO tries to - use the current filehandle, that operation will fail with the status - NFS4ERR_NOFILEHANDLE. + Section 2.6.3.1.1.8), and if the next operation after SECINFO tries + to use the current filehandle, that operation will fail with the + status NFS4ERR_NOFILEHANDLE. If the name has a length of 0 (zero), or if name does not obey the - UTF-8 definition, the error NFS4ERR_INVAL will be returned. + UTF-8 definition (assuming UTF-8 capabilities are enabled, see + Section 14.4), the error NFS4ERR_INVAL will be returned. + + See Section 2.6 for additional information on the use of SECINFO. 18.29.4. IMPLEMENTATION The SECINFO operation is expected to be used by the NFS client when the error value of NFS4ERR_WRONGSEC is returned from another NFS operation. This signifies to the client that the server's security policy is different from what the client is currently using. At this point, the client is expected to obtain a list of possible security flavors and choose what best suits its policies. As mentioned, the server's security policies will determine when a - client request receives NFS4ERR_WRONGSEC. The operations which may - receive this error are: LINK, LOOKUP, LOOKUPP, OPEN, PUTFH, PUTPUBFH, - PUTROOTFH, RESTOREFH, RENAME, and indirectly READDIR. LINK and - RENAME will only receive this error if the security used for the - operation is inappropriate for saved filehandle. With the exception - of READDIR, these operations represent the point at which the client - can instantiate a filehandle into the "current filehandle" at the - server. The filehandle is either provided by the client (PUTFH, - PUTPUBFH, PUTROOTFH) or generated as a result of a name to filehandle - translation (LOOKUP and OPEN). RESTOREFH is different because the - filehandle is a result of a previous SAVEFH. Even though the - filehandle, for RESTOREFH, might have previously passed the server's - inspection for a security match, the server will check it again on - RESTOREFH to ensure that the security policy has not changed. + client request receives NFS4ERR_WRONGSEC. See Table 14 for a list + operations which can return NFS4ERR_WRONGSEC. In addition, when + READDIR returns attributes, the rdaddr_error (Section 5.8.1.12) can + contain NFS4ERR_WRONGSEC. Note that CREATE and REMOVE MUST NOT + return NFS4ERR_WRONGSEC. The rationale for CREATE is that unless the + target name exists it cannot have a separate security policy from the + parent directory, and the security policy of the parent was checked + when its filehandle was injected into the COMPOUND request's + operations stream (for similar reasons, an OPEN operation that + creates the target MUST NOT return NFS4ERR_WRONGSEC). If the target + name exists, while it might have a separate security policy, that is + irrelevant because CREATE MUST return NFS4ERR_EXIST. The rationale + for REMOVE is that while that target might have separate security + policy, the target is going to be removed, and so the the security + policy of the parent trumps that of the object being removed. RENAME + and LINK MAY return NFS4ERR_WRONGSEC, but the NFS4ERR_WRONGSEC error + applies only to the saved filehandle (see Section 2.6.3.1.2). Any + NFS4ERR_WRONGSEC error on the current filehandle used by LINK and + RENAME MUST be returned by the PUTFH, PUTPUBFH, PUTROOTFH, or + RESTOREFH operation that injected the current filehandle. - If the client wants to resolve an error return of NFS4ERR_WRONGSEC, - the following will occur: + With the exception of LINK and RENAME, the set of operations that can + return NFS4ERR_WRONGSEC represent the point at which the client can + inject a filehandle into the "current filehandle" at the server. The + filehandle is either provided by the client (PUTFH, PUTPUBFH, + PUTROOTFH), generated as a result of a name to filehandle translation + (LOOKUP and OPEN), or generated from the saved filehandle via + RESTOREFH. As Section 2.6.3.1.1.1 states, a put filehandle operation + followed by SAVEFH MUST NOT return NFS4ERR_WRONGSEC. Thus the + RESTOREFH operation, under certain conditions (see Section 2.6.3.1.1) + is permitted to return NFS4ERR_WRONGSEC so that security policies can + be honored. + + The READDIR operation will not directly return the NFS4ERR_WRONGSEC + error. However, if the READDIR request included a request for + attributes, it is possible that the READDIR request's security triple + did not match that of a directory entry. If this is the case and the + client has requested the rdattr_error attribute, the server will + return the NFS4ERR_WRONGSEC error in rdattr_error for the entry. + + To resolve an error return of NFS4ERR_WRONGSEC, the client does the + following: o For LOOKUP and OPEN, the client will use SECINFO with the same current filehandle and name as provided in the original LOOKUP or OPEN to enumerate the available security triples. - o For LINK, PUTFH, PUTROOTFH, PUTPUBFH, RENAME, and RESTOREFH, the + o For the rdattr_error, the client will use SECINFO with the same + current filehandle as provided in the original READDIR. The name + passed to SECINFO will be that of the directory entry (as returned + from READDIR) that had the NFS4ERR_WRONGSEC error in the + rdattr_error attribute. + + o For PUTFH, PUTROOTFH, PUTPUBFH, RESTOREFH, LINK, and RENAME, the client will use SECINFO_NO_NAME { style = SECINFO_STYLE4_CURRENT_FH }. The client will prefix the SECINFO_NO_NAME operation with the appropriate PUTFH, PUTPUBFH, or PUTROOTFH operation that provides the filehandle originally - provided by the PUTFH, PUTPUBFH, PUTROOTFH, or RESTOREFH, or for - the failed LINK or RENAME, the SAVEFH. + provided by the PUTFH, PUTPUBFH, PUTROOTFH, or RESTOREFH + operation. - o NOTE: In NFSv4.0, the client was required to use SECINFO, and had + NOTE: In NFSv4.0, the client was required to use SECINFO, and had to reconstruct the parent of the original filehandle, and the - component name of the original filehandle. + component name of the original filehandle. The introduction in + NFSv4.1 of SECINFO_NO_NAME obviates the need for reconstruction. o For LOOKUPP, the client will use SECINFO_NO_NAME { style = - SECINFO_STYLE4_PARENT } and provide the filehandle with equals the - filehandle originally provided to LOOKUPP. - - The READDIR operation will not directly return the NFS4ERR_WRONGSEC - error. However, if the READDIR request included a request for - attributes, it is possible that the READDIR request's security triple - did not match that of a directory entry. If this is the case and the - client has requested the rdattr_error attribute, the server will - return the NFS4ERR_WRONGSEC error in rdattr_error for the entry. + SECINFO_STYLE4_PARENT } and provide the filehandle which equals + the filehandle originally provided to LOOKUPP. - See Section 21 for a discussion on the recommendations for security - flavor used by SECINFO and SECINFO_NO_NAME. + See Section 21 for a discussion on the recommendations for the + security flavor used by SECINFO and SECINFO_NO_NAME. 18.30. Operation 34: SETATTR - Set Attributes 18.30.1. ARGUMENTS struct SETATTR4args { /* CURRENT_FH: target object */ stateid4 stateid; fattr4 obj_attributes; }; @@ -21627,165 +21702,167 @@ The stateid argument for SETATTR is used to provide file locking context that is necessary for SETATTR requests that set the size attribute. Since setting the size attribute modifies the file's data, it has the same locking requirements as a corresponding WRITE. Any SETATTR that sets the size attribute is incompatible with a share reservation that specifies DENY_WRITE. The area between the old end- of-file and the new end-of-file is considered to be modified just as would have been the case had the area in question been specified as the target of WRITE, for the purpose of checking conflicts with byte- range locks, for those cases in which a server is implementing - mandatory byte-range locking behavior. A valid stateid should always + mandatory byte-range locking behavior. A valid stateid SHOULD always be specified. When the file size attribute is not set, the special - stateid consisting of all bits zero should be passed. + stateid consisting of all bits zero MAY be passed. On either success or failure of the operation, the server will return the attrsset bitmask to represent what (if any) attributes were successfully set. The attrsset in the response is a subset of the - bitmap4 that is part of the obj_attributes in the argument. + attrmask field of the obj_attributes field in the argument. On success, the current filehandle retains its value. 18.30.4. IMPLEMENTATION If the request specifies the owner attribute to be set, the server - should allow the operation to succeed if the current owner of the + SHOULD allow the operation to succeed if the current owner of the object matches the value specified in the request. Some servers may be implemented in a way as to prohibit the setting of the owner attribute unless the requester has privilege to do so. If the server is lenient in this one case of matching owner values, the client implementation may be simplified in cases of creation of an object - followed by a SETATTR. + (e.g. an exclusive create via OPEN) followed by a SETATTR. The file size attribute is used to request changes to the size of a - file. A value of 0 (zero) causes the file to be truncated, a value - less than the current size of the file causes data from new size to - the end of the file to be discarded, and a size greater than the - current size of the file causes logically zeroed data bytes to be - added to the end of the file. Servers are free to implement this - using holes or actual zero data bytes. Clients should not make any - assumptions regarding a server's implementation of this feature, - beyond that the bytes returned will be zeroed. Servers must support + file. A value of zero causes the file to be truncated, a value less + than the current size of the file causes data from new size to the + end of the file to be discarded, and a size greater than the current + size of the file causes logically zeroed data bytes to be added to + the end of the file. Servers are free to implement this using + unallocate bytes (holes) or allocated data bytes set to zero. + Clients should not make any assumptions regarding a server's + implementation of this feature, beyond that the bytes in affected + region returned by READ will be zeroed. Servers MUST support extending the file size via SETATTR. - SETATTR is not guaranteed atomic. A failed SETATTR may partially - change a file's attributes. + SETATTR is not guaranteed to be atomic. A failed SETATTR may + partially change a file's attributes, hence the reason why the reply + always includes the status and the list of attributes that were set. If the object whose attributes are being changed has a file delegation which is held by a client other than the one doing the SETATTR, the delegation(s) must be recalled, and the operation cannot proceed to actually change an attribute until each such delegation is returned or revoked. In all cases in which delegations are recalled, the server is likely to return one or more NFS4ERR_DELAY error while the delegation(s) remains outstanding, although it may, if the returns happen quickly, not do that. If the object whose attributes are being set is a directory and another client holds a directory delegation for that directory, then - asynchronous notifications will be generated when the set of - attributes changed has a non-null intersection with the set of + if enabled, asynchronous notifications will be generated when the set + of attributes changed has a non-null intersection with the set of attributes for which notification is requested. Notifications of type NOTIFY4_CHANGE_DIR_ATTRS will be sent to the appropriate client(s), but the SETATTR is not delayed by waiting for these notifications to be sent. If the object whose attributes are being set is a member of directory for which another client holds a directory delegation, then asynchronous notifications will be generated when the set of attributes changed has a non-null intersection with the set of attributes for which notification is requested. Notifications of type NOTIFY4_CHANGE_CHILD_ATTRS will be sent to the appropriate - client(s), but the SETATTR is not delayed by waiting for these + clients, but the SETATTR is not delayed by waiting for these notifications to be sent. Changing the size of a file with SETATTR indirectly changes the - time_modify. A client must account for this as size changes can - result in data deletion. + time_modify and change attributes. A client must account for this as + size changes can result in data deletion. The attributes time_access_set and time_modify_set are write-only attributes constructed as a switched union so the client can direct the server in setting the time values. If the switched union specifies SET_TO_CLIENT_TIME4, the client has provided an nfstime4 to be used for the operation. If the switch union does not specify SET_TO_CLIENT_TIME4, the server is to use its current time for the SETATTR operation. If server and client times differ, programs that compare client time - to file times can break. A time maintenance protocol should be used - to limit client/server time skew. + to file times can break. A time synchronization protocol should be + used to limit client/server time skew. Use of a COMPOUND containing a VERIFY operation specifying only the change attribute, immediately followed by a SETATTR, provides a means whereby a client may specify a request that emulates the functionality of the SETATTR guard mechanism of NFSv3. Since the function of the guard mechanism is to avoid changes to the file attributes based on stale information, delays between checking of the guard condition and the setting of the attributes have the potential to compromise this function, as would the corresponding delay in the - NFSv4 emulation. Therefore, NFSv4.1 servers should take care to + NFSv4 emulation. Therefore, NFSv4.1 servers SHOULD take care to avoid such delays, to the degree possible, when executing such a request. If the server does not support an attribute as requested by the - client, the server should return NFS4ERR_ATTRNOTSUPP. + client, the server SHOULD return NFS4ERR_ATTRNOTSUPP. A mask of the attributes actually set is returned by SETATTR in all - cases. That mask must not include attributes bits not requested to - be set by the client, and must be equal to the mask of attributes - requested to be set only if the SETATTR completes without error. + cases. That mask MUST NOT include attributes bits not requested to + be set by the client. If the attribute masks in the request and + reply are equal, the the status field in the reply MUST be NFS4_OK. 18.31. Operation 37: VERIFY - Verify Same Attributes 18.31.1. ARGUMENTS struct VERIFY4args { /* CURRENT_FH: object */ fattr4 obj_attributes; }; 18.31.2. RESULTS struct VERIFY4res { nfsstat4 status; }; 18.31.3. DESCRIPTION - The VERIFY operation is used to verify that attributes have a value + The VERIFY operation is used to verify that attributes have the value assumed by the client before proceeding with following operations in - the compound request. If any of the attributes do not match then the + the COMPOUND request. If any of the attributes do not match then the error NFS4ERR_NOT_SAME must be returned. The current filehandle retains its value after successful completion of the operation. 18.31.4. IMPLEMENTATION - One possible use of the VERIFY operation is the following compound - sequence. With this the client is attempting to verify that the file - being removed will match what the client expects to be removed. This - sequence can help prevent the unintended deletion of a file. + One possible use of the VERIFY operation is the following series of + operations. With this the client is attempting to verify that the + file being removed will match what the client expects to be removed. + This series can help prevent the unintended deletion of a file. PUTFH (directory filehandle) LOOKUP (file name) VERIFY (filehandle == fh) PUTFH (directory filehandle) REMOVE (file name) - This sequence does not prevent a second client from removing and + This series does not prevent a second client from removing and creating a new file in the middle of this sequence but it does help avoid the unintended result. In the case that a RECOMMENDED attribute is specified in the VERIFY operation and the server does not support that attribute for the file system object, the error NFS4ERR_ATTRNOTSUPP is returned to the client. - When the attribute rdattr_error or any write-only attribute (e.g. + When the attribute rdattr_error or any set-only attribute (e.g. time_modify_set) is specified, the error NFS4ERR_INVAL is returned to the client. 18.32. Operation 38: WRITE - Write to File 18.32.1. ARGUMENTS enum stable_how4 { UNSTABLE4 = 0, DATA_SYNC4 = 1, @@ -21817,178 +21894,189 @@ 18.32.3. DESCRIPTION The WRITE operation is used to write data to a regular file. The target file is specified by the current filehandle. The offset specifies the offset where the data should be written. An offset of 0 (zero) specifies that the write should start at the beginning of the file. The count, as encoded as part of the opaque data parameter, represents the number of bytes of data that are to be written. If the count is 0 (zero), the WRITE will succeed and return - a count of 0 (zero) subject to permissions checking. The server may - choose to write fewer bytes than requested by the client. + a count of 0 (zero) subject to permissions checking. The server MAY + write fewer bytes than requested by the client. - Part of the write request is a specification of how the write is to - be performed. The client specifies with the stable parameter the - method of how the data is to be processed by the server. If stable - is FILE_SYNC4, the server must commit the data written plus all file - system metadata to stable storage before returning results. This - corresponds to the NFSv2 protocol semantics. Any other behavior - constitutes a protocol violation. If stable is DATA_SYNC4, then the - server must commit all of the data to stable storage and enough of - the metadata to retrieve the data before returning. The server - implementor is free to implement DATA_SYNC4 in the same fashion as - FILE_SYNC4, but with a possible performance drop. If stable is - UNSTABLE4, the server is free to commit any part of the data and the - metadata to stable storage, including all or none, before returning a - reply to the client. There is no guarantee whether or when any - uncommitted data will subsequently be committed to stable storage. - The only guarantees made by the server are that it will not destroy - any data without changing the value of verf and that it will not - commit the data and metadata at a level less than that requested by - the client. + The client specifies with the stable parameter the method of how the + data is to be processed by the server. If stable is FILE_SYNC4, the + server MUST commit the data written plus all file system metadata to + stable storage before returning results. This corresponds to the + NFSv2 protocol semantics. Any other behavior constitutes a protocol + violation. If stable is DATA_SYNC4, then the server MUST commit all + of the data to stable storage and enough of the metadata to retrieve + the data before returning. The server implementor is free to + implement DATA_SYNC4 in the same fashion as FILE_SYNC4, but with a + possible performance drop. If stable is UNSTABLE4, the server is + free to commit any part of the data and the metadata to stable + storage, including all or none, before returning a reply to the + client. There is no guarantee whether or when any uncommitted data + will subsequently be committed to stable storage. The only + guarantees made by the server are that it will not destroy any data + without changing the value of writeverf and that it will not commit + the data and metadata at a level less than that requested by the + client. Except when special stateids are used, the stateid value for a WRITE - request represents a value returned from a previous byte-range lock - or share reservation request or the stateid associated with a - delegation. The stateid identifies the associated owners if any and - is used by the server to verify that the associated locks are still - valid (e.g. have not been revoked). + request represents a value returned from a previous byte-range LOCK + or OPEN request or the stateid associated with a delegation. The + stateid identifies the associated owners if any and is used by the + server to verify that the associated locks are still valid (e.g. have + not been revoked). Upon successful completion, the following results are returned. The count result is the number of bytes of data written to the file. The server may write fewer bytes than requested. If so, the actual number of bytes written starting at location, offset, is returned. The server also returns an indication of the level of commitment of - the data and metadata via committed. If the server committed all - data and metadata to stable storage, committed should be set to - FILE_SYNC4. If the level of commitment was at least as strong as - DATA_SYNC4, then committed should be set to DATA_SYNC4. Otherwise, - committed must be returned as UNSTABLE4. If stable was FILE4_SYNC, - then committed must also be FILE_SYNC4: anything else constitutes a - protocol violation. If stable was DATA_SYNC4, then committed may be - FILE_SYNC4 or DATA_SYNC4: anything else constitutes a protocol - violation. If stable was UNSTABLE4, then committed may be either - FILE_SYNC4, DATA_SYNC4, or UNSTABLE4. + the data and metadata via committed. Per Table 20, - The final portion of the result is the write verifier. The write - verifier is a cookie that the client can use to determine whether the - server has changed instance (boot) state between a call to WRITE and - a subsequent call to either WRITE or COMMIT. This cookie must be - consistent during a single instance of the NFSv4.1 protocol service - and must be unique between instances of the NFSv4.1 protocol server, - where uncommitted data may be lost. + o The server MAY commit the data at a stronger level than requested. + + o The server MUST commit the data at a level at least as high as + that committed. + + Valid combinations of the fields stable in the request and committed + in the reply. + + +------------+-----------------------------------+ + | stable | committed | + +------------+-----------------------------------+ + | UNSTABLE4 | FILE_SYNC4, DATA_SYNC4, UNSTABLE4 | + | DATA_SYNC4 | FILE_SYNC4, DATA_SYNC4 | + | FILE_SYNC4 | FILE_SYNC4 | + +------------+-----------------------------------+ + + Table 20 + + The final portion of the result is the field writeverf. This field + is the write verifier and is a cookie that the client can use to + determine whether a server has changed instance state (e.g. server + restart) between a call to WRITE and a subsequent call to either + WRITE or COMMIT. This cookie MUST be unchanged during a single + instance of the NFSv4.1 server and MUST be unique between instances + of the NFSv4.1 server. If the cookie changes, then the client MUST + assume that any data written with an UNSTABLE4 value for committed + and an old writeverf in the reply has been lost and will need to be + recovered. If a client writes data to the server with the stable argument set to UNSTABLE4 and the reply yields a committed response of DATA_SYNC4 or UNSTABLE4, the client will follow up some time in the future with a COMMIT operation to synchronize outstanding asynchronous data and metadata with the server's stable storage, barring client error. It is possible that due to client crash or other error that a subsequent COMMIT will not be received by the server. For a WRITE with a stateid value of all bits 0, the server MAY allow the WRITE to be serviced subject to mandatory file locks or the current share deny modes for the file. For a WRITE with a stateid value of all bits 1, the server MUST NOT allow the WRITE operation to - bypass locking checks at the server and are treated exactly the same - as if a stateid of all bits 0 were used. + bypass locking checks at the server and otherwise is treated as if a + stateid of all bits 0 were used. On success, the current filehandle retains its value. 18.32.4. IMPLEMENTATION It is possible for the server to write fewer bytes of data than - requested by the client. In this case, the server should not return + requested by the client. In this case, the server SHOULD NOT return an error unless no data was written at all. If the server writes - less than the number of bytes specified, the client should send + less than the number of bytes specified, the client will need to send another WRITE to write the remaining data. It is assumed that the act of writing data to a file will cause the - time_modified of the file to be updated. However, the time_modified - of the file should not be changed unless the contents of the file are - changed. Thus, a WRITE request with count set to 0 should not cause - the time_modified of the file to be updated. + time_modified and change attributes of the file to be updated. + However, these attributes SHOULD NOT be changed unless the contents + of the file are changed. Thus, a WRITE request with count set to 0 + SHOULD NOT cause the time_modified and change attributes of the file + to be updated. - The definition of stable storage has been historically a point of - contention. The following expected properties of stable storage may - help in resolving design sends in the implementation. Stable storage - is persistent storage that survives: + Stable storage is persistent storage that survives: 1. Repeated power failures. 2. Hardware failures (of any board, power supply, etc.). 3. Repeated software crashes and restarts. This definition does not address failure of the stable storage module itself. The verifier is defined to allow a client to detect different instances of an NFSv4.1 protocol server over which cached, uncommitted data may be lost. In the most likely case, the verifier allows the client to detect server restarts. This information is required so that the client can safely determine whether the server could have lost cached data. If the server fails unexpectedly and the client has uncommitted data from previous WRITE requests (done with the stable argument set to UNSTABLE4 and in which the result - committed was returned as UNSTABLE4 as well) it may not have flushed - cached data to stable storage. The burden of recovery is on the - client and the client will need to retransmit the data to the server. + committed was returned as UNSTABLE4 as well) the server might not + have flushed cached data to stable storage. The burden of recovery + is on the client and the client will need to retransmit the data to + the server. A suggested verifier would be to use the time that the server was last started (if restarting the server results in lost buffers). - The committed field in the results allows the client to do more - effective caching. If the server is committing all WRITE requests to - stable storage, then it should return with committed set to - FILE_SYNC4, regardless of the value of the stable field in the - arguments. A server that uses an NVRAM accelerator may choose to - implement this policy. The client can use this to increase the - effectiveness of the cache by discarding cached data that has already - been committed on the server. + The reply's committed field allows the client to do more effective + caching. If the server is committing all WRITE requests to stable + storage, then it SHOULD return with committed set to FILE_SYNC4, + regardless of the value of the stable field in the arguments. A + server that uses an NVRAM accelerator may choose to implement this + policy. The client can use this to increase the effectiveness of the + cache by discarding cached data that has already been committed on + the server. Some implementations may return NFS4ERR_NOSPC instead of - NFS4ERR_DQUOT when a user's quota is exceeded. In the case that the - current filehandle is of type NF4DIR, the server will return - NFS4ERR_ISDIR. If the current file is a symbolic link, the error - NFS4ERR_SYMLINK will be returned. Otherwise, if the current - filehandle does not designate an ordinary file, the server will - return NFS4ERR_WRONG_TYPE. + NFS4ERR_DQUOT when a user's quota is exceeded. - If mandatory file locking is on for the file, and corresponding byte- - range of the data to be written file is read or write locked by an - owner that is not associated with the stateid, the server will return - NFS4ERR_LOCKED. If so, the client must check if the owner - corresponding to the stateid used with the WRITE operation has a - conflicting read lock that overlaps with the region that was to be - written. If the stateid's owner has no conflicting read lock, then - the client should try to get the appropriate write byte-range lock - via the LOCK operation before re-attempting the WRITE. When the - WRITE completes, the client should release the byte-range lock via - LOCKU. + In the case that the current filehandle is of type NF4DIR, the server + will return NFS4ERR_ISDIR. If the current file is a symbolic link, + the error NFS4ERR_SYMLINK will be returned. Otherwise, if the + current filehandle does not designate an ordinary file, the server + will return NFS4ERR_WRONG_TYPE. + + If mandatory file locking is in effect for the file, and the + corresponding byte-range of the data to be written to the file is + read or write locked by an owner that is not associated with the + stateid, the server MUST return NFS4ERR_LOCKED. If so, the client + MUST check if the owner corresponding to the stateid used with the + WRITE operation has a conflicting read lock that overlaps with the + region that was to be written. If the stateid's owner has no + conflicting read lock, then the client SHOULD try to get the + appropriate write byte-range lock via the LOCK operation before re- + attempting the WRITE. When the WRITE completes, the client SHOULD + release the byte-range lock via LOCKU. If the stateid's owner had a conflicting read lock, then the client has no choice but to return an error to the application that attempted the WRITE. The reason is that since the stateid's owner had a read lock, the server either attempted to temporarily effectively upgrade this read lock to a write lock, or the server has no upgrade capability. If the server attempted to upgrade the read lock and failed, it is pointless for the client to re-attempt the upgrade via the LOCK operation, because there might be another client also trying to upgrade. If two clients are blocked trying upgrade the same lock, the clients deadlock. If the server has no upgrade capability, then it is pointless to try a LOCK operation to upgrade. If one or more other clients have delegations for the file being - written, those delegations must be recalled, and the operation cannot + written, those delegations MUST be recalled, and the operation cannot proceed until those delegations are returned or revoked. Except where this happens very quickly, one or more NFS4ERR_DELAY errors will be returned to requests made while the delegation remains outstanding. Normally, delegations will not be recalled as a result of a WRITE operation since the recall will occur as a result of an earlier OPEN. However, since it is possible for a WRITE to be done with a special stateid, the server needs to check for this case even though the client should have done an OPEN previously. 18.33. Operation 40: BACKCHANNEL_CTL - Backchannel control @@ -23355,20 +23443,23 @@ be incremented. o Adding a function to create a new RPCSEC_GSS handle from a pointer to the wrapper data structure. The reference count would be incremented. o Replacing calls from RPCSEC_GSS that free GSS-API contexts, with calls to decrement the reference count on the wrapper data structure. + If the server cannot reserve space for the reply cache, it MAY return + NFS4ERR_NOSPC. + 18.37. Operation 44: DESTROY_SESSION - Destroy existing session Destroy existing session. 18.37.1. ARGUMENT struct DESTROY_SESSION4args { sessionid4 dsa_sessionid; }; @@ -24378,56 +24469,48 @@ 18.45.2. RESULT /* CURRENTFH: consumed if status is NFS4_OK */ typedef SECINFO4res SECINFO_NO_NAME4res; 18.45.3. DESCRIPTION Like the SECINFO operation, SECINFO_NO_NAME is used by the client to obtain a list of valid RPC authentication flavors for a specific file - object. Unlike SECINFO, SECINFO_NO_NAME only works with objects are - accessed by filehandle. + object. Unlike SECINFO, SECINFO_NO_NAME only works with objects that + are accessed by filehandle. There are two styles of SECINFO_NO_NAME, as determined by the value of the secinfo_style4 enumeration. If SECINFO_STYLE4_CURRENT_FH is passed, then SECINFO_NO_NAME is querying for the required security for the current filehandle. If SECINFO_STYLE4_PARENT is passed, then SECINFO_NO_NAME is querying for the required security of the current - filehandles's parent. If the style selected is - SECINFO_STYLE4_PARENT, then SECINFO should apply the same access - methodology used for LOOKUPP when evaluating the traversal to the - parent directory. Therefore, if the requester does not have the - appropriate access to LOOKUPP the parent then SECINFO_NO_NAME must - behave the same way and return NFS4ERR_ACCESS. + filehandle's parent. If the style selected is SECINFO_STYLE4_PARENT, + then SECINFO should apply the same access methodology used for + LOOKUPP when evaluating the traversal to the parent directory. - Note that if PUTFH, PUTPUBFH, or PUTROOTFH return NFS4ERR_WRONGSEC, - this is tantamount to the server asserting that the client will have - to guess what the required security is, because there is no way to - query. Therefore, the client must iterate through the security - triples available at the client and reattempt the PUTFH, PUTROOTFH or - PUTPUBFH operation. In the unfortunate event none of the REQUIRED - security triples are supported by the client and server, the client - SHOULD try using others that support integrity. Failing that, the - client can try using other forms (e.g. AUTH_SYS and AUTH_NONE), but - because such forms lack integrity checks, this puts the client at - risk. + Therefore, if the requester does not have the appropriate access to + LOOKUPP the parent then SECINFO_NO_NAME must behave the same way and + return NFS4ERR_ACCESS. - The server implementor should pay particular attention to Section 2.6 - for instructions on avoiding NFS4ERR_WRONGSEC error returns from + If PUTFH, PUTPUBFH, PUTROOTFH, or RESTOREFH return NFS4ERR_WRONGSEC, + then the client resolves the situation by sending a COMPOUND request + that consists of PUTFH, PUTPUBFH, or PUTROOTFH immediately followed + by SECINFO_NO_NAME, style SECINFO_STYLE4_CURRENT_FH. See Section 2.6 + for instructions on dealing with NFS4ERR_WRONGSEC error returns from PUTFH, PUTROOTFH, PUTPUBFH, or RESTOREFH. If SECINFO_STYLE4_PARENT is specified and there is no parent directory, SECINFO_NO_NAME MUST return NFS4ERR_NOENT. On success, the current filehandle is consumed (see - Section 2.6.3.1.8), and if the next operation after SECINFO_NO_NAME + Section 2.6.3.1.1.8), and if the next operation after SECINFO_NO_NAME tries to use the current filehandle, that operation will fail with the status NFS4ERR_NOFILEHANDLE. Everything else about SECINFO_NO_NAME is the same as SECINFO. See the discussion on SECINFO (Section 18.29.3). 18.45.4. IMPLEMENTATION See the discussion on SECINFO (Section 18.29.4). @@ -25391,21 +25474,21 @@ | NFS4ERR_INVAL | The tag argument is not in UTF-8 | | | encoding. | | NFS4ERR_MINOR_VERS_MISMATCH | | | NFS4ERR_SERVERFAULT | | | NFS4ERR_TOO_MANY_OPS | | | NFS4ERR_REP_TOO_BIG | | | NFS4ERR_REP_TOO_BIG_TO_CACHE | | | NFS4ERR_REQ_TOO_BIG | | +------------------------------+------------------------------------+ - Table 20 + Table 21 20. NFSv4.1 Callback Operations 20.1. Operation 3: CB_GETATTR - Get Attributes 20.1.1. ARGUMENT struct CB_GETATTR4args { nfs_fh4 fh; bitmap4 attr_request;