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

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/