draft-ietf-nfsv4-rfc3530bis-32.txt   draft-ietf-nfsv4-rfc3530bis-33.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft Primary Data
Obsoletes: 3530 (if approved) D. Noveck, Ed. Obsoletes: 3530 (if approved) D. Noveck, Ed.
Intended status: Standards Track March 04, 2014 Intended status: Standards Track
Expires: September 5, 2014 Expires: October 13, 2014 April 11, 2014
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-32.txt draft-ietf-nfsv4-rfc3530bis-33.txt
Abstract Abstract
The Network File System (NFS) version 4 is a distributed file system The Network File System (NFS) version 4 is a distributed file system
protocol which builds on the heritage of NFS protocol version 2, RFC protocol which builds on the heritage of NFS protocol version 2, RFC
1094, and version 3, RFC 1813. Unlike earlier versions, the NFS 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS
version 4 protocol supports traditional file access while integrating version 4 protocol supports traditional file access while integrating
support for file locking and the mount protocol. In addition, support for file locking and the mount protocol. In addition,
support for strong security (and its negotiation), compound support for strong security (and its negotiation), compound
operations, client caching, and internationalization have been added. operations, client caching, and internationalization have been added.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
This document, together with the companion XDR description document, This document, together with the companion XDR description document,
RFCNFSv4XDR, obsoletes RFC 3530 as the definition of the NFS version RFCNFSv4XDR, obsoletes RFC 3530 as the definition of the NFS version
4 protocol. 4 protocol.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 5, 2014. This Internet-Draft will expire on October 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. NFS Version 4 Goals . . . . . . . . . . . . . . . . . . 9 1.1. NFS Version 4 Goals . . . . . . . . . . . . . . . . . . . 7
1.2. Definitions in the companion document NFS Version 4 1.2. Definitions in the companion document NFS Version 4
Protocol are Authoritative . . . . . . . . . . . . . . . 9 Protocol are Authoritative . . . . . . . . . . . . . . . 8
1.3. Overview of NFSv4 Features . . . . . . . . . . . . . . . 10 1.3. Overview of NFSv4 Features . . . . . . . . . . . . . . . 8
1.3.1. RPC and Security . . . . . . . . . . . . . . . . . . 10 1.3.1. RPC and Security . . . . . . . . . . . . . . . . . . 9
1.3.2. Procedure and Operation Structure . . . . . . . . . 10 1.3.2. Procedure and Operation Structure . . . . . . . . . . 9
1.3.3. Filesystem Model . . . . . . . . . . . . . . . . . . 11 1.3.3. Filesystem Model . . . . . . . . . . . . . . . . . . 10
1.3.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 13 1.3.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 12
1.3.5. File Locking . . . . . . . . . . . . . . . . . . . . 13 1.3.5. File Locking . . . . . . . . . . . . . . . . . . . . 12
1.3.6. Client Caching and Delegation . . . . . . . . . . . 13 1.3.6. Client Caching and Delegation . . . . . . . . . . . . 12
1.4. General Definitions . . . . . . . . . . . . . . . . . . 14 1.4. General Definitions . . . . . . . . . . . . . . . . . . . 13
1.5. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 16 1.5. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 15
1.6. Changes since RFC 3010 . . . . . . . . . . . . . . . . . 17 1.6. Changes since RFC 3010 . . . . . . . . . . . . . . . . . 15
2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 18 2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 16
2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 18 2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 16
2.2. Structured Data Types . . . . . . . . . . . . . . . . . 20 2.2. Structured Data Types . . . . . . . . . . . . . . . . . . 18
3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 24 3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 22
3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 24 3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 23
3.1.1. Client Retransmission Behavior . . . . . . . . . . . 25 3.1.1. Client Retransmission Behavior . . . . . . . . . . . 23
3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 26 3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 24
3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . 26 3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . . 24
3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 27 3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 26
3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . 28 3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 28 3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 26
3.3.3. Callback RPC Authentication . . . . . . . . . . . . 28 3.3.3. Callback RPC Authentication . . . . . . . . . . . . . 27
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 29 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 29 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 28
4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 30 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . . 28
4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 30 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . . 29
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 30 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 29
4.2.1. General Properties of a Filehandle . . . . . . . . . 31 4.2.1. General Properties of a Filehandle . . . . . . . . . 29
4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 31 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . . 30
4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 32 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . . 30
4.2.4. One Method of Constructing a Volatile Filehandle . . 33 4.2.4. One Method of Constructing a Volatile Filehandle . . 32
4.3. Client Recovery from Filehandle Expiration . . . . . . . 34 4.3. Client Recovery from Filehandle Expiration . . . . . . . 32
5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 34 5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 36 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . . 34
5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 36 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 35
5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 36 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 35
5.4. Classification of Attributes . . . . . . . . . . . . . . 38 5.4. Classification of Attributes . . . . . . . . . . . . . . 36
5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 39 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 37
5.6. REQUIRED Attributes - List and Definition References . . 39 5.6. REQUIRED Attributes - List and Definition References . . 38
5.7. RECOMMENDED Attributes - List and Definition 5.7. RECOMMENDED Attributes - List and Definition References . 38
References . . . . . . . . . . . . . . . . . . . . . . . 40 5.8. Attribute Definitions . . . . . . . . . . . . . . . . . . 40
5.8. Attribute Definitions . . . . . . . . . . . . . . . . . 41 5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 40
5.8.1. Definitions of REQUIRED Attributes . . . . . . . . . 41 5.8.2. Definitions of Uncategorized RECOMMENDED Attributes . 42
5.8.2. Definitions of Uncategorized RECOMMENDED 5.9. Interpreting owner and owner_group . . . . . . . . . . . 48
Attributes . . . . . . . . . . . . . . . . . . . . . 43 5.10. Character Case Attributes . . . . . . . . . . . . . . . . 51
5.9. Interpreting owner and owner_group . . . . . . . . . . . 49 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 51
5.10. Character Case Attributes . . . . . . . . . . . . . . . 52 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6. Access Control Attributes . . . . . . . . . . . . . . . . . . 53 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 52
6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . . 52
6.2. File Attributes Discussion . . . . . . . . . . . . . . . 54 6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 67
6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 54 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 67
6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 68 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . . 68
6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 69 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 69
6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 69 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 70
6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 70 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 70
6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 71 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . . 71
6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 71 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 72
6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 73 7. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 73
6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 73 7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 73
7. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 75 7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 74
7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 75 7.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 74
7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 75 7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 75
7.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 76 7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . . 75
7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 76 7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . . 75
7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 76 7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 76
7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 77 7.8. Security Policy and Name Space Presentation . . . . . . . 76
7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 77 8. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 77
7.8. Security Policy and Name Space Presentation . . . . . . 77 8.1. Location Attributes . . . . . . . . . . . . . . . . . . . 77
8. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 78 8.2. File System Presence or Absence . . . . . . . . . . . . . 77
8.1. Location Attributes . . . . . . . . . . . . . . . . . . 78 8.3. Getting Attributes for an Absent File System . . . . . . 78
8.2. File System Presence or Absence . . . . . . . . . . . . 79 8.3.1. GETATTR Within an Absent File System . . . . . . . . 79
8.3. Getting Attributes for an Absent File System . . . . . . 80 8.3.2. READDIR and Absent File Systems . . . . . . . . . . . 80
8.3.1. GETATTR Within an Absent File System . . . . . . . . 80 8.4. Uses of Location Information . . . . . . . . . . . . . . 80
8.3.2. READDIR and Absent File Systems . . . . . . . . . . 81 8.4.1. File System Replication . . . . . . . . . . . . . . . 81
8.4. Uses of Location Information . . . . . . . . . . . . . . 82 8.4.2. File System Migration . . . . . . . . . . . . . . . . 82
8.4.1. File System Replication . . . . . . . . . . . . . . 82 8.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . . 83
8.4.2. File System Migration . . . . . . . . . . . . . . . 83 8.5. Location Entries and Server Identity . . . . . . . . . . 83
8.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 84 8.6. Additional Client-Side Considerations . . . . . . . . . . 84
8.5. Location Entries and Server Identity . . . . . . . . . . 85 8.7. Effecting File System Referrals . . . . . . . . . . . . . 85
8.6. Additional Client-Side Considerations . . . . . . . . . 85 8.7.1. Referral Example (LOOKUP) . . . . . . . . . . . . . . 85
8.7. Effecting File System Referrals . . . . . . . . . . . . 86 8.7.2. Referral Example (READDIR) . . . . . . . . . . . . . 89
8.7.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 87 8.8. The Attribute fs_locations . . . . . . . . . . . . . . . 92
8.7.2. Referral Example (READDIR) . . . . . . . . . . . . . 90 8.8.1. Inferring Transition Modes . . . . . . . . . . . . . 93
8.8. The Attribute fs_locations . . . . . . . . . . . . . . . 93 9. File Locking and Share Reservations . . . . . . . . . . . . . 95
8.8.1. Inferring Transition Modes . . . . . . . . . . . . . 95 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 96
9. File Locking and Share Reservations . . . . . . . . . . . . . 96 9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . . 96
9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 97 9.1.2. Server Release of Client ID . . . . . . . . . . . . . 99
9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 97 9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 100
9.1.2. Server Release of Client ID . . . . . . . . . . . . 100 9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 106
9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 101 9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 106
9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 107 9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . . 109
9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 107 9.1.7. Recovery from Replayed Requests . . . . . . . . . . . 110
9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 110 9.1.8. Interactions of multiple sequence values . . . . . . 110
9.1.7. Recovery from Replayed Requests . . . . . . . . . . 111 9.1.9. Releasing state-owner State . . . . . . . . . . . . . 111
9.1.8. Interactions of multiple sequence values . . . . . . 111 9.1.10. Use of Open Confirmation . . . . . . . . . . . . . . 112
9.1.9. Releasing state-owner State . . . . . . . . . . . . 112 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . . 113
9.1.10. Use of Open Confirmation . . . . . . . . . . . . . . 113 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . . 113
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 114 9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 114
9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 114 9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . . 115
9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 115 9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 115
9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 116 9.6.1. Client Failure and Recovery . . . . . . . . . . . . . 116
9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 116 9.6.2. Server Failure and Recovery . . . . . . . . . . . . . 116
9.6.1. Client Failure and Recovery . . . . . . . . . . . . 117 9.6.3. Network Partitions and Recovery . . . . . . . . . . . 118
9.6.2. Server Failure and Recovery . . . . . . . . . . . . 117 9.7. Recovery from a Lock Request Timeout or Abort . . . . . . 126
9.6.3. Network Partitions and Recovery . . . . . . . . . . 119 9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 126
9.7. Recovery from a Lock Request Timeout or Abort . . . . . 127 9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 127
9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 127 9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . . 128
9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 128 9.10.1. Close and Retention of State Information . . . . . . 129
9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 129 9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 129
9.10.1. Close and Retention of State Information . . . . . . 130 9.12. Short and Long Leases . . . . . . . . . . . . . . . . . . 130
9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 130 9.13. Clocks, Propagation Delay, and Calculating Lease
9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 131 Expiration . . . . . . . . . . . . . . . . . . . . . . . 131
9.13. Clocks, Propagation Delay, and Calculating Lease 9.14. Migration, Replication and State . . . . . . . . . . . . 131
Expiration . . . . . . . . . . . . . . . . . . . . . . . 132 9.14.1. Migration and State . . . . . . . . . . . . . . . . 132
9.14. Migration, Replication and State . . . . . . . . . . . . 132 9.14.2. Replication and State . . . . . . . . . . . . . . . 132
9.14.1. Migration and State . . . . . . . . . . . . . . . . 133 9.14.3. Notification of Migrated Lease . . . . . . . . . . . 133
9.14.2. Replication and State . . . . . . . . . . . . . . . 133 9.14.4. Migration and the Lease_time Attribute . . . . . . . 134
9.14.3. Notification of Migrated Lease . . . . . . . . . . . 134 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 134
9.14.4. Migration and the Lease_time Attribute . . . . . . . 135 10.1. Performance Challenges for Client-Side Caching . . . . . 135
10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 135 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 136
10.1. Performance Challenges for Client-Side Caching . . . . . 136 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 137
10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 137 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 142
10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 138 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 142
10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 143 10.3.2. Data Caching and File Locking . . . . . . . . . . . 143
10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 143 10.3.3. Data Caching and Mandatory File Locking . . . . . . 145
10.3.2. Data Caching and File Locking . . . . . . . . . . . 144 10.3.4. Data Caching and File Identity . . . . . . . . . . . 145
10.3.3. Data Caching and Mandatory File Locking . . . . . . 146 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 146
10.3.4. Data Caching and File Identity . . . . . . . . . . . 146 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 149
10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 147 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 150
10.4.1. Open Delegation and Data Caching . . . . . . . . . . 150 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 150
10.4.2. Open Delegation and File Locks . . . . . . . . . . . 151 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 153
10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 151 10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 155
10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 154 10.4.6. Clients that Fail to Honor Delegation Recalls . . . 156
10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 156 10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 157
10.4.6. Clients that Fail to Honor Delegation Recalls . . . 157 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 157
10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 158 10.5.1. Revocation Recovery for Write Open Delegation . . . 158
10.5. Data Caching and Revocation . . . . . . . . . . . . . . 158 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 159
10.5.1. Revocation Recovery for Write Open Delegation . . . 159 10.7. Data and Metadata Caching and Memory Mapped Files . . . 161
10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 163
10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 160 10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 164
10.7. Data and Metadata Caching and Memory Mapped Files . . . 162 11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 165
10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 164 12. Internationalization . . . . . . . . . . . . . . . . . . . . 167
10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 165 12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 167
11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 166 12.2. Limitations on internationalization-related processing
12. Internationalization . . . . . . . . . . . . . . . . . . . . 168 in the NFSv4 context . . . . . . . . . . . . . . . . . . 169
12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 168 12.3. Summary of Server Behavior Types . . . . . . . . . . . . 170
12.2. Limitations on internationalization-related 12.4. String Encoding . . . . . . . . . . . . . . . . . . . . 170
processing in the NFSv4 context . . . . . . . . . . . . 170 12.5. Normalization . . . . . . . . . . . . . . . . . . . . . 171
12.3. Summary of Server Behavior Types . . . . . . . . . . . . 171 12.6. Types with Processing Defined by Other Internet Areas . 172
12.4. String Encoding . . . . . . . . . . . . . . . . . . . . 171 12.7. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 173
12.5. Normalization . . . . . . . . . . . . . . . . . . . . . 172
12.6. Types with Processing Defined by Other Internet Areas . 173
12.7. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 174
12.8. Servers that accept file component names that are not 12.8. Servers that accept file component names that are not
valid UTF-8 strings . . . . . . . . . . . . . . . . . . 174 valid UTF-8 strings . . . . . . . . . . . . . . . . . . 174
13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 175 13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 175
13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 175 13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 175
13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 177 13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 177
13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 178 13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 178
13.1.3. Compound Structure Errors . . . . . . . . . . . . . 180 13.1.3. Compound Structure Errors . . . . . . . . . . . . . 179
13.1.4. File System Errors . . . . . . . . . . . . . . . . . 181 13.1.4. File System Errors . . . . . . . . . . . . . . . . . 180
13.1.5. State Management Errors . . . . . . . . . . . . . . 183 13.1.5. State Management Errors . . . . . . . . . . . . . . 182
13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 184 13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 183
13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 184 13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 184
13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 185 13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 184
13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 186 13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 186
13.1.10. Client Management Errors . . . . . . . . . . . . . . 187 13.1.10. Client Management Errors . . . . . . . . . . . . . . 187
13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 187 13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 187
13.2. Operations and their valid errors . . . . . . . . . . . 188 13.2. Operations and their valid errors . . . . . . . . . . . 188
13.3. Callback operations and their valid errors . . . . . . . 195 13.3. Callback operations and their valid errors . . . . . . . 195
13.4. Errors and the operations that use them . . . . . . . . 196 13.4. Errors and the operations that use them . . . . . . . . 196
14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 200 14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 201
14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 201 14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 201
14.2. Evaluation of a Compound Request . . . . . . . . . . . . 201 14.2. Evaluation of a Compound Request . . . . . . . . . . . . 202
14.3. Synchronous Modifying Operations . . . . . . . . . . . . 202 14.3. Synchronous Modifying Operations . . . . . . . . . . . . 203
14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 202 14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 203
15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 203 15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 203
15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 203 15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 203
15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 203 15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 204
15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 207 15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 208
15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 210 15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 210
15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 211 15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 211
15.6. Operation 6: CREATE - Create a Non-Regular File Object . 213 15.6. Operation 6: CREATE - Create a Non-Regular File Object . 214
15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting 15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 216 Recovery . . . . . . . . . . . . . . . . . . . . . . . . 217
15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 217 15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 218
15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 218 15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 219
15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 220 15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 221
15.11. Operation 11: LINK - Create Link to a File . . . . . . . 221 15.11. Operation 11: LINK - Create Link to a File . . . . . . . 221
15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 222 15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 223
15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 226 15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 227
15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 228 15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 229
15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 229 15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 230
15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 231 15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 232
15.17. Operation 17: NVERIFY - Verify Difference in 15.17. Operation 17: NVERIFY - Verify Difference in Attributes 233
Attributes . . . . . . . . . . . . . . . . . . . . . . . 232 15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 234
15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 233 15.19. Operation 19: OPENATTR - Open Named Attribute Directory 244
15.19. Operation 19: OPENATTR - Open Named Attribute 15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 245
Directory . . . . . . . . . . . . . . . . . . . . . . . 243 15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 247
15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 244 15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 249
15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 246 15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 249
15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 247 15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 251
15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 248 15.25. Operation 25: READ - Read from File . . . . . . . . . . 252
15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 249 15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 254
15.25. Operation 25: READ - Read from File . . . . . . . . . . 250 15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 258
15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 252 15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 259
15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 256 15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 260
15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 257 15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 262
15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 259 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 264
15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 261 15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 265
15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 262 15.33. Operation 33: SECINFO - Obtain Available Security . . . 265
15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 263 15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 269
15.33. Operation 33: SECINFO - Obtain Available Security . . . 264 15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 271
15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 268 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 275
15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 270 15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 278
15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 274 15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 280
15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 277
15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 279
15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner
State . . . . . . . . . . . . . . . . . . . . . . . . . 283 State . . . . . . . . . . . . . . . . . . . . . . . . . 284
15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 284 15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 285
16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 285 16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 286
16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 285 16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 286
16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 285 16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 286
16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 287 16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 288
16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 288 16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 289
16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback 16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation . . . . . . . . . . . . . . . . . . . . . 289 Operation . . . . . . . . . . . . . . . . . . . . . 290
17. Security Considerations . . . . . . . . . . . . . . . . . . . 290 17. Security Considerations . . . . . . . . . . . . . . . . . . . 291
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 292 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 293
18.1. Named Attribute Definitions . . . . . . . . . . . . . . 292 18.1. Named Attribute Definitions . . . . . . . . . . . . . . 293
18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 293 18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 294
18.1.2. Updating Registrations . . . . . . . . . . . . . . . 293 18.1.2. Updating Registrations . . . . . . . . . . . . . . . 294
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 293 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 294
19.1. Normative References . . . . . . . . . . . . . . . . . . 293 19.1. Normative References . . . . . . . . . . . . . . . . . . 294
19.2. Informative References . . . . . . . . . . . . . . . . . 294 19.2. Informative References . . . . . . . . . . . . . . . . . 296
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 297 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 298
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 298 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 299
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 298 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 300
1. Introduction 1. Introduction
1.1. NFS Version 4 Goals 1.1. NFS Version 4 Goals
The Network Filesystem version 4 (NFSv4) protocol is a further The Network Filesystem version 4 (NFSv4) protocol is a further
revision of the NFS protocol defined already by versions 2 [RFC1094] revision of the NFS protocol defined already by versions 2 [RFC1094]
and 3 [RFC1813]. It retains the essential characteristics of and 3 [RFC1813]. It retains the essential characteristics of
previous versions: design for easy recovery, independent of transport previous versions: design for easy recovery, independent of transport
protocols, operating systems and file systems, simplicity, and good protocols, operating systems and file systems, simplicity, and good
skipping to change at page 9, line 44 skipping to change at page 8, line 25
The protocol features a file system model that provides a useful, The protocol features a file system model that provides a useful,
common set of features that does not unduly favor one file system common set of features that does not unduly favor one file system
or operating system over another. or operating system over another.
o Designed for protocol extensions. o Designed for protocol extensions.
The protocol is designed to accept standard extensions that do not The protocol is designed to accept standard extensions that do not
compromise backward compatibility. compromise backward compatibility.
This document, together with the companion XDR description document This document, together with the companion XDR description document
[I-D.ietf-nfsv4-rfc3530bis-dot-x], obsoletes RFC 3530 [RFC3530] as [RFCNFSv4XDR], obsoletes [RFC3530] as the authoritative document
the authoritative document describing NFSv4. It does not introduce describing NFSv4. It does not introduce any over-the-wire protocol
any over-the-wire protocol changes, in the sense that previously changes, in the sense that previously valid requests remain valid.
valid requests remain valid.
1.2. Definitions in the companion document NFS Version 4 Protocol are 1.2. Definitions in the companion document NFS Version 4 Protocol are
Authoritative Authoritative
[I-D.ietf-nfsv4-rfc3530bis-dot-x], NFS Version 4 Protocol, contains [RFCNFSv4XDR], NFS Version 4 Protocol, contains the definitions in
the definitions in XDR description language of the constructs used by XDR description language of the constructs used by the protocol.
the protocol. Inside this document, several of the constructs are Inside this document, several of the constructs are reproduced for
reproduced for purposes of explanation. The reader is warned of the purposes of explanation. The reader is warned of the possibility of
possibility of errors in the reproduced constructs outside of errors in the reproduced constructs outside of [RFCNFSv4XDR]. For
[I-D.ietf-nfsv4-rfc3530bis-dot-x]. For any part of the document that any part of the document that is inconsistent with [RFCNFSv4XDR],
is inconsistent with [I-D.ietf-nfsv4-rfc3530bis-dot-x], [RFCNFSv4XDR] is to be considered authoritative.
[I-D.ietf-nfsv4-rfc3530bis-dot-x] is to be considered authoritative.
1.3. Overview of NFSv4 Features 1.3. Overview of NFSv4 Features
To provide a reasonable context for the reader, the major features of To provide a reasonable context for the reader, the major features of
NFSv4 protocol will be reviewed in brief. This will be done to NFSv4 protocol will be reviewed in brief. This will be done to
provide an appropriate context for both the reader who is familiar provide an appropriate context for both the reader who is familiar
with the previous versions of the NFS protocol and the reader who is with the previous versions of the NFS protocol and the reader who is
new to the NFS protocols. For the reader new to the NFS protocols, new to the NFS protocols. For the reader new to the NFS protocols,
some fundamental knowledge is still expected. The reader should be some fundamental knowledge is still expected. The reader should be
familiar with the XDR and RPC protocols as described in [RFC5531] and familiar with the XDR and RPC protocols as described in [RFC5531] and
skipping to change at page 16, line 33 skipping to change at page 15, line 14
Verifier: A 64-bit quantity generated by the client that the server Verifier: A 64-bit quantity generated by the client that the server
can use to determine if the client has restarted and lost all can use to determine if the client has restarted and lost all
previous lock state. previous lock state.
1.5. Changes since RFC 3530 1.5. Changes since RFC 3530
The main changes from RFC 3530 [RFC3530] are: The main changes from RFC 3530 [RFC3530] are:
o The XDR definition has been moved to a companion document o The XDR definition has been moved to a companion document
[I-D.ietf-nfsv4-rfc3530bis-dot-x] [RFCNFSv4XDR]
o Updates for the latest IETF intellectual property statements o Updates for the latest IETF intellectual property statements
o There is a restructured and more complete explanation of multi- o There is a restructured and more complete explanation of multi-
server namespace features. server namespace features.
o Updating handling of domain names to reflect Internationalized o Updating handling of domain names to reflect Internationalized
Domain Names in Applications (IDNA) [RFC5891]. Domain Names in Applications (IDNA) [RFC5891].
o The previously required LIPKEY and SPKM-3 security mechanisms have o The previously required LIPKEY and SPKM-3 security mechanisms have
skipping to change at page 19, line 20 skipping to change at page 17, line 48
| | type is not really opaque. Instead it contains | | | type is not really opaque. Instead it contains |
| | an ASN.1 OBJECT IDENTIFIER as used by GSS-API | | | an ASN.1 OBJECT IDENTIFIER as used by GSS-API |
| | in the mech_type argument to | | | in the mech_type argument to |
| | GSS_Init_sec_context. See [RFC2743] for | | | GSS_Init_sec_context. See [RFC2743] for |
| | details. | | | details. |
| seqid4 | typedef uint32_t seqid4; | | seqid4 | typedef uint32_t seqid4; |
| | Sequence identifier used for file locking. | | | Sequence identifier used for file locking. |
| utf8string | typedef opaque utf8string<>; | | utf8string | typedef opaque utf8string<>; |
| | UTF-8 encoding for strings. | | | UTF-8 encoding for strings. |
| utf8str_cis | typedef utf8string utf8str_cis; | | utf8str_cis | typedef utf8string utf8str_cis; |
| | Case-insensitive UTF-8 string. | | | Case insensitive UTF-8 string. |
| utf8str_cs | typedef utf8string utf8str_cs; | | utf8str_cs | typedef utf8string utf8str_cs; |
| | Case-sensitive UTF-8 string. | | | Case sensitive UTF-8 string. |
| utf8str_mixed | typedef utf8string utf8str_mixed; | | utf8str_mixed | typedef utf8string utf8str_mixed; |
| | UTF-8 strings with a case-sensitive prefix and | | | UTF-8 strings with a case sensitive prefix and |
| | a case-insensitive suffix. | | | a case insensitive suffix. |
| component4 | typedef utf8str_cs component4; | | component4 | typedef utf8str_cs component4; |
| | Represents pathname components. | | | Represents pathname components. |
| linktext4<> | typedef opaque linktext4<>; | | linktext4 | typedef opaque linktext4; |
| | Symbolic link contents ("symbolic link" is | | | Symbolic link contents ("symbolic link" is |
| | defined in an Open Group [openg_symlink] | | | defined in an Open Group [openg_symlink] |
| | standard). | | | standard). |
| ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; | | ascii_REQUIRED4 | typedef utf8string ascii_REQUIRED4; |
| | String MUST be sent as ASCII and thus is | | | String MUST be sent as ASCII and thus is |
| | automatically UTF-8. | | | automatically UTF-8. |
| pathname4 | typedef component4 pathname4<>; | | pathname4 | typedef component4 pathname4<>; |
| | Represents path name for fs_locations. | | | Represents path name for fs_locations. |
| nfs_lockid4 | typedef uint64_t nfs_lockid4; | | nfs_lockid4 | typedef uint64_t nfs_lockid4; |
| verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; | | verifier4 | typedef opaque verifier4[NFS4_VERIFIER_SIZE]; |
skipping to change at page 24, line 38 skipping to change at page 23, line 15
3.1. Ports and Transports 3.1. Ports and Transports
Historically, NFSv2 and NFSv3 servers have resided on port 2049. The Historically, NFSv2 and NFSv3 servers have resided on port 2049. The
registered port 2049 [RFC3232] for the NFS protocol SHOULD be the registered port 2049 [RFC3232] for the NFS protocol SHOULD be the
default configuration. Using the registered port for NFS services default configuration. Using the registered port for NFS services
means the NFS client will not need to use the RPC binding protocols means the NFS client will not need to use the RPC binding protocols
as described in [RFC1833]; this will allow NFS to transit firewalls. as described in [RFC1833]; this will allow NFS to transit firewalls.
Where an NFSv4 implementation supports operation over the IP network Where an NFSv4 implementation supports operation over the IP network
protocol, the supported transport layer between NFS and IP MUST be an protocol, the supported transport layer between NFS and IP MUST be an
IETF standardised transport protocol that is specified to avoid IETF standardized transport protocol that is specified to avoid
network congestion; such transports include TCP and Stream Control network congestion; such transports include TCP and Stream Control
Transmission Protocol (SCTP). To enhance the possibilities for Transmission Protocol (SCTP). To enhance the possibilities for
interoperability, an NFSv4 implementation MUST support operation over interoperability, an NFSv4 implementation MUST support operation over
the TCP transport protocol. the TCP transport protocol.
If TCP is used as the transport, the client and server SHOULD use If TCP is used as the transport, the client and server SHOULD use
persistent connections. This will prevent the weakening of TCP's persistent connections. This will prevent the weakening of TCP's
congestion control via short lived connections and will improve congestion control via short lived connections and will improve
performance for the Wide Area Network (WAN) environment by performance for the Wide Area Network (WAN) environment by
eliminating the need for SYN handshakes. eliminating the need for SYN handshakes.
skipping to change at page 27, line 7 skipping to change at page 25, line 28
5 == NFSv4 clients MUST support 5 == NFSv4 clients MUST support
6 == NFSv4 servers MUST support 6 == NFSv4 servers MUST support
1 2 3 4 5 6 1 2 3 4 5 6
------------------------------------------------------------------ ------------------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 rpc_gss_svc_none yes yes 390003 krb5 1.2.840.113554.1.2.2 rpc_gss_svc_none yes yes
390004 krb5i 1.2.840.113554.1.2.2 rpc_gss_svc_integrity yes yes 390004 krb5i 1.2.840.113554.1.2.2 rpc_gss_svc_integrity yes yes
390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy no yes 390005 krb5p 1.2.840.113554.1.2.2 rpc_gss_svc_privacy no yes
Note that the pseudo flavor is presented here as a mapping aid to the Note that the pseudo flavor is presented here as a mapping aid to the
implementor. Because this NFS protocol includes a method to implementer. Because this NFS protocol includes a method to
negotiate security and it understands the GSS-API mechanism, the negotiate security and it understands the GSS-API mechanism, the
pseudo flavor is not needed. The pseudo flavor is needed for NFSv3 pseudo flavor is not needed. The pseudo flavor is needed for NFSv3
since the security negotiation is done via the MOUNT protocol as since the security negotiation is done via the MOUNT protocol as
described in [RFC2623]. described in [RFC2623].
At the time this document was specified, the Advanced Encryption At the time this document was specified, the Advanced Encryption
Standard (AES) with HMAC-SHA1 was a REQUIRED algorithm set for Standard (AES) with HMAC-SHA1 was a REQUIRED algorithm set for
Kerberos V5. In contrast, when NFSv4.0 was first specified in Kerberos V5. In contrast, when NFSv4.0 was first specified in
[RFC3530], weaker algorithm sets were REQUIRED for Kerberos V5, and [RFC3530], weaker algorithm sets were REQUIRED for Kerberos V5, and
were REQUIRED in the NFSv4.0 specification, because the Kerberos V5 were REQUIRED in the NFSv4.0 specification, because the Kerberos V5
specification at the time did not specify stronger algorithms. The specification at the time did not specify stronger algorithms. The
NFSv4 specification does not specify REQUIRED algorithms for Kerberos NFSv4 specification does not specify REQUIRED algorithms for Kerberos
V5, and instead, the implementor is expected to track the evolution V5, and instead, the implementer is expected to track the evolution
of the Kerberos V5 standard if and when stronger algorithms are of the Kerberos V5 standard if and when stronger algorithms are
specified. specified.
3.2.1.1.1. Security Considerations for Cryptographic Algorithms in 3.2.1.1.1. Security Considerations for Cryptographic Algorithms in
Kerberos V5 Kerberos V5
When deploying NFSv4, the strength of the security achieved depends When deploying NFSv4, the strength of the security achieved depends
on the existing Kerberos V5 infrastructure. The algorithms of on the existing Kerberos V5 infrastructure. The algorithms of
Kerberos V5 are not directly exposed to or selectable by the client Kerberos V5 are not directly exposed to or selectable by the client
or server, so there is some due diligence required by the user of or server, so there is some due diligence required by the user of
skipping to change at page 35, line 38 skipping to change at page 34, line 17
+----------+-----------+---------------------------------+ +----------+-----------+---------------------------------+
| LOOKUP | "foo" | ; look up file | | LOOKUP | "foo" | ; look up file |
| GETATTR | attrbits | | | GETATTR | attrbits | |
| OPENATTR | | ; access foo's named attributes | | OPENATTR | | ; access foo's named attributes |
| LOOKUP | "x11icon" | ; look up specific attribute | | LOOKUP | "x11icon" | ; look up specific attribute |
| READ | 0,4096 | ; read stream of bytes | | READ | 0,4096 | ; read stream of bytes |
+----------+-----------+---------------------------------+ +----------+-----------+---------------------------------+
Named attributes are intended for data needed by applications rather Named attributes are intended for data needed by applications rather
than by an NFS client implementation. NFS implementors are strongly than by an NFS client implementation. NFS implementers are strongly
encouraged to define their new attributes as RECOMMENDED attributes encouraged to define their new attributes as RECOMMENDED attributes
by bringing them to the IETF Standards Track process. by bringing them to the IETF Standards Track process.
The set of attributes that are classified as REQUIRED is deliberately The set of attributes that are classified as REQUIRED is deliberately
small since servers need to do whatever it takes to support them. A small since servers need to do whatever it takes to support them. A
server should support as many of the RECOMMENDED attributes as server should support as many of the RECOMMENDED attributes as
possible but, by their definition, the server is not required to possible but, by their definition, the server is not required to
support all of them. Attributes are deemed REQUIRED if the data is support all of them. Attributes are deemed REQUIRED if the data is
both needed by a large number of clients and is not otherwise both needed by a large number of clients and is not otherwise
reasonably computable by the client when support is not provided on reasonably computable by the client when support is not provided on
skipping to change at page 39, line 25 skipping to change at page 38, line 13
MUST return NFS4ERR_INVAL. MUST return NFS4ERR_INVAL.
5.6. REQUIRED Attributes - List and Definition References 5.6. REQUIRED Attributes - List and Definition References
The list of REQUIRED attributes appears in Table 2. The meaning of The list of REQUIRED attributes appears in Table 2. The meaning of
the columns of the table are: the 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 conflicts between the assigned number and [RFCNFSv4XDR], the
[I-D.ietf-nfsv4-rfc3530bis-dot-x], the latter is authoritative, latter is authoritative, but in such an event, it should be
but in such an event, it should be resolved with Errata to this resolved with Errata to this document and/or [RFCNFSv4XDR]. See
document and/or [I-D.ietf-nfsv4-rfc3530bis-dot-x]. See
[ISEG_errata] for the Errata process. [ISEG_errata] for the Errata process.
o Data Type: The XDR data type of the attribute. o Data Type: The XDR data type of the attribute.
o Acc: Access allowed to the attribute. R means read-only (GETATTR o Acc: Access allowed to the attribute. R means read-only (GETATTR
may retrieve, SETATTR may not set). W means write-only (SETATTR may retrieve, SETATTR may not set). W means write-only (SETATTR
may set, GETATTR may not retrieve). R W means read/write (GETATTR may set, GETATTR may not retrieve). R W means read/write (GETATTR
may retrieve, SETATTR may set). 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 | R | Section 5.8.1.1 | | supported_attrs | 0 | bitmap4 | R | Section 5.8.1.1 |
| type | 1 | nfs_ftype4 | R | Section 5.8.1.2 | | type | 1 | nfs_ftype4 | R | Section 5.8.1.2 |
| fh_expire_type | 2 | uint32_t | R | Section 5.8.1.3 | | fh_expire_type | 2 | uint32_t | R | Section 5.8.1.3 |
| change | 3 | uint64_t | R | 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 | R | Section 5.8.1.6 | | link_support | 5 | bool | R | Section 5.8.1.6 |
| symlink_support | 6 | bool | R | Section 5.8.1.7 | | symlink_support | 6 | bool | R | Section 5.8.1.7 |
| named_attr | 7 | bool | R | Section 5.8.1.8 | | named_attr | 7 | bool | R | Section 5.8.1.8 |
| fsid | 8 | fsid4 | R | Section 5.8.1.9 | | fsid | 8 | fsid4 | R | Section 5.8.1.9 |
| unique_handles | 9 | bool | R | Section 5.8.1.10 | | unique_handles | 9 | bool | R | Section 5.8.1.10 |
| lease_time | 10 | nfs_lease4 | R | Section 5.8.1.11 | | lease_time | 10 | nfs_lease4 | R | Section 5.8.1.11 |
| rdattr_error | 11 | nfsstat4 | R | Section 5.8.1.12 | | rdattr_error | 11 | nfsstat4 | R | Section 5.8.1.12 |
| filehandle | 19 | nfs_fh4 | R | Section 5.8.1.13 | | filehandle | 19 | nfs_fh4 | R | Section 5.8.1.13 |
+-----------------+----+------------+-----+------------------+ +-----------------+----+------------+-----+-------------------+
Table 2 Table 2
5.7. RECOMMENDED Attributes - List and Definition References 5.7. RECOMMENDED Attributes - List and Definition References
The RECOMMENDED attributes are defined in Table 3. The meanings of The RECOMMENDED attributes are defined in Table 3. The meanings of
the column headers are the same as Table 2; see Section 5.6 for the the column headers are the same as Table 2; see Section 5.6 for the
meanings. meanings.
+-------------------+----+-----------------+-----+------------------+ +-------------------+----+-----------------+-----+------------------+
skipping to change at page 41, line 22 skipping to change at page 39, line 45
| quota_avail_hard | 38 | uint64_t | R | Section 5.8.2.24 | | quota_avail_hard | 38 | uint64_t | R | Section 5.8.2.24 |
| quota_avail_soft | 39 | uint64_t | R | Section 5.8.2.25 | | quota_avail_soft | 39 | uint64_t | R | Section 5.8.2.25 |
| quota_used | 40 | uint64_t | R | Section 5.8.2.26 | | quota_used | 40 | uint64_t | R | Section 5.8.2.26 |
| rawdev | 41 | specdata4 | R | Section 5.8.2.27 | | rawdev | 41 | specdata4 | R | Section 5.8.2.27 |
| space_avail | 42 | uint64_t | R | Section 5.8.2.28 | | space_avail | 42 | uint64_t | R | Section 5.8.2.28 |
| space_free | 43 | uint64_t | R | Section 5.8.2.29 | | space_free | 43 | uint64_t | R | Section 5.8.2.29 |
| space_total | 44 | uint64_t | R | Section 5.8.2.30 | | space_total | 44 | uint64_t | R | Section 5.8.2.30 |
| space_used | 45 | uint64_t | R | Section 5.8.2.31 | | space_used | 45 | uint64_t | R | Section 5.8.2.31 |
| system | 46 | bool | R W | Section 5.8.2.32 | | system | 46 | bool | R W | Section 5.8.2.32 |
| time_access | 47 | nfstime4 | R | Section 5.8.2.33 | | time_access | 47 | nfstime4 | R | Section 5.8.2.33 |
| time_access_set | 48 | settime4 | W | Section 5.8.2.34 | | time_access_set | 48 | settime4 | W | Section 5.8.2.34 |
| time_backup | 49 | nfstime4 | R W | Section 5.8.2.35 | | time_backup | 49 | nfstime4 | R W | Section 5.8.2.35 |
| time_create | 50 | nfstime4 | R W | Section 5.8.2.36 | | time_create | 50 | nfstime4 | R W | Section 5.8.2.36 |
| time_delta | 51 | nfstime4 | R | Section 5.8.2.37 | | time_delta | 51 | nfstime4 | R | Section 5.8.2.37 |
| time_metadata | 52 | nfstime4 | R | Section 5.8.2.38 | | time_metadata | 52 | nfstime4 | R | Section 5.8.2.38 |
| time_modify | 53 | nfstime4 | R | Section 5.8.2.39 | | time_modify | 53 | nfstime4 | R | Section 5.8.2.39 |
| time_modify_set | 54 | settime4 | W | Section 5.8.2.40 | | time_modify_set | 54 | settime4 | W | Section 5.8.2.40 |
+-------------------+----+-----------------+-----+------------------+ +-------------------+----+-----------------+-----+------------------+
Table 3 Table 3
5.8. Attribute Definitions 5.8. Attribute Definitions
5.8.1. Definitions of REQUIRED Attributes 5.8.1. Definitions of REQUIRED Attributes
5.8.1.1. Attribute 0: supported_attrs 5.8.1.1. Attribute 0: supported_attrs
The bit vector that would retrieve all REQUIRED and RECOMMENDED The bit vector that would retrieve all REQUIRED and RECOMMENDED
attributes that are supported for this object. The scope of this attributes that are supported for this object. The scope of this
skipping to change at page 49, line 51 skipping to change at page 48, line 34
and groups used as values of the "who" field within nfs4ace and groups used as values of the "who" field within nfs4ace
structures used in the acl attribute) are represented in the form of structures used in the acl attribute) are represented in the form of
UTF-8 strings. This format avoids use of a representation that is UTF-8 strings. This format avoids use of a representation that is
tied to a particular underlying implementation at the client or tied to a particular underlying implementation at the client or
server. Note that section 6.1 of [RFC2624] provides additional server. Note that section 6.1 of [RFC2624] provides additional
rationale. It is expected that the client and server will have their rationale. It is expected that the client and server will have their
own local representation of owners and groups that is used for local own local representation of owners and groups that is used for local
storage or presentation to the application via API's that expect such storage or presentation to the application via API's that expect such
a representation. Therefore, the protocol requires that when these a representation. Therefore, the protocol requires that when these
attributes are transferred between the client and server, the local attributes are transferred between the client and server, the local
representation is translated to a string of the form "identifier@ representation is translated to a string of the form
dns_domain". This allows clients and servers that do not use the "identifier@dns_domain". This allows clients and servers that do not
same local representation to effectively interoperate since they both use the same local representation to effectively interoperate since
use a common syntax that can be interpreted by both. they both use a common syntax that can be interpreted by both.
Similarly, security principals may be represented in different ways Similarly, security principals may be represented in different ways
by different security mechanisms. Servers normally translate these by different security mechanisms. Servers normally translate these
representations into a common format, generally that used by local representations into a common format, generally that used by local
storage, to serve as a means of identifying the users corresponding storage, to serve as a means of identifying the users corresponding
to these security principals. When these local identifiers are to these security principals. When these local identifiers are
translated to the form of the owner attribute, associated with files translated to the form of the owner attribute, associated with files
created by such principals, they identify, in a common format, the created by such principals, they identify, in a common format, the
users associated with each corresponding set of security principals. users associated with each corresponding set of security principals.
skipping to change at page 51, line 23 skipping to change at page 50, line 7
As mentioned above, it is desirable that a server when accepting a As mentioned above, it is desirable that a server when accepting a
string of the form "user@domain" or "group@domain" in an attribute, string of the form "user@domain" or "group@domain" in an attribute,
return this same string when that corresponding attribute is fetched. return this same string when that corresponding attribute is fetched.
Internationalization issues (for a general discussion of which see Internationalization issues (for a general discussion of which see
Section 12) may make this impossible and the client needs to take Section 12) may make this impossible and the client needs to take
note of the following situations: note of the following situations:
o The string representing the domain may be converted to an o The string representing the domain may be converted to an
equivalent U-label (see [RFC5890]), if presented using a form equivalent U-label (see [RFC5890]), if presented using a form
other than an U-label. See Section 12.6 for details. other than a U-label. See Section 12.6 for details.
o The user or group may be returned in a different form, as a result o The user or group may be returned or used for verification in a
of Unicode normalization at the server. The result SHOULD be a different form, as a result of Unicode normalization at the
canonically equivalent Unicode string [UNICODE]. Other sorts of server. The result SHOULD be a canonically equivalent Unicode
string modification, including case mapping or folding, SHOULD NOT string [UNICODE]. Other sorts of string modification, including
be done as such modifications may cause the server to merge case mapping or folding, SHOULD NOT be done as such modifications
identities that are separate at the client. may cause the server to merge identities that are separate at the
client.
In the case where there is no translation available to the client or In the case where there is no translation available to the client or
server, the attribute value will be constructed without the "@". server, the attribute value will be constructed without the "@".
Therefore, the absence of the "@" from the owner or owner_group Therefore, the absence of the "@" from the owner or owner_group
attribute signifies that no translation was available at the sender attribute signifies that no translation was available at the sender
and that the receiver of the attribute should not use that string as and that the receiver of the attribute should not use that string as
a basis for translation into its own internal format. Even though a basis for translation into its own internal format. Even though
the attribute value cannot be translated, it may still be useful. In the attribute value cannot be translated, it may still be useful. In
the case of a client, the attribute string may be used for local the case of a client, the attribute string may be used for local
display of ownership. display of ownership.
skipping to change at page 52, line 21 skipping to change at page 51, line 5
the special form, then the server SHOULD return an NFS4ERR_BADOWNER the special form, then the server SHOULD return an NFS4ERR_BADOWNER
error when there is a valid translation for the user or owner error when there is a valid translation for the user or owner
designated in this way. In that case, the client must use the designated in this way. In that case, the client must use the
appropriate user@domain string and not the special form for appropriate user@domain string and not the special form for
compatibility. compatibility.
The client MUST always accept numeric values if the security The client MUST always accept numeric values if the security
mechanism is not RPCSEC_GSS. A client can determine if a server mechanism is not RPCSEC_GSS. A client can determine if a server
supports numeric identifiers by first attempting to provide a numeric supports numeric identifiers by first attempting to provide a numeric
identifier. If this attempt rejected with an NFS4ERR_BADOWNER error, identifier. If this attempt rejected with an NFS4ERR_BADOWNER error,
the the client should only use named identifiers of the form "user@ then the client should only use named identifiers of the form
dns_domain". "user@dns_domain".
The owner string "nobody" may be used to designate an anonymous user, The owner string "nobody" may be used to designate an anonymous user,
which will be associated with a file created by a security principal which will be associated with a file created by a security principal
that cannot be mapped through normal means to the owner attribute. that cannot be mapped through normal means to the owner attribute.
5.10. Character Case Attributes 5.10. Character Case Attributes
With respect to the case_insensitive and case_preserving attributes, With respect to the case_insensitive and case_preserving attributes,
case insensitive comparisons of Unicode characters SHOULD use Unicode case insensitive comparisons of Unicode characters SHOULD use Unicode
Default Case Folding as defined in Chapter 3 of the Unicode Standard Default Case Folding as defined in Chapter 3 of the Unicode Standard
skipping to change at page 52, line 50 skipping to change at page 51, line 34
CAPITAL LETTER I ("I", U+0049) is default case folded to LATIN SMALL CAPITAL LETTER I ("I", U+0049) is default case folded to LATIN SMALL
LETTER I ("i", U+0069); however, Turkish and several other languages) LETTER I ("i", U+0069); however, Turkish and several other languages)
treat an "I" character with a dot as a different letter than an "I" treat an "I" character with a dot as a different letter than an "I"
character without a dot, therefore in such languages, unless an I is character without a dot, therefore in such languages, unless an I is
before a dot_above, the "I" (U+0049) character should be case folded before a dot_above, the "I" (U+0049) character should be case folded
to a different character, LATIN SMALL LETTER DOTLESS I (U+0131). to a different character, LATIN SMALL LETTER DOTLESS I (U+0131).
The [UNICODE] and [SPECIALCASING] references in this RFC are for The [UNICODE] and [SPECIALCASING] references in this RFC are for
version 6.3.0 of the Unicode standard, as that was the latest version version 6.3.0 of the Unicode standard, as that was the latest version
of Unicode when this RFC was published. Implementations SHOULD of Unicode when this RFC was published. Implementations SHOULD
always use the latest version of Unicode always use the latest version of Unicode (http://www.unicode.org/
(http://www.unicode.org/versions/latest/). versions/latest/).
6. Access Control Attributes 6. Access Control Attributes
Access Control Lists (ACLs) are file attributes that specify fine Access Control Lists (ACLs) are file attributes that specify fine
grained access control. This chapter covers the "acl", "aclsupport", grained access control. This chapter covers the "acl", "aclsupport",
"mode", file attributes, and their interactions. Note that file "mode", file attributes, and their interactions. Note that file
attributes may apply to any file system object. attributes may apply to any file system object.
6.1. Goals 6.1. Goals
skipping to change at page 68, line 5 skipping to change at page 66, line 25
which. which.
There are several special identifiers which need to be understood There are several special identifiers which need to be understood
universally, rather than in the context of a particular DNS domain. universally, rather than in the context of a particular DNS domain.
Some of these identifiers cannot be understood when an NFS client Some of these identifiers cannot be understood when an NFS client
accesses the server, but have meaning when a local process accesses accesses the server, but have meaning when a local process accesses
the file. The ability to display and modify these permissions is the file. The ability to display and modify these permissions is
permitted over NFS, even if none of the access methods on the server permitted over NFS, even if none of the access methods on the server
understands the identifiers. understands the identifiers.
+---------------+--------------------------------------------------+ +---------------+---------------------------------------------------+
| Who | Description | | Who | Description |
+---------------+--------------------------------------------------+ +---------------+---------------------------------------------------+
| OWNER | The owner of the file | | OWNER | The owner of the file. |
| GROUP | The group associated with the file. | | GROUP | The group associated with the file. |
| EVERYONE | The world, including the owner and owning group. | | EVERYONE | The world, including the owner and owning group. |
| INTERACTIVE | Accessed from an interactive terminal. | | INTERACTIVE | Accessed from an interactive terminal. |
| NETWORK | Accessed via the network. | | NETWORK | Accessed via the network. |
| DIALUP | Accessed as a dialup user to the server. | | DIALUP | Accessed as a dialup user to the server. |
| BATCH | Accessed from a batch job. | | BATCH | Accessed from a batch job. |
| ANONYMOUS | Accessed without any authentication. | | ANONYMOUS | Accessed without any authentication. |
| AUTHENTICATED | Any authenticated user (opposite of ANONYMOUS) | | AUTHENTICATED | Any authenticated user (opposite of ANONYMOUS). |
| SERVICE | Access from a system service. | | SERVICE | Access from a system service. |
+---------------+--------------------------------------------------+ +---------------+---------------------------------------------------+
Table 4 Table 4
To avoid conflict, these special identifiers are distinguished by an To avoid conflict, these special identifiers are distinguished by an
appended "@" and should appear in the form "xxxx@" (with no domain appended "@" and should appear in the form "xxxx@" (with no domain
name after the "@"). For example: ANONYMOUS@. name after the "@"). For example: ANONYMOUS@.
The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these The ACE4_IDENTIFIER_GROUP flag MUST be ignored on entries with these
special identifiers. When encoding entries with these special special identifiers. When encoding entries with these special
identifiers, the ACE4_IDENTIFIER_GROUP flag SHOULD be set to zero. identifiers, the ACE4_IDENTIFIER_GROUP flag SHOULD be set to zero.
skipping to change at page 77, line 38 skipping to change at page 76, line 25
like: like:
/ (place holder/not exported) / (place holder/not exported)
/a/b (file system 1) /a/b (file system 1)
/a/b/c/d (file system 2) /a/b/c/d (file system 2)
It is the server's responsibility to present the pseudo file system It is the server's responsibility to present the pseudo file system
that is complete to the client. If the client sends a lookup request that is complete to the client. If the client sends a lookup request
for the path "/a/b/c/d", the server's response is the filehandle of for the path "/a/b/c/d", the server's response is the filehandle of
the file system "/a/b/c/d". In previous versions of the NFS the file system "/a/b/c/d". In previous versions of the NFS
protocol, the server would respond with the filehandle of directory protocol, the server would respond with the filehandle of directory "
"/a/b/c/d" within the file system "/a/b". /a/b/c/d" within the file system "/a/b".
The NFS client will be able to determine if it crosses a server mount The NFS client will be able to determine if it crosses a server mount
point by a change in the value of the "fsid" attribute. point by a change in the value of the "fsid" attribute.
7.8. Security Policy and Name Space Presentation 7.8. Security Policy and Name Space Presentation
The application of the server's security policy needs to be carefully The application of the server's security policy needs to be carefully
considered by the implementor. One may choose to limit the considered by the implementer. One may choose to limit the
viewability of portions of the pseudo file system based on the viewability of portions of the pseudo file system based on the
server's perception of the client's ability to authenticate itself server's perception of the client's ability to authenticate itself
properly. However, with the support of multiple security mechanisms properly. However, with the support of multiple security mechanisms
and the ability to negotiate the appropriate use of these mechanisms, and the ability to negotiate the appropriate use of these mechanisms,
the server is unable to properly determine if a client will be able the server is unable to properly determine if a client will be able
to authenticate itself. If, based on its policies, the server to authenticate itself. If, based on its policies, the server
chooses to limit the contents of the pseudo file system, the server chooses to limit the contents of the pseudo file system, the server
may effectively hide file systems from a client that may otherwise may effectively hide file systems from a client that may otherwise
have legitimate access. have legitimate access.
skipping to change at page 83, line 40 skipping to change at page 82, line 25
given the opportunity to have continued access to their data, at an given the opportunity to have continued access to their data, at an
alternative location, as specified by the fs_locations attribute. alternative location, as specified by the fs_locations attribute.
Typically, a client will be accessing the file system in question, Typically, a client will be accessing the file system in question,
get an NFS4ERR_MOVED error, and then use the fs_locations attribute get an NFS4ERR_MOVED error, and then use the fs_locations attribute
to determine the new location of the data. to determine the new location of the data.
Such migration can be helpful in providing load balancing or general Such migration can be helpful in providing load balancing or general
resource reallocation. The protocol does not specify how the file resource reallocation. The protocol does not specify how the file
system will be moved between servers. It is anticipated that a system will be moved between servers. It is anticipated that a
number of different server-to-server transfer mechanisms might be number of different server-to-server transfer mechanisms might be
used with the choice left to the server implementor. The NFSv4 used with the choice left to the server implementer. The NFSv4
protocol specifies the method used to communicate the migration event protocol specifies the method used to communicate the migration event
between client and server. between client and server.
The new location may be an alternative communication path to the same The new location may be an alternative communication path to the same
server or, in the case of various forms of server clustering, another server or, in the case of various forms of server clustering, another
server providing access to the same physical file system. The server providing access to the same physical file system. The
client's responsibilities in dealing with this transition depend on client's responsibilities in dealing with this transition depend on
the specific nature of the new access path as well as how and whether the specific nature of the new access path as well as how and whether
data was in fact migrated. These issues will be discussed in detail data was in fact migrated. These issues will be discussed in detail
below. below.
skipping to change at page 87, line 44 skipping to change at page 86, line 36
o LOOKUP "this" --> NFS_OK. The current fh is for /this and is o LOOKUP "this" --> NFS_OK. The current fh is for /this and is
within the pseudo-fs. within the pseudo-fs.
o LOOKUP "is" --> NFS_OK. The current fh is for /this/is and is o LOOKUP "is" --> NFS_OK. The current fh is for /this/is and is
within the pseudo-fs. within the pseudo-fs.
o LOOKUP "the" --> NFS_OK. The current fh is for /this/is/the and o LOOKUP "the" --> NFS_OK. The current fh is for /this/is/the and
is within the pseudo-fs. is within the pseudo-fs.
o LOOKUP "path" --> NFS_OK. The current fh is for /this/is/the/path o LOOKUP "path" --> NFS_OK. The current fh is for /this/is/the/path
and is within a new, absent file system, but ... the client will and is within a new, absent file system, but ... the client will
never see the value of that fh. never see the value of that fh.
o GETFH --> NFS4ERR_MOVED. Fails because current fh is in an absent o GETFH --> NFS4ERR_MOVED. Fails because current fh is in an absent
file system at the start of the operation, and the specification file system at the start of the operation, and the specification
makes no exception for GETFH. makes no exception for GETFH.
o GETATTR(fsid,fileid,size,time_modify) Not executed because the o GETATTR(fsid,fileid,size,time_modify) Not executed because the
failure of the GETFH stops processing of the COMPOUND. failure of the GETFH stops processing of the COMPOUND.
Given the failure of the GETFH, the client has the job of determining Given the failure of the GETFH, the client has the job of determining
the root of the absent file system and where to find that file the root of the absent file system and where to find that file
system, i.e., the server and path relative to that server's root fh. system, i.e., the server and path relative to that server's root fh.
Note here that in this example, the client did not obtain filehandles Note here that in this example, the client did not obtain filehandles
and attribute information (e.g., fsid) for the intermediate and attribute information (e.g., fsid) for the intermediate
directories, so that it would not be sure where the absent file directories, so that it would not be sure where the absent file
system starts. It could be the case, for example, that /this/is/the system starts. It could be the case, for example, that /this/is/the
is the root of the moved file system and that the reason that the is the root of the moved file system and that the reason that the
look up of "path" succeeded is that the file system was not absent on look up of "path" succeeded is that the file system was not absent on
that operation but was moved between the last LOOKUP and the GETFH that operation but was moved between the last LOOKUP and the GETFH
(since COMPOUND is not atomic). Even if we had the fsids for all of (since COMPOUND is not atomic). Even if we had the fsids for all of
the intermediate directories, we could have no way of knowing that the intermediate directories, we could have no way of knowing that /
/this/is/the/path was the root of a new file system, since we don't this/is/the/path was the root of a new file system, since we don't
yet have its fsid. yet have its fsid.
In order to get the necessary information, let us re-send the chain In order to get the necessary information, let us re-send the chain
of LOOKUPs with GETFHs and GETATTRs to at least get the fsids so we of LOOKUPs with GETFHs and GETATTRs to at least get the fsids so we
can be sure where the appropriate file system boundaries are. The can be sure where the appropriate file system boundaries are. The
client could choose to get fs_locations at the same time but in most client could choose to get fs_locations at the same time but in most
cases the client will have a good guess as to where file system cases the client will have a good guess as to where file system
boundaries are (because of where NFS4ERR_MOVED was, and was not, boundaries are (because of where NFS4ERR_MOVED was, and was not,
received) making fetching of fs_locations unnecessary. received) making fetching of fs_locations unnecessary.
skipping to change at page 94, line 41 skipping to change at page 93, line 24
information, the client is able to substitute /x/y/z for the /a/b/c information, the client is able to substitute /x/y/z for the /a/b/c
at the beginning of its access path and construct /x/y/z/d to use for at the beginning of its access path and construct /x/y/z/d to use for
the new server. the new server.
Note that: there is no requirement that the number of components in Note that: there is no requirement that the number of components in
each rootpath be the same; there is no relation between the number of each rootpath be the same; there is no relation between the number of
components in rootpath or fs_root, and none of the components in each components in rootpath or fs_root, and none of the components in each
rootpath and fs_root have to be the same. In the above example, we rootpath and fs_root have to be the same. In the above example, we
could have had a third element in the locations array, with server could have had a third element in the locations array, with server
equal to "servC", and rootpath equal to "/I/II", and a fourth element equal to "servC", and rootpath equal to "/I/II", and a fourth element
in locations with server equal to "servD" and rootpath equal to in locations with server equal to "servD" and rootpath equal to "/
"/aleph/beth/gimel/daleth/he". aleph/beth/gimel/daleth/he".
The relationship between fs_root to a rootpath is that the client The relationship between fs_root to a rootpath is that the client
replaces the pathname indicated in fs_root for the current server for replaces the pathname indicated in fs_root for the current server for
the substitute indicated in rootpath for the new server. the substitute indicated in rootpath for the new server.
For an example of a referred or migrated file system, suppose there For an example of a referred or migrated file system, suppose there
is a file system located at serv1. At serv1, the file system is is a file system located at serv1. At serv1, the file system is
located at /az/buky/vedi/glagoli. The client finds that object at located at /az/buky/vedi/glagoli. The client finds that object at
glagoli has migrated (or is a referral). The client gets the glagoli has migrated (or is a referral). The client gets the
fs_locations attribute, which contains an fs_root of /az/buky/vedi/ fs_locations attribute, which contains an fs_root of /az/buky/vedi/
skipping to change at page 98, line 44 skipping to change at page 97, line 30
string: string:
o The string should be unique so that multiple clients do not o The string should be unique so that multiple clients do not
present the same string. The consequences of two clients present the same string. The consequences of two clients
presenting the same string range from one client getting an error presenting the same string range from one client getting an error
to one client having its leased state abruptly and unexpectedly to one client having its leased state abruptly and unexpectedly
canceled. canceled.
o The string should be selected so the subsequent incarnations o The string should be selected so the subsequent incarnations
(e.g., reboots) of the same client cause the client to present the (e.g., reboots) of the same client cause the client to present the
same string. The implementor is cautioned against an approach same string. The implementer is cautioned against an approach
that requires the string to be recorded in a local file because that requires the string to be recorded in a local file because
this precludes the use of the implementation in an environment this precludes the use of the implementation in an environment
where there is no local disk and all file access is from an NFSv4 where there is no local disk and all file access is from an NFSv4
server. server.
o The string should be different for each server network address o The string should be different for each server network address
that the client accesses, rather than common to all server network that the client accesses, rather than common to all server network
addresses. The reason is that it may not be possible for the addresses. The reason is that it may not be possible for the
client to tell if the same server is listening on multiple network client to tell if the same server is listening on multiple network
addresses. If the client issues SETCLIENTID with the same id addresses. If the client issues SETCLIENTID with the same id
skipping to change at page 113, line 19 skipping to change at page 112, line 17
In the case that an OPEN is retransmitted and the open-owner is being In the case that an OPEN is retransmitted and the open-owner is being
used for the first time or the open-owner state has been previously used for the first time or the open-owner state has been previously
released by the server, the use of the OPEN_CONFIRM operation will released by the server, the use of the OPEN_CONFIRM operation will
prevent incorrect behavior. When the server observes the use of the prevent incorrect behavior. When the server observes the use of the
open-owner for the first time, it will direct the client to perform open-owner for the first time, it will direct the client to perform
the OPEN_CONFIRM for the corresponding OPEN. This sequence the OPEN_CONFIRM for the corresponding OPEN. This sequence
establishes the use of a open-owner and associated sequence number. establishes the use of a open-owner and associated sequence number.
Since the OPEN_CONFIRM sequence connects a new open-owner on the Since the OPEN_CONFIRM sequence connects a new open-owner on the
server with an existing open-owner on a client, the sequence number server with an existing open-owner on a client, the sequence number
may have any value. The OPEN_CONFIRM step assures the server that may have any value. The OPEN_CONFIRM step assures the server that
the value received is the correct one. (see Section 15.20 for further the value received is the correct one. (see Section 15.20 for
details.) further details.)
There are a number of situations in which the requirement to confirm There are a number of situations in which the requirement to confirm
an OPEN would pose difficulties for the client and server, in that an OPEN would pose difficulties for the client and server, in that
they would be prevented from acting in a timely fashion on they would be prevented from acting in a timely fashion on
information received, because that information would be provisional, information received, because that information would be provisional,
subject to deletion upon non-confirmation. Fortunately, these are subject to deletion upon non-confirmation. Fortunately, these are
situations in which the server can avoid the need for confirmation situations in which the server can avoid the need for confirmation
when responding to open requests. The two constraints are: when responding to open requests. The two constraints are:
o The server must not bestow a delegation for any open which would o The server must not bestow a delegation for any open which would
skipping to change at page 118, line 43 skipping to change at page 117, line 44
could determine if a regular lock or READ or WRITE operation can be could determine if a regular lock or READ or WRITE operation can be
safely processed. safely processed.
For example, if a count of locks on a given file is available in For example, if a count of locks on a given file is available in
stable storage, the server can track reclaimed locks for the file and stable storage, the server can track reclaimed locks for the file and
when all reclaims have been processed, non-reclaim locking requests when all reclaims have been processed, non-reclaim locking requests
may be processed. This way the server can ensure that non-reclaim may be processed. This way the server can ensure that non-reclaim
locking requests will not conflict with potential reclaim requests. locking requests will not conflict with potential reclaim requests.
With respect to I/O requests, if the server is able to determine that With respect to I/O requests, if the server is able to determine that
there are no outstanding reclaim requests for a file by information there are no outstanding reclaim requests for a file by information
from stable storage or another similar mechanism, the processing of from stable storage or another similar mechanism, the processing of I
I/O requests could proceed normally for the file. /O requests could proceed normally for the file.
To reiterate, for a server that allows non-reclaim lock and I/O To reiterate, for a server that allows non-reclaim lock and I/O
requests to be processed during the grace period, it MUST determine requests to be processed during the grace period, it MUST determine
that no lock subsequently reclaimed will be rejected and that no lock that no lock subsequently reclaimed will be rejected and that no lock
subsequently reclaimed would have prevented any I/O operation subsequently reclaimed would have prevented any I/O operation
processed during the grace period. processed during the grace period.
Clients should be prepared for the return of NFS4ERR_GRACE errors for Clients should be prepared for the return of NFS4ERR_GRACE errors for
non-reclaim lock and I/O requests. In this case the client should non-reclaim lock and I/O requests. In this case the client should
employ a retry mechanism for the request. A delay (on the order of employ a retry mechanism for the request. A delay (on the order of
skipping to change at page 125, line 10 skipping to change at page 124, line 10
1. Reject all reclaims with NFS4ERR_NO_GRACE. This is super harsh, 1. Reject all reclaims with NFS4ERR_NO_GRACE. This is super harsh,
but necessary if the server does not want to record lock state in but necessary if the server does not want to record lock state in
stable storage. stable storage.
2. Record sufficient state in stable storage to meet its 2. Record sufficient state in stable storage to meet its
responsibilities. In doubt, the server should err on the side of responsibilities. In doubt, the server should err on the side of
being harsh. being harsh.
In the event that, after a server reboot, the server determines In the event that, after a server reboot, the server determines
that there is unrecoverable damage or corruption to the the that there is unrecoverable damage or corruption to the stable
stable storage, then for all clients and/or locks affected, the storage, then for all clients and/or locks affected, the server
server MUST return NFS4ERR_NO_GRACE. MUST return NFS4ERR_NO_GRACE.
9.6.3.4.4. Client Edge Condition 9.6.3.4.4. Client Edge Condition
A third edge condition effects the client and not the server. If the A third edge condition effects the client and not the server. If the
server reboots in the middle of the client reclaiming some locks and server reboots in the middle of the client reclaiming some locks and
then a network partition is established, the client might be in the then a network partition is established, the client might be in the
situation of having reclaimed some, but not all locks. In that case, situation of having reclaimed some, but not all locks. In that case,
a conservative client would assume that the non-reclaimed locks were a conservative client would assume that the non-reclaimed locks were
revoked. revoked.
skipping to change at page 126, line 42 skipping to change at page 125, line 42
NFS4ERR_RECLAIM_BAD errors is outside the scope of this NFS4ERR_RECLAIM_BAD errors is outside the scope of this
specification, since the strategies for such handling are very specification, since the strategies for such handling are very
dependent on the client's operating environment. However, one dependent on the client's operating environment. However, one
potential approach is described below. potential approach is described below.
When the client's reclaim fails, it could examine the change When the client's reclaim fails, it could examine the change
attribute of the objects the client is trying to reclaim state for, attribute of the objects the client is trying to reclaim state for,
and use that to determine whether to re-establish the state via and use that to determine whether to re-establish the state via
normal OPEN or LOCK requests. This is acceptable provided the normal OPEN or LOCK requests. This is acceptable provided the
client's operating environment allows it. In other words, the client client's operating environment allows it. In other words, the client
implementor is advised to document for his users the behavior. The implementer is advised to document for his users the behavior. The
client could also inform the application that its byte-range lock or client could also inform the application that its byte-range lock or
share reservations (whether they were delegated or not) have been share reservations (whether they were delegated or not) have been
lost, such as via a UNIX signal, a GUI pop-up window, etc. See lost, such as via a UNIX signal, a GUI pop-up window, etc. See
Section 10.5, for a discussion of what the client should do for Section 10.5, for a discussion of what the client should do for
dealing with unreclaimed delegations on client state. dealing with unreclaimed delegations on client state.
For further discussion of revocation of locks see Section 9.8. For further discussion of revocation of locks see Section 9.8.
9.7. Recovery from a Lock Request Timeout or Abort 9.7. Recovery from a Lock Request Timeout or Abort
skipping to change at page 138, line 38 skipping to change at page 137, line 38
not know what opens are in effect on the client. Without this not know what opens are in effect on the client. Without this
knowledge the server will be unable to determine if the access and knowledge the server will be unable to determine if the access and
deny state for the file allows any particular open until the deny state for the file allows any particular open until the
delegation for the file has been returned. delegation for the file has been returned.
A client failure or a network partition can result in failure to A client failure or a network partition can result in failure to
respond to a recall callback. In this case, the server will revoke respond to a recall callback. In this case, the server will revoke
the delegation which in turn will render useless any modified state the delegation which in turn will render useless any modified state
still on the client. still on the client.
Clients need to be aware that server implementors may enforce Clients need to be aware that server implementers may enforce
practical limitations on the number of delegations issued. Further, practical limitations on the number of delegations issued. Further,
as there is no way to determine which delegations to revoke, the as there is no way to determine which delegations to revoke, the
server is allowed to revoke any. If the server is implemented to server is allowed to revoke any. If the server is implemented to
revoke another delegation held by that client, then the client may be revoke another delegation held by that client, then the client may be
able to determine that a limit has been reached because each new able to determine that a limit has been reached because each new
delegation request results in a revoke. The client could then delegation request results in a revoke. The client could then
determine which delegations it may not need and preemptively release determine which delegations it may not need and preemptively release
them. them.
10.2.1. Delegation Recovery 10.2.1. Delegation Recovery
skipping to change at page 144, line 12 skipping to change at page 143, line 9
well as the cached attributes) as invalid. This is to ensure that well as the cached attributes) as invalid. This is to ensure that
the data for the OPENed file is still correctly reflected in the the data for the OPENed file is still correctly reflected in the
client's cache. This validation must be done at least when the client's cache. This validation must be done at least when the
client's OPEN operation includes DENY=WRITE or BOTH thus client's OPEN operation includes DENY=WRITE or BOTH thus
terminating a period in which other clients may have had the terminating a period in which other clients may have had the
opportunity to open the file with WRITE access. Clients may opportunity to open the file with WRITE access. Clients may
choose to do the revalidation more often (i.e., at OPENs choose to do the revalidation more often (i.e., at OPENs
specifying DENY=NONE) to parallel the NFSv3 protocol's practice specifying DENY=NONE) to parallel the NFSv3 protocol's practice
for the benefit of users assuming this degree of cache for the benefit of users assuming this degree of cache
revalidation. Since the change attribute is updated for data and revalidation. Since the change attribute is updated for data and
metadata modifications, some client implementors may be tempted to metadata modifications, some client implementers may be tempted to
use the time_modify attribute and not the change attribute to use the time_modify attribute and not the change attribute to
validate cached data, so that metadata changes do not spuriously validate cached data, so that metadata changes do not spuriously
invalidate clean data. The implementor is cautioned in this invalidate clean data. The implementer is cautioned in this
approach. The change attribute is guaranteed to change for each approach. The change attribute is guaranteed to change for each
update to the file, whereas time_modify is guaranteed to change update to the file, whereas time_modify is guaranteed to change
only at the granularity of the time_delta attribute. Use by the only at the granularity of the time_delta attribute. Use by the
client's data cache validation logic of time_modify and not the client's data cache validation logic of time_modify and not the
change attribute runs the risk of the client incorrectly marking change attribute runs the risk of the client incorrectly marking
stale data as valid. stale data as valid.
o Second, modified data must be flushed to the server before closing o Second, modified data must be flushed to the server before closing
a file OPENed for write. This is complementary to the first rule. a file OPENed for write. This is complementary to the first rule.
If the data is not flushed at CLOSE, the revalidation done after If the data is not flushed at CLOSE, the revalidation done after
skipping to change at page 155, line 4 skipping to change at page 153, line 49
to avoid its use. to avoid its use.
10.4.4. Recall of Open Delegation 10.4.4. Recall of Open Delegation
The following events necessitate recall of an open delegation: The following events necessitate recall of an open delegation:
o Potentially conflicting OPEN request (or READ/WRITE done with o Potentially conflicting OPEN request (or READ/WRITE done with
"special" stateid) "special" stateid)
o SETATTR issued by another client o SETATTR issued by another client
o REMOVE request for the file
o REMOVE request for the file
o RENAME request for the file as either source or target of the o RENAME request for the file as either source or target of the
RENAME RENAME
Whether a RENAME of a directory in the path leading to the file Whether a RENAME of a directory in the path leading to the file
results in recall of an open delegation depends on the semantics of results in recall of an open delegation depends on the semantics of
the server file system. If that file system denies such RENAMEs when the server file system. If that file system denies such RENAMEs when
a file is open, the recall must be performed to determine whether the a file is open, the recall must be performed to determine whether the
file in question is, in fact, open. file in question is, in fact, open.
In addition to the situations above, the server may choose to recall In addition to the situations above, the server may choose to recall
skipping to change at page 162, line 23 skipping to change at page 161, line 23
application's address space). application's address space).
As long as each memory mapped access to the file requires a page As long as each memory mapped access to the file requires a page
fault, the relevant attributes of the file that are used to detect fault, the relevant attributes of the file that are used to detect
access and modification (time_access, time_metadata, time_modify, and access and modification (time_access, time_metadata, time_modify, and
change) will be updated. However, in many operating environments, change) will be updated. However, in many operating environments,
when page faults are not required these attributes will not be when page faults are not required these attributes will not be
updated on reads or updates to the file via memory access (regardless updated on reads or updates to the file via memory access (regardless
of whether the file is a local file or is being access remotely). A of whether the file is a local file or is being access remotely). A
client or server MAY fail to update attributes of a file that is client or server MAY fail to update attributes of a file that is
being accessed via memory mapped I/O. This has several implications: being accessed via memory mapped I/O. This has several implications:
o If there is an application on the server that has memory mapped a o If there is an application on the server that has memory mapped a
file that a client is also accessing, the client may not be able file that a client is also accessing, the client may not be able
to get a consistent value of the change attribute to determine to get a consistent value of the change attribute to determine
whether its cache is stale or not. A server that knows that the whether its cache is stale or not. A server that knows that the
file is memory mapped could always pessimistically return updated file is memory mapped could always pessimistically return updated
values for change so as to force the application to always get the values for change so as to force the application to always get the
most up to date data and metadata for the file. However, due to most up to date data and metadata for the file. However, due to
the negative performance implications of this, such behavior is the negative performance implications of this, such behavior is
OPTIONAL. OPTIONAL.
skipping to change at page 164, line 12 skipping to change at page 163, line 12
Given the above issues the following are permitted: Given the above issues the following are permitted:
o Clients and servers MAY deny memory mapping a file they know there o Clients and servers MAY deny memory mapping a file they know there
are byte-range locks for. are byte-range locks for.
o Clients and servers MAY deny a byte-range lock on a file they know o Clients and servers MAY deny a byte-range lock on a file they know
is memory mapped. is memory mapped.
o A client MAY deny memory mapping a file that it knows requires o A client MAY deny memory mapping a file that it knows requires
mandatory locking for I/O. If mandatory locking is enabled after mandatory locking for I/O. If mandatory locking is enabled after
the file is opened and mapped, the client MAY deny the application the file is opened and mapped, the client MAY deny the application
further access to its mapped file. further access to its mapped file.
10.8. Name Caching 10.8. Name Caching
The results of LOOKUP and READDIR operations may be cached to avoid The results of LOOKUP and READDIR operations may be cached to avoid
the cost of subsequent LOOKUP operations. Just as in the case of the cost of subsequent LOOKUP operations. Just as in the case of
attribute caching, inconsistencies may arise among the various client attribute caching, inconsistencies may arise among the various client
caches. To mitigate the effects of these inconsistencies and given caches. To mitigate the effects of these inconsistencies and given
the context of typical file system APIs, an upper time boundary is the context of typical file system APIs, an upper time boundary is
skipping to change at page 168, line 39 skipping to change at page 167, line 39
13. A client MUST NOT attempt to use a stateid, filehandle, or 13. A client MUST NOT attempt to use a stateid, filehandle, or
similar returned object from the COMPOUND procedure with minor similar returned object from the COMPOUND procedure with minor
version X for another COMPOUND procedure with minor version Y, version X for another COMPOUND procedure with minor version Y,
where X != Y. where X != Y.
12. Internationalization 12. Internationalization
12.1. Introduction 12.1. Introduction
This section uses NFSv4.0 internationalization, as implemented by Internationalization is a complex topic with its own set of
existing clients and servers, as the basis upon which NFSv4.0 clients terminology (see [RFC6365]). The topic is made more complex in
may implement internationalization support. This procedure, while NFSv4.0 by the tangled history and state of NFS implementations.
necessary, may result in confusion if we do not clearly understand This section describes what we might call "NFSv4.0
that we are mixing prescription and description, and why, in this internationalization" (i.e., internationalization as implemented by
particular case, this is a valid thing to do. existing clients and servers) as the basis upon which NFSv4.0 clients
may implement internationalization support.
This section is based on the behavior of existing implementations. This section is based on the behavior of existing implementations.
Note that the behaviors described are each demonstrated by a Note that the behaviors described are each demonstrated by a
combination of an NFSv4 server implementation proper and a server- combination of an NFSv4 server implementation proper and a server-
side physical filesystem. It is common for servers and physical side physical filesystem. It is common for servers and physical
filesystems to be configurable as to the behavior shown once set up filesystems to be configurable as to the behavior shown. In the
and each be configuration showing different behavior is considered discussion below, each configuration that shows different behavior is
separately, for our purposes. considered separately.
Note that in this section, the keywords "MUST", "SHOULD", and "MAY", Note that in this section, the keywords "MUST", "SHOULD", and "MAY",
retain their normal meanings. However, in deriving this retain their normal meanings. However, in deriving this
specification from implementation patterns, we document below how the specification from implementation patterns, we document below how the
normative terms used derive from the behavior of existing normative terms used derive from the behavior of existing
implementations, in those situations in which existing implementation implementations, in those situations in which existing implementation
behavior patterns can be determined. behavior patterns can be determined.
o Behavior implemented by all existing clients or servers is o Behavior implemented by all existing clients or servers is
described using "MUST", since new implementations need to follow described using "MUST", since new implementations need to follow
skipping to change at page 171, line 44 skipping to change at page 170, line 44
is possible to configure at least one known server to have this is possible to configure at least one known server to have this
behavior. This behavior SHOULD NOT be used due to the possibility behavior. This behavior SHOULD NOT be used due to the possibility
that a filename using one character set may, by coincidence, have that a filename using one character set may, by coincidence, have
the appearance of a UTF-8 filename; the results of UTF-8 the appearance of a UTF-8 filename; the results of UTF-8
normalization or representation-independent lookups are unlikely normalization or representation-independent lookups are unlikely
to be correct in all cases with respect to the other character to be correct in all cases with respect to the other character
set. set.
12.4. String Encoding 12.4. String Encoding
Strings that potentially contain non-ASCII Characters are generally Strings that potentially contain characters outside the ASCII range
represented in NFSv4 using the UTF-8 encoding of Unicode. See [RFC20] are generally represented in NFSv4 using the UTF-8 encoding
[RFC2279] for precise encoding and decoding rules. [RFC3629] of Unicode [UNICODE]. See [RFC2279] for precise encoding
and decoding rules.
Some details of the protocol treatment depend on the type of string: Some details of the protocol treatment depend on the type of string:
o For strings which are component names, the preferred encoding for o For strings which are component names, the preferred encoding for
any non-ASCII characters is the UTF-8 representation of Unicode. any non-ASCII characters is the UTF-8 representation of Unicode.
In many cases, clients have no knowledge of the encoding being In many cases, clients have no knowledge of the encoding being
used, with the encoding done at user-level under control of a per- used, with the encoding done at user-level under control of a per-
process locale specification. As a result, it may be impossible process locale specification. As a result, it may be impossible
for the NFSv4 client to enforce use of UTF-8. Use of non-UTF-8 for the NFSv4 client to enforce use of UTF-8. Use of non-UTF-8
encodings can be problematic since it may interfere with access to encodings can be problematic since it may interfere with access to
files stored using other forms of name encoding. Also, files stored using other forms of name encoding. Also,
normalization-related processing (see Section 12.5) of a string normalization-related processing (see Section 12.5) of a string
not encoded in UTF-8 could result in inappropriate name not encoded in UTF-8 could result in inappropriate name
modification or aliasing. In cases in which one has a non-UT8- modification or aliasing. In cases in which one has a non-UT8-
name that accidentally conforms to UTF-8 rules, substitution of name that accidentally conforms to UTF-8 rules, substitution of
canonically equivalent strings can change the non-UTF-8 encoded canonically equivalent strings can change the non-UTF-8 encoded
name drastically. name drastically.
The kinds of modification and aliasing mentioned here can lead to
both false negatives and false positives depending on the strings
in question, which can result in security issues such as elevation
of privilege and denial of service (see [RFC6943] for further
discussion).
o For strings based on domain names, non-ASCII characters MUST be o For strings based on domain names, non-ASCII characters MUST be
represented using the UTF-8 encoding of Unicode, and additional represented using the UTF-8 encoding of Unicode, and additional
string format restrictions apply. See Section 12.6 for details. string format restrictions apply. See Section 12.6 for details.
o The contents of symbolic links (of type linktext4 in the XDR) MUST o The contents of symbolic links (of type linktext4 in the XDR) MUST
be treated as opaque data by NFSv4 servers. Although UTF-8 be treated as opaque data by NFSv4 servers. Although UTF-8
encoding is often used, it need not be. In this respect, the encoding is often used, it need not be. In this respect, the
contents of symbolic links are like the contents of regular files contents of symbolic links are like the contents of regular files
in that their encoding is not within the scope of this in that their encoding is not within the scope of this
specification. specification.
skipping to change at page 173, line 17 skipping to change at page 172, line 25
Server implementations MAY normalize file names to conform to a Server implementations MAY normalize file names to conform to a
particular normalization form before using the resulting string when particular normalization form before using the resulting string when
looking up or creating a file. Servers MAY also perform looking up or creating a file. Servers MAY also perform
normalization-insensitive string comparisons without modifying name normalization-insensitive string comparisons without modifying name
to match a particular normalization form. Except in cases in which to match a particular normalization form. Except in cases in which
component names are excluded from normalization-related handling component names are excluded from normalization-related handling
because they are not valid UTF-8 strings, a server MUST make the same because they are not valid UTF-8 strings, a server MUST make the same
choice (as to whether to normalize or not, the target form of choice (as to whether to normalize or not, the target form of
normalization and whether to do normalization-insensitive string normalization and whether to do normalization-insensitive string
comparisons) in the same way for all accesses to a particular comparisons) in the same way for all accesses to a particular
filesystem. Servers MUST NOT reject a file name because it does not filesystem. Servers SHOULD NOT reject a file name because it does
conform to a particular normalization form. not conform to a particular normalization form as this may deny
access to clients that use a different normalization form.
12.6. Types with Processing Defined by Other Internet Areas 12.6. Types with Processing Defined by Other Internet Areas
There are two types of strings that NFSv4 deals with that are based There are two types of strings that NFSv4 deals with that are based
on domain names. Processing of such strings is defined by other on domain names. Processing of such strings is defined by other
Internet standards, and hence the processing behavior for such Internet standards, and hence the processing behavior for such
strings should be consistent across all server operating systems and strings should be consistent across all server operating systems and
server file systems. server file systems.
These are as follows: These are as follows:
skipping to change at page 173, line 45 skipping to change at page 173, line 5
o Principal suffixes which are used to denote sets of users and o Principal suffixes which are used to denote sets of users and
groups, and are in the form of domain names. groups, and are in the form of domain names.
The general rules for handling all of these domain-related strings The general rules for handling all of these domain-related strings
are similar and independent of the role of the sender or receiver as are similar and independent of the role of the sender or receiver as
client or server although the consequences of failure to obey these client or server although the consequences of failure to obey these
rules may be different for client or server. The server can report rules may be different for client or server. The server can report
errors when it is sent invalid strings, whereas the client will errors when it is sent invalid strings, whereas the client will
simply ignore invalid string or use a default value in their place. simply ignore invalid string or use a default value in their place.
The string sent SHOULD be in the form of an U-label although it MAY The string sent SHOULD be in the form of a U-label although it MAY be
be in the form of an A-label or a UTF-8 domain name that is not a in the form of one or more A-labels or a UTF-8 domain name that is
properly formatted U-label. The receiver needs to be able to accept not a properly formatted U-label. The receiver needs to be able to
domain and server names in any of the formats allowed. The server accept domain and server names in any of the formats allowed. The
MUST reject, using the error NFS4ERR_INVAL, a string which is not server MUST reject, using the error NFS4ERR_INVAL, a string which is
valid UTF-8 or which begins with "xn--" and violates the rules for a not valid UTF-8 or which begins with "xn--" and violates the rules
valid A-label. for a valid A-label.
When a domain string is part of id@domain or group@domain, the server When a domain string is part of id@domain or group@domain, there are
SHOULD map domain strings which are A-labels (see [RFC5890]) or are two possible approaches:
UTF-8 domain names which are not U-labels, to the corresponding
U-label, using ToUnicode(domain) or ToUnicode(ToASCII(domain)). As a
result, the domain name returned within a userid on a GETATTR may not
match that sent when the userid is set using SETATTR, although when
this happens, the domain will be in the form of an U-label. When the
server does not map domain strings which are not U-labels into a
U-label, which it MAY do, it MUST NOT modify the domain, and the
domain returned on a GETATTR of the userid MUST be the same as that
used when setting the userid by the SETATTR.
The server MAY implement VERIFY and NVERIFY without translating 1. The server treats the domain string as a U-label (see [RFC5890]
internal state to a string form, so that, for example, a user This happens if the domain string is an A-label (or is a UTF-8-
principal which represents a specific numeric user id, will match a encoded string which is not a U-label) and the server converts
different principal string which represents the same numeric user id. the domain string to the corresponding U-label, using the
functions ToUnicode(domain) or ToUnicode(ToASCII(domain)). As a
result, the domain string returned within a userid on a GETATTR
may not match that sent when the userid is set using SETATTR,
although when this happens, the domain will be in the form of an
U-label.
2. The server does not attempt to treat the domain string as a
U-label; specifically, it does not map a domain string which is
not a U-label into a U-label using the ToUnicode function as
described above. As a result, the domain string returned on a
GETATTR of the userid MUST be the same as that used when setting
the userid by the SETATTR.
A server SHOULD use the first method, but MAY use the second method.
For VERIFY and NVERIFY, additional string processing requirements
apply to verification of the owner and owner_group attributes, see
Section 5.9.
12.7. UTF-8 Related Errors 12.7. UTF-8 Related Errors
Where the client sends an invalid UTF-8 string, the server MAY return Where the client sends an invalid UTF-8 string, the server MAY return
an NFS4ERR_INVAL error. This includes cases in which inappropriate an NFS4ERR_INVAL error. This includes cases in which inappropriate
prefixes are detected and where the count includes trailing bytes prefixes are detected and where the count includes trailing bytes
that do not constitute a full UCS character. that do not constitute a full UCS character.
Requirements for server handling of component names which are not Requirements for server handling of component names which are not
valid UTF-8, when a server does not return NFS4ERR_INVAL in response valid UTF-8, when a server does not return NFS4ERR_INVAL in response
to receiving them, are described in Section 12.8. to receiving them, are described in Section 12.8.
Where the client supplied string is not rejected with NFS4ERR_INVAL Where the client supplied string is not rejected with NFS4ERR_INVAL
but contains characters that are not supported by the server as a but contains characters that are not supported by the server as a
value for that string (e.g., names containing slashes, or characters value for that string (e.g., names containing slashes, or characters
that does not fit into 16 bits when converted from UTF-8 to a Unicode that do not fit into 16 bits when converted from UTF-8 to a Unicode
codepoint), the server should return an NFS4ERR_BADCHAR error. codepoint), the server should return an NFS4ERR_BADCHAR error.
Where a UTF-8 string is used as a file name, and the file system, Where a UTF-8 string is used as a file name, and the file system,
while supporting all of the characters within the name, does not while supporting all of the characters within the name, does not
allow that particular name to be used, the error should return the allow that particular name to be used, the error should return the
error NFS4ERR_BADNAME. This includes such situations as file system error NFS4ERR_BADNAME. This includes such situations as file system
prohibitions of "." and ".." as file names for certain operations, prohibitions of "." and ".." as file names for certain operations,
and similar constraints and similar constraints
12.8. Servers that accept file component names that are not valid UTF-8 12.8. Servers that accept file component names that are not valid UTF-8
strings strings
As stated previously, servers MAY accept, on all or on some subset of As stated previously, servers MAY accept, on all or on some subset of
the physical filesystems exported, component names that are not valid the physical filesystems exported, component names that are not valid
UTF-8 strings. A typical pattern is for a server to use UTF-8- UTF-8 strings. A typical pattern is for a server to use
unaware physical filesystems that treat component names as UTF-8-unaware physical filesystems that treat component names as
uninterpreted strings of bytes, rather than having any awareness of uninterpreted strings of bytes, rather than having any awareness of
the character set being used. the character set being used.
Such servers SHOULD NOT change the stored representation of component Such servers SHOULD NOT change the stored representation of component
names from those received on the wire, and SHOULD use binary names from those received on the wire, and SHOULD use an octet-by-
comparison of component name strings to determine equivalence (as octet comparison of component name strings to determine equivalence
opposed to any broader notion of string comparison). This is because (as opposed to any broader notion of string comparison). This is
the server has no knowledge of the character encoding being used. because the server has no knowledge of the character encoding being
used.
Nonetheless, when such a server uses a broader notion of string Nonetheless, when such a server uses a broader notion of string
equivalence than recommended in the preceding paragraph the following equivalence than recommended in the preceding paragraph the following
considerations apply: considerations apply:
o Outside of 7-bit ASCII, string processing that changes string o Outside of 7-bit ASCII, string processing that changes string
contents is usually specific to a character set and hence is contents is usually specific to a character set and hence is
generally unsafe when the character set is unknown. This generally unsafe when the character set is unknown. This
processing could change the filename in an unexpected fashion, processing could change the filename in an unexpected fashion,
rendering the file inaccessible to the application or client that rendering the file inaccessible to the application or client that
skipping to change at page 175, line 36 skipping to change at page 175, line 7
o Unicode normalization is particularly dangerous, as such o Unicode normalization is particularly dangerous, as such
processing assumes that the string is UTF-8. When that assumption processing assumes that the string is UTF-8. When that assumption
is false because a different character set was used to create the is false because a different character set was used to create the
filename, normalization may corrupt the filename with respect to filename, normalization may corrupt the filename with respect to
that character set, rendering the file inaccessible to the that character set, rendering the file inaccessible to the
application that created it and others expecting the original application that created it and others expecting the original
filename. Hence, Unicode normalization SHOULD NOT be performed, filename. Hence, Unicode normalization SHOULD NOT be performed,
because it may cause incorrect string modification or aliasing. because it may cause incorrect string modification or aliasing.
When the above recommendations are not followed, the resulting string
modification and aliasing can lead to both false negatives and false
positives depending on the strings in question, which can result in
security issues such as elevation of privilege and denial of service
(see [RFC6943] for further discussion).
13. Error Values 13. Error Values
NFS error numbers are assigned to failed operations within a Compound NFS error numbers are assigned to failed operations within a Compound
(COMPOUND or CB_COMPOUND) request. A Compound request contains a (COMPOUND or CB_COMPOUND) request. A Compound request contains a
number of NFS operations that have their results encoded in sequence number of NFS operations that have their results encoded in sequence
in a Compound reply. The results of successful operations will in a Compound reply. The results of successful operations will
consist of an NFS4_OK status followed by the encoded results of the consist of an NFS4_OK status followed by the encoded results of the
operation. If an NFS operation fails, an error status will be operation. If an NFS operation fails, an error status will be
entered in the reply and the Compound request will be terminated. entered in the reply and the Compound request will be terminated.
skipping to change at page 188, line 36 skipping to change at page 188, line 23
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Operation | Errors | | Operation | Errors |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| ACCESS | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, | | ACCESS | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| CLOSE | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADHANDLE, | | CLOSE | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, | | | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_ISDIR, | | | NFS4ERR_INVAL, NFS4ERR_ISDIR, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCKS_HELD, | | | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCKS_HELD, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, | | | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID | | | NFS4ERR_STALE_STATEID |
| | |
| COMMIT | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, | | COMMIT | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_MOVED, | | | NFS4ERR_IO, NFS4ERR_ISDIR, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK | | | NFS4ERR_STALE, NFS4ERR_SYMLINK |
| | |
| CREATE | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, | | CREATE | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, |
| | NFS4ERR_BADCHAR, NFS4ERR_BADHANDLE, | | | NFS4ERR_BADCHAR, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADNAME, NFS4ERR_BADOWNER, | | | NFS4ERR_BADNAME, NFS4ERR_BADOWNER, |
| | NFS4ERR_BADTYPE, NFS4ERR_BADXDR, | | | NFS4ERR_BADTYPE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_DQUOT, | | | NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXIST, NFS4ERR_FHEXPIRED, | | | NFS4ERR_EXIST, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_NAMETOOLONG, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, | | | NFS4ERR_NOSPC, NFS4ERR_NOTDIR, |
| | NFS4ERR_PERM, NFS4ERR_RESOURCE, | | | NFS4ERR_PERM, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE | | | NFS4ERR_STALE |
| | |
| DELEGPURGE | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | DELEGPURGE | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_NOTSUPP, NFS4ERR_LEASE_MOVED, | | | NFS4ERR_NOTSUPP, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, | | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE_CLIENTID | | | NFS4ERR_STALE_CLIENTID |
| | |
| DELEGRETURN | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BAD_STATEID, | | DELEGRETURN | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_INVAL, | | | NFS4ERR_EXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_MOVED, | | | NFS4ERR_LEASE_MOVED, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTSUPP, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, | | | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID | | | NFS4ERR_STALE_STATEID |
| | |
| GETATTR | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, | | GETATTR | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| GETFH | NFS4ERR_BADHANDLE, NFS4ERR_FHEXPIRED, | | GETFH | NFS4ERR_BADHANDLE, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, | | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE | | | NFS4ERR_STALE |
| | |
| ILLEGAL | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL | | ILLEGAL | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL |
| | |
| LINK | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, | | LINK | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, | | | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_DQUOT, NFS4ERR_EXIST, | | | NFS4ERR_DQUOT, NFS4ERR_EXIST, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, | | | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, | | | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, |
| | NFS4ERR_MLINK, NFS4ERR_MOVED, | | | NFS4ERR_MLINK, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, | | | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOTDIR, NFS4ERR_NOTSUPP, | | | NFS4ERR_NOTDIR, NFS4ERR_NOTSUPP, |
| | NFS4ERR_RESOURCE, NFS4ERR_ROFS, | | | NFS4ERR_RESOURCE, NFS4ERR_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_WRONGSEC, NFS4ERR_XDEV | | | NFS4ERR_WRONGSEC, NFS4ERR_XDEV |
| | |
| LOCK | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | LOCK | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BAD_RANGE, | | | NFS4ERR_BADHANDLE, NFS4ERR_BAD_RANGE, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, | | | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DEADLOCK, | | | NFS4ERR_BADXDR, NFS4ERR_DEADLOCK, |
| | NFS4ERR_DELAY, NFS4ERR_DENIED, | | | NFS4ERR_DELAY, NFS4ERR_DENIED, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, | | | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, | | | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | 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, |
| | NFS4ERR_OPENMODE, NFS4ERR_RECLAIM_BAD, | | | NFS4ERR_OPENMODE, NFS4ERR_RECLAIM_BAD, |
| | NFS4ERR_RECLAIM_CONFLICT, NFS4ERR_RESOURCE, | | | NFS4ERR_RECLAIM_CONFLICT, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_CLIENTID, | | | NFS4ERR_STALE_CLIENTID, |
| | NFS4ERR_STALE_STATEID | | | NFS4ERR_STALE_STATEID |
| | |
| LOCKT | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, | | LOCKT | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BAD_RANGE, NFS4ERR_BADXDR, | | | NFS4ERR_BAD_RANGE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_DENIED, | | | NFS4ERR_DELAY, NFS4ERR_DENIED, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, | | | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, | | | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCK_RANGE, NFS4ERR_MOVED, | | | NFS4ERR_LOCK_RANGE, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_CLIENTID | | | NFS4ERR_STALE_CLIENTID |
| | |
| LOCKU | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | LOCKU | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BAD_RANGE, | | | NFS4ERR_BADHANDLE, NFS4ERR_BAD_RANGE, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, | | | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, | | | NFS4ERR_GRACE, NFS4ERR_INVAL, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, | | | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCK_RANGE, NFS4ERR_MOVED, | | | NFS4ERR_LOCK_RANGE, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, | | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_STALE_STATEID | | | NFS4ERR_STALE, NFS4ERR_STALE_STATEID |
| | |
| LOOKUP | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, | | LOOKUP | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, | | | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, | | | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, | | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK, | | | NFS4ERR_STALE, NFS4ERR_SYMLINK, |
| | NFS4ERR_WRONGSEC | | | NFS4ERR_WRONGSEC |
| | |
| LOOKUPP | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, | | LOOKUPP | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, | | | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NOENT, | | | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, | | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_SYMLINK, | | | NFS4ERR_STALE, NFS4ERR_SYMLINK, |
| | NFS4ERR_WRONGSEC | | | NFS4ERR_WRONGSEC |
| | |
| NVERIFY | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, | | NVERIFY | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, |
| | NFS4ERR_BADCHAR, NFS4ERR_BADHANDLE, | | | NFS4ERR_BADCHAR, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_SAME, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_SAME, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| OPEN | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | OPEN | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR, | | | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, | | | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADOWNER, NFS4ERR_BADXDR, | | | NFS4ERR_BADOWNER, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, | | | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DELAY, NFS4ERR_DQUOT, | | | NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXIST, NFS4ERR_EXPIRED, | | | NFS4ERR_EXIST, NFS4ERR_EXPIRED, |
| | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, | | | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_ISDIR, NFS4ERR_MOVED, | | | NFS4ERR_ISDIR, NFS4ERR_MOVED, |
| | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, | | | NFS4ERR_NAMETOOLONG, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOTDIR, NFS4ERR_NOTSUP, | | | NFS4ERR_NOTDIR, NFS4ERR_NOTSUP, |
| | NFS4ERR_NO_GRACE, NFS4ERR_OLD_STATEID, | | | NFS4ERR_NO_GRACE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_PERM, NFS4ERR_RECLAIM_BAD, | | | NFS4ERR_PERM, NFS4ERR_RECLAIM_BAD, |
| | NFS4ERR_RECLAIM_CONFLICT, NFS4ERR_RESOURCE, | | | NFS4ERR_RECLAIM_CONFLICT, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_SHARE_DENIED, NFS4ERR_STALE, | | | NFS4ERR_SHARE_DENIED, NFS4ERR_STALE, |
| | NFS4ERR_STALE_CLIENTID, NFS4ERR_SYMLINK, | | | NFS4ERR_STALE_CLIENTID, NFS4ERR_SYMLINK, |
| | NFS4ERR_WRONGSEC | | | NFS4ERR_WRONGSEC |
| | |
| OPENATTR | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, | | OPENATTR | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_DQUOT, NFS4ERR_FHEXPIRED, | | | NFS4ERR_DQUOT, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NOENT, | | | NFS4ERR_IO, NFS4ERR_MOVED, NFS4ERR_NOENT, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NOTSUPP, NFS4ERR_RESOURCE, | | | NFS4ERR_NOTSUPP, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE | | | NFS4ERR_STALE |
| | |
| OPEN_CONFIRM | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADHANDLE, | | OPEN_CONFIRM | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, | | | NFS4ERR_BAD_SEQID, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_BADXDR, NFS4ERR_EXPIRED, | | | NFS4ERR_BADXDR, NFS4ERR_EXPIRED, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, | | | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, | | | NFS4ERR_OLD_STATEID, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID | | | NFS4ERR_STALE_STATEID |
| | |
| OPEN_DOWNGRADE | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADHANDLE, | | OPEN_DOWNGRADE | NFS4ERR_ADMIN_REVOKED, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_SEQID, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_SEQID, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, | | | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_LEASE_MOVED, | | | NFS4ERR_INVAL, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCKS_HELD, NFS4ERR_MOVED, | | | NFS4ERR_LOCKS_HELD, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_RESOURCE, NFS4ERR_ROFS, | | | NFS4ERR_RESOURCE, NFS4ERR_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID | | | NFS4ERR_STALE_STATEID |
| | |
| PUTFH | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, | | PUTFH | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, | | | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_MOVED, NFS4ERR_SERVERFAULT, | | | NFS4ERR_MOVED, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_WRONGSEC | | | NFS4ERR_STALE, NFS4ERR_WRONGSEC |
| | |
| PUTPUBFH | NFS4ERR_DELAY, NFS4ERR_SERVERFAULT, | | PUTPUBFH | NFS4ERR_DELAY, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_WRONGSEC | | | NFS4ERR_WRONGSEC |
| | |
| PUTROOTFH | NFS4ERR_DELAY, NFS4ERR_SERVERFAULT, | | PUTROOTFH | NFS4ERR_DELAY, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_WRONGSEC | | | NFS4ERR_WRONGSEC |
| | |
| READ | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | READ | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, | | | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, | | | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, |
| | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, | | | NFS4ERR_EXPIRED, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, | | | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCKED, NFS4ERR_MOVED, | | | NFS4ERR_LOCKED, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_RESOURCE, | | | NFS4ERR_OPENMODE, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID, NFS4ERR_SYMLINK | | | NFS4ERR_STALE_STATEID, NFS4ERR_SYMLINK |
| | |
| READDIR | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, | | READDIR | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_COOKIE, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_COOKIE, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, | | | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOTDIR, |
| | NFS4ERR_NOT_SAME, NFS4ERR_RESOURCE, | | | NFS4ERR_NOT_SAME, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_TOOSMALL | | | NFS4ERR_TOOSMALL |
| | |
| READLINK | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, | | READLINK | NFS4ERR_ACCESS, NFS4ERR_BADHANDLE, |
| | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, | | | NFS4ERR_DELAY, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, | | | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, |
| | NFS4ERR_MOVED, NFS4ERR_NOTSUP, | | | NFS4ERR_MOVED, NFS4ERR_NOTSUP, |
| | NFS4ERR_RESOURCE, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_RESOURCE, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| RELEASE_LOCKOWNER | NFS4ERR_BADXDR, NFS4ERR_EXPIRED, | | RELEASE_LOCKOWNER | NFS4ERR_BADXDR, NFS4ERR_EXPIRED, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCKS_HELD, | | | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCKS_HELD, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, | | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE_CLIENTID | | | NFS4ERR_STALE_CLIENTID |
| | |
| REMOVE | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, | | REMOVE | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, | | | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, | | | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, |
| | 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_NOTDIR, NFS4ERR_NOTEMPTY, | | | NFS4ERR_NOTDIR, NFS4ERR_NOTEMPTY, |
| | NFS4ERR_RESOURCE, NFS4ERR_ROFS, | | | NFS4ERR_RESOURCE, NFS4ERR_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| RENAME | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, | | RENAME | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, | | | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_DQUOT, NFS4ERR_EXIST, | | | NFS4ERR_DQUOT, NFS4ERR_EXIST, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, | | | NFS4ERR_FHEXPIRED, NFS4ERR_FILE_OPEN, |
| | 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_RESOURCE, | | | NFS4ERR_NOTEMPTY, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_WRONGSEC, | | | NFS4ERR_STALE, NFS4ERR_WRONGSEC, |
| | NFS4ERR_XDEV | | | NFS4ERR_XDEV |
| | |
| RENEW | NFS4ERR_ACCESS, NFS4ERR_BADXDR, | | RENEW | NFS4ERR_ACCESS, NFS4ERR_BADXDR, |
| | NFS4ERR_CB_PATH_DOWN, NFS4ERR_EXPIRED, | | | NFS4ERR_CB_PATH_DOWN, NFS4ERR_EXPIRED, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_RESOURCE, | | | NFS4ERR_LEASE_MOVED, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE_CLIENTID | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE_CLIENTID |
| | |
| RESTOREFH | NFS4ERR_BADHANDLE, NFS4ERR_FHEXPIRED, | | RESTOREFH | NFS4ERR_BADHANDLE, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_MOVED, NFS4ERR_RESOURCE, | | | NFS4ERR_MOVED, NFS4ERR_RESOURCE, |
| | NFS4ERR_RESTOREFH, NFS4ERR_SERVERFAULT, | | | NFS4ERR_RESTOREFH, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_WRONGSEC | | | NFS4ERR_STALE, NFS4ERR_WRONGSEC |
| | |
| SAVEFH | NFS4ERR_BADHANDLE, NFS4ERR_FHEXPIRED, | | SAVEFH | NFS4ERR_BADHANDLE, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, | | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE | | | NFS4ERR_STALE |
| | |
| SECINFO | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, | | SECINFO | NFS4ERR_ACCESS, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, | | | NFS4ERR_BADHANDLE, NFS4ERR_BADNAME, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, | | | NFS4ERR_FHEXPIRED, NFS4ERR_INVAL, |
| | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, | | | NFS4ERR_MOVED, NFS4ERR_NAMETOOLONG, |
| | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_NOENT, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOTDIR, NFS4ERR_RESOURCE, | | | NFS4ERR_NOTDIR, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE |
| | |
| SETATTR | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | SETATTR | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR, | | | NFS4ERR_ATTRNOTSUPP, NFS4ERR_BADCHAR, |
| | NFS4ERR_BADHANDLE, NFS4ERR_BADOWNER, | | | NFS4ERR_BADHANDLE, NFS4ERR_BADOWNER, |
| | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, | | | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID, |
| | NFS4ERR_DELAY, NFS4ERR_DQUOT, | | | NFS4ERR_DELAY, NFS4ERR_DQUOT, |
| | NFS4ERR_EXPIRED, NFS4ERR_FBIG, | | | NFS4ERR_EXPIRED, NFS4ERR_FBIG, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, | | | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_ISDIR, |
| | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCKED, | | | NFS4ERR_LEASE_MOVED, NFS4ERR_LOCKED, |
| | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, | | | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE, |
| | NFS4ERR_NOSPC, NFS4ERR_OLD_STATEID, | | | NFS4ERR_NOSPC, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_PERM, | | | NFS4ERR_OPENMODE, NFS4ERR_PERM, |
| | NFS4ERR_RESOURCE, NFS4ERR_ROFS, | | | NFS4ERR_RESOURCE, NFS4ERR_ROFS, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE, |
| | NFS4ERR_STALE_STATEID | | | NFS4ERR_STALE_STATEID |
| | |
| SETCLIENTID | NFS4ERR_BADXDR, NFS4ERR_CLID_INUSE, | | SETCLIENTID | NFS4ERR_BADXDR, NFS4ERR_CLID_INUSE, |
| | NFS4ERR_DELAY, NFS4ERR_INVAL, | | | NFS4ERR_DELAY, NFS4ERR_INVAL, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT | | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT |
| | |
| SETCLIENTID_CONFIRM | NFS4ERR_BADXDR, NFS4ERR_CLID_INUSE, | | SETCLIENTID_CONFIRM | NFS4ERR_BADXDR, NFS4ERR_CLID_INUSE, |
| | NFS4ERR_DELAY, NFS4ERR_RESOURCE, | | | NFS4ERR_DELAY, NFS4ERR_RESOURCE, |
| | NFS4ERR_SERVERFAULT, NFS4ERR_STALE_CLIENTID | | | NFS4ERR_SERVERFAULT, NFS4ERR_STALE_CLIENTID |
| | |
| VERIFY | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, | | VERIFY | NFS4ERR_ACCESS, NFS4ERR_ATTRNOTSUPP, |
| | NFS4ERR_BADCHAR, NFS4ERR_BADHANDLE, | | | NFS4ERR_BADCHAR, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BADXDR, NFS4ERR_DELAY, | | | NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, | | | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE, |
| | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, | | | NFS4ERR_INVAL, NFS4ERR_IO, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOT_SAME, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOT_SAME, |
| | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, | | | NFS4ERR_RESOURCE, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE | | | NFS4ERR_STALE |
| | |
| WRITE | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, | | WRITE | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED, |
| | NFS4ERR_BADXDR, NFS4ERR_BADHANDLE, | | | NFS4ERR_BADXDR, NFS4ERR_BADHANDLE, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, | | | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, |
| | NFS4ERR_DQUOT, NFS4ERR_EXPIRED, | | | NFS4ERR_DQUOT, NFS4ERR_EXPIRED, |
| | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, | | | NFS4ERR_FBIG, NFS4ERR_FHEXPIRED, |
| | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, | | | NFS4ERR_GRACE, NFS4ERR_INVAL, NFS4ERR_IO, |
| | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, | | | NFS4ERR_ISDIR, NFS4ERR_LEASE_MOVED, |
| | NFS4ERR_LOCKED, NFS4ERR_MOVED, | | | NFS4ERR_LOCKED, NFS4ERR_MOVED, |
| | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, | | | NFS4ERR_NOFILEHANDLE, NFS4ERR_NOSPC, |
| | NFS4ERR_NXIO, NFS4ERR_OLD_STATEID, | | | NFS4ERR_NXIO, NFS4ERR_OLD_STATEID, |
| | NFS4ERR_OPENMODE, NFS4ERR_RESOURCE, | | | NFS4ERR_OPENMODE, NFS4ERR_RESOURCE, |
| | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, | | | NFS4ERR_ROFS, NFS4ERR_SERVERFAULT, |
| | NFS4ERR_STALE, NFS4ERR_STALE_STATEID, | | | NFS4ERR_STALE, NFS4ERR_STALE_STATEID, |
| | NFS4ERR_SYMLINK | | | NFS4ERR_SYMLINK |
| | |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
Table 6 Table 6
13.3. Callback operations and their valid errors 13.3. Callback operations and their valid errors
This section contains a table which gives the valid error returns for This section contains a table which gives the valid error returns for
each callback operation. The error code NFS4_OK (indicating no each callback operation. The error code NFS4_OK (indicating no
error) is not listed but should be understood to be returnable by all error) is not listed but should be understood to be returnable by all
callback operations with the exception of CB_ILLEGAL. callback operations with the exception of CB_ILLEGAL.
Valid error returns for each protocol callback operation Valid error returns for each protocol callback operation
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| Callback | Errors | | Callback | Errors |
| Operation | | | Operation | |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| CB_GETATTR | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, NFS4ERR_DELAY, | | CB_GETATTR | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, NFS4ERR_DELAY, |
| | NFS4ERR_INVAL, NFS4ERR_SERVERFAULT | | | NFS4ERR_INVAL, NFS4ERR_SERVERFAULT |
| | |
| CB_ILLEGAL | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL | | CB_ILLEGAL | NFS4ERR_BADXDR, NFS4ERR_OP_ILLEGAL |
| | |
| CB_RECALL | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, | | CB_RECALL | NFS4ERR_BADHANDLE, NFS4ERR_BADXDR, |
| | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, | | | NFS4ERR_BAD_STATEID, NFS4ERR_DELAY, |
| | NFS4ERR_SERVERFAULT | | | NFS4ERR_SERVERFAULT |
| | |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
Table 7 Table 7
13.4. Errors and the operations that use them 13.4. Errors and the operations that use them
+--------------------------+----------------------------------------+ +--------------------------+----------------------------------------+
| Error | Operations | | Error | Operations |
+--------------------------+----------------------------------------+ +--------------------------+----------------------------------------+
| NFS4ERR_ACCESS | ACCESS, COMMIT, CREATE, GETATTR, LINK, | | NFS4ERR_ACCESS | ACCESS, COMMIT, CREATE, GETATTR, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, | | | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, READ, | | | NVERIFY, OPEN, OPENATTR, READ, |
| | READDIR, READLINK, REMOVE, RENAME, | | | READDIR, READLINK, REMOVE, RENAME, |
| | RENEW, SECINFO, SETATTR, VERIFY, WRITE | | | RENEW, SECINFO, SETATTR, VERIFY, WRITE |
| | |
| NFS4ERR_ADMIN_REVOKED | CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN, | | NFS4ERR_ADMIN_REVOKED | CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, | | | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, |
| | SETATTR, WRITE | | | SETATTR, WRITE |
| | |
| NFS4ERR_ATTRNOTSUPP | CREATE, NVERIFY, OPEN, SETATTR, VERIFY | | NFS4ERR_ATTRNOTSUPP | CREATE, NVERIFY, OPEN, SETATTR, VERIFY |
| | |
| NFS4ERR_BADCHAR | CREATE, LINK, LOOKUP, NVERIFY, OPEN, | | NFS4ERR_BADCHAR | CREATE, LINK, LOOKUP, NVERIFY, OPEN, |
| | REMOVE, RENAME, SECINFO, SETATTR, | | | REMOVE, RENAME, SECINFO, SETATTR, |
| | VERIFY | | | VERIFY |
| | |
| NFS4ERR_BADHANDLE | ACCESS, CB_GETATTR, CB_RECALL, CLOSE, | | NFS4ERR_BADHANDLE | ACCESS, CB_GETATTR, CB_RECALL, CLOSE, |
| | COMMIT, CREATE, GETATTR, GETFH, LINK, | | | COMMIT, CREATE, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, | | | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, | | | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, READ, READDIR, | | | OPEN_DOWNGRADE, PUTFH, READ, READDIR, |
| | READLINK, REMOVE, RENAME, RESTOREFH, | | | READLINK, REMOVE, RENAME, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, VERIFY, | | | SAVEFH, SECINFO, SETATTR, VERIFY, |
| | WRITE | | | WRITE |
| | |
| NFS4ERR_BADNAME | CREATE, LINK, LOOKUP, OPEN, REMOVE, | | NFS4ERR_BADNAME | CREATE, LINK, LOOKUP, OPEN, REMOVE, |
| | RENAME, SECINFO | | | RENAME, SECINFO |
| | |
| NFS4ERR_BADOWNER | CREATE, OPEN, SETATTR | | NFS4ERR_BADOWNER | CREATE, OPEN, SETATTR |
| | |
| NFS4ERR_BADTYPE | CREATE | | NFS4ERR_BADTYPE | CREATE |
| | |
| NFS4ERR_BADXDR | ACCESS, CB_GETATTR, CB_ILLEGAL, | | NFS4ERR_BADXDR | ACCESS, CB_GETATTR, CB_ILLEGAL, |
| | CB_RECALL, CLOSE, COMMIT, CREATE, | | | CB_RECALL, CLOSE, COMMIT, CREATE, |
| | DELEGPURGE, DELEGRETURN, GETATTR, | | | DELEGPURGE, DELEGRETURN, GETATTR, |
| | ILLEGAL, LINK, LOCK, LOCKT, LOCKU, | | | ILLEGAL, LINK, LOCK, LOCKT, LOCKU, |
| | LOOKUP, NVERIFY, OPEN, OPENATTR, | | | LOOKUP, NVERIFY, OPEN, OPENATTR, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, PUTFH, | | | OPEN_CONFIRM, OPEN_DOWNGRADE, PUTFH, |
| | READ, READDIR, RELEASE_LOCKOWNER, | | | READ, READDIR, RELEASE_LOCKOWNER, |
| | REMOVE, RENAME, RENEW, SECINFO, | | | REMOVE, RENAME, RENEW, SECINFO, |
| | SETATTR, SETCLIENTID, | | | SETATTR, SETCLIENTID, |
| | SETCLIENTID_CONFIRM, VERIFY, WRITE | | | SETCLIENTID_CONFIRM, VERIFY, WRITE |
| | |
| NFS4ERR_BAD_COOKIE | READDIR | | NFS4ERR_BAD_COOKIE | READDIR |
| | |
| NFS4ERR_BAD_RANGE | LOCK, LOCKT, LOCKU | | NFS4ERR_BAD_RANGE | LOCK, LOCKT, LOCKU |
| | |
| NFS4ERR_BAD_SEQID | CLOSE, LOCK, LOCKU, OPEN, | | NFS4ERR_BAD_SEQID | CLOSE, LOCK, LOCKU, OPEN, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE | | | OPEN_CONFIRM, OPEN_DOWNGRADE |
| | |
| NFS4ERR_BAD_STATEID | CB_RECALL, CLOSE, DELEGRETURN, LOCK, | | NFS4ERR_BAD_STATEID | CB_RECALL, CLOSE, DELEGRETURN, LOCK, |
| | LOCKU, OPEN, OPEN_CONFIRM, | | | LOCKU, OPEN, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, READ, SETATTR, WRITE | | | OPEN_DOWNGRADE, READ, SETATTR, WRITE |
| | |
| NFS4ERR_CB_PATH_DOWN | RENEW | | NFS4ERR_CB_PATH_DOWN | RENEW |
| | |
| NFS4ERR_CLID_INUSE | SETCLIENTID, SETCLIENTID_CONFIRM | | NFS4ERR_CLID_INUSE | SETCLIENTID, SETCLIENTID_CONFIRM |
| | |
| NFS4ERR_DEADLOCK | LOCK | | NFS4ERR_DEADLOCK | LOCK |
| | |
| NFS4ERR_DELAY | ACCESS, CB_GETATTR, CB_RECALL, CLOSE, | | NFS4ERR_DELAY | ACCESS, CB_GETATTR, CB_RECALL, CLOSE, |
| | COMMIT, CREATE, DELEGPURGE, | | | COMMIT, CREATE, DELEGPURGE, |
| | DELEGRETURN, GETATTR, LINK, LOCK, | | | DELEGRETURN, GETATTR, LINK, LOCK, |
| | LOCKT, LOCKU, LOOKUP, LOOKUPP, | | | LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, | | | NVERIFY, OPEN, OPENATTR, |
| | OPEN_DOWNGRADE, PUTFH, PUTPUBFH, | | | OPEN_DOWNGRADE, PUTFH, PUTPUBFH, |
| | PUTROOTFH, READ, READDIR, READLINK, | | | PUTROOTFH, READ, READDIR, READLINK, |
| | REMOVE, RENAME, SECINFO, SETATTR, | | | REMOVE, RENAME, SECINFO, SETATTR, |
| | SETCLIENTID, SETCLIENTID_CONFIRM, | | | SETCLIENTID, SETCLIENTID_CONFIRM, |
| | VERIFY, WRITE | | | VERIFY, WRITE |
| | |
| NFS4ERR_DENIED | LOCK, LOCKT | | NFS4ERR_DENIED | LOCK, LOCKT |
| | |
| NFS4ERR_DQUOT | CREATE, LINK, OPEN, OPENATTR, RENAME, | | NFS4ERR_DQUOT | CREATE, LINK, OPEN, OPENATTR, RENAME, |
| | SETATTR, WRITE | | | SETATTR, WRITE |
| | |
| NFS4ERR_EXIST | CREATE, LINK, OPEN, RENAME | | NFS4ERR_EXIST | CREATE, LINK, OPEN, RENAME |
| | |
| NFS4ERR_EXPIRED | CLOSE, DELEGRETURN, LOCK, LOCKT, | | NFS4ERR_EXPIRED | CLOSE, DELEGRETURN, LOCK, LOCKT, |
| | LOCKU, OPEN, OPEN_CONFIRM, | | | LOCKU, OPEN, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, READ, | | | OPEN_DOWNGRADE, READ, |
| | RELEASE_LOCKOWNER, RENEW, SETATTR, | | | RELEASE_LOCKOWNER, RENEW, SETATTR, |
| | WRITE | | | WRITE |
| | |
| NFS4ERR_FBIG | OPEN, SETATTR, WRITE | | NFS4ERR_FBIG | OPEN, SETATTR, WRITE |
| | |
| NFS4ERR_FHEXPIRED | ACCESS, CLOSE, COMMIT, CREATE, | | NFS4ERR_FHEXPIRED | ACCESS, CLOSE, COMMIT, CREATE, |
| | GETATTR, GETFH, LINK, LOCK, LOCKT, | | | GETATTR, GETFH, LINK, LOCK, LOCKT, |
| | LOCKU, LOOKUP, LOOKUPP, NVERIFY, OPEN, | | | LOCKU, LOOKUP, LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, OPEN_CONFIRM, | | | OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, READ, READDIR, | | | OPEN_DOWNGRADE, PUTFH, READ, READDIR, |
| | READLINK, REMOVE, RENAME, RESTOREFH, | | | READLINK, REMOVE, RENAME, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, VERIFY, | | | SAVEFH, SECINFO, SETATTR, VERIFY, |
| | WRITE | | | WRITE |
| | |
| NFS4ERR_FILE_OPEN | LINK, REMOVE, RENAME | | NFS4ERR_FILE_OPEN | LINK, REMOVE, RENAME |
| | |
| NFS4ERR_GRACE | GETATTR, LOCK, LOCKT, LOCKU, NVERIFY, | | NFS4ERR_GRACE | GETATTR, LOCK, LOCKT, LOCKU, NVERIFY, |
| | OPEN, READ, REMOVE, RENAME, SETATTR, | | | OPEN, READ, REMOVE, RENAME, SETATTR, |
| | VERIFY, WRITE | | | VERIFY, WRITE |
| | |
| NFS4ERR_INVAL | ACCESS, CB_GETATTR, CLOSE, COMMIT, | | NFS4ERR_INVAL | ACCESS, CB_GETATTR, CLOSE, COMMIT, |
| | CREATE, DELEGRETURN, GETATTR, LINK, | | | CREATE, DELEGRETURN, GETATTR, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, NVERIFY, | | | LOCK, LOCKT, LOCKU, LOOKUP, NVERIFY, |
| | OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE, | | | OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE, |
| | READ, READDIR, READLINK, REMOVE, | | | READ, READDIR, READLINK, REMOVE, |
| | RENAME, SECINFO, SETATTR, SETCLIENTID, | | | RENAME, SECINFO, SETATTR, SETCLIENTID, |
| | VERIFY, WRITE | | | VERIFY, WRITE |
| | |
| NFS4ERR_IO | ACCESS, COMMIT, CREATE, GETATTR, LINK, | | NFS4ERR_IO | ACCESS, COMMIT, CREATE, GETATTR, LINK, |
| | LOOKUP, LOOKUPP, NVERIFY, OPEN, | | | LOOKUP, LOOKUPP, NVERIFY, OPEN, |
| | OPENATTR, READ, READDIR, READLINK, | | | OPENATTR, READ, READDIR, READLINK, |
| | REMOVE, RENAME, SETATTR, VERIFY, WRITE | | | REMOVE, RENAME, SETATTR, VERIFY, WRITE |
| | |
| NFS4ERR_ISDIR | CLOSE, COMMIT, LINK, LOCK, LOCKT, | | NFS4ERR_ISDIR | CLOSE, COMMIT, LINK, LOCK, LOCKT, |
| | LOCKU, OPEN, OPEN_CONFIRM, READ, | | | LOCKU, OPEN, OPEN_CONFIRM, READ, |
| | READLINK, SETATTR, WRITE | | | READLINK, SETATTR, WRITE |
| | |
| NFS4ERR_LEASE_MOVED | CLOSE, DELEGPURGE, DELEGRETURN, LOCK, | | NFS4ERR_LEASE_MOVED | CLOSE, DELEGPURGE, DELEGRETURN, LOCK, |
| | LOCKT, LOCKU, OPEN_CONFIRM, | | | LOCKT, LOCKU, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, READ, | | | OPEN_DOWNGRADE, READ, |
| | RELEASE_LOCKOWNER, RENEW, SETATTR, | | | RELEASE_LOCKOWNER, RENEW, SETATTR, |
| | WRITE | | | WRITE |
| | |
| NFS4ERR_LOCKED | READ, SETATTR, WRITE | | NFS4ERR_LOCKED | READ, SETATTR, WRITE |
| | |
| NFS4ERR_LOCKS_HELD | CLOSE, OPEN_DOWNGRADE, | | NFS4ERR_LOCKS_HELD | CLOSE, OPEN_DOWNGRADE, |
| | RELEASE_LOCKOWNER | | | RELEASE_LOCKOWNER |
| | |
| NFS4ERR_LOCK_NOTSUPP | LOCK | | NFS4ERR_LOCK_NOTSUPP | LOCK |
| | |
| NFS4ERR_LOCK_RANGE | LOCK, LOCKT, LOCKU | | NFS4ERR_LOCK_RANGE | LOCK, LOCKT, LOCKU |
| | |
| NFS4ERR_MLINK | LINK | | NFS4ERR_MLINK | LINK |
| | |
| NFS4ERR_MOVED | ACCESS, CLOSE, COMMIT, CREATE, | | NFS4ERR_MOVED | ACCESS, CLOSE, COMMIT, CREATE, |
| | DELEGRETURN, GETATTR, GETFH, LINK, | | | DELEGRETURN, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, | | | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, | | | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, READ, READDIR, | | | OPEN_DOWNGRADE, PUTFH, READ, READDIR, |
| | READLINK, REMOVE, RENAME, RESTOREFH, | | | READLINK, REMOVE, RENAME, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, VERIFY, | | | SAVEFH, SECINFO, SETATTR, VERIFY, |
| | WRITE | | | WRITE |
| | |
| NFS4ERR_NAMETOOLONG | CREATE, LINK, LOOKUP, OPEN, REMOVE, | | NFS4ERR_NAMETOOLONG | CREATE, LINK, LOOKUP, OPEN, REMOVE, |
| | RENAME, SECINFO | | | RENAME, SECINFO |
| | |
| NFS4ERR_NOENT | LINK, LOOKUP, LOOKUPP, OPEN, OPENATTR, | | NFS4ERR_NOENT | LINK, LOOKUP, LOOKUPP, OPEN, OPENATTR, |
| | REMOVE, RENAME, SECINFO | | | REMOVE, RENAME, SECINFO |
| | |
| NFS4ERR_NOFILEHANDLE | ACCESS, CLOSE, COMMIT, CREATE, | | NFS4ERR_NOFILEHANDLE | ACCESS, CLOSE, COMMIT, CREATE, |
| | DELEGRETURN, GETATTR, GETFH, LINK, | | | DELEGRETURN, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, | | | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, | | | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, READ, READDIR, | | | OPEN_DOWNGRADE, READ, READDIR, |
| | READLINK, REMOVE, RENAME, SAVEFH, | | | READLINK, REMOVE, RENAME, SAVEFH, |
| | SECINFO, SETATTR, VERIFY, WRITE | | | SECINFO, SETATTR, VERIFY, WRITE |
| | |
| NFS4ERR_NOSPC | CREATE, LINK, OPEN, OPENATTR, RENAME, | | NFS4ERR_NOSPC | CREATE, LINK, OPEN, OPENATTR, RENAME, |
| | SETATTR, WRITE | | | SETATTR, WRITE |
| | |
| NFS4ERR_NOTDIR | CREATE, LINK, LOOKUP, LOOKUPP, OPEN, | | NFS4ERR_NOTDIR | CREATE, LINK, LOOKUP, LOOKUPP, OPEN, |
| | READDIR, REMOVE, RENAME, SECINFO | | | READDIR, REMOVE, RENAME, SECINFO |
| | |
| NFS4ERR_NOTEMPTY | REMOVE, RENAME | | NFS4ERR_NOTEMPTY | REMOVE, RENAME |
| | |
| NFS4ERR_NOTSUP | OPEN, READLINK | | NFS4ERR_NOTSUP | OPEN, READLINK |
| | |
| NFS4ERR_NOTSUPP | DELEGPURGE, DELEGRETURN, LINK, | | NFS4ERR_NOTSUPP | DELEGPURGE, DELEGRETURN, LINK, |
| | OPENATTR | | | OPENATTR |
| | |
| NFS4ERR_NOT_SAME | READDIR, VERIFY | | NFS4ERR_NOT_SAME | READDIR, VERIFY |
| | |
| NFS4ERR_NO_GRACE | LOCK, OPEN | | NFS4ERR_NO_GRACE | LOCK, OPEN |
| | |
| NFS4ERR_NXIO | WRITE | | NFS4ERR_NXIO | WRITE |
| | |
| NFS4ERR_OLD_STATEID | CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN, | | NFS4ERR_OLD_STATEID | CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, | | | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, |
| | SETATTR, WRITE | | | SETATTR, WRITE |
| | |
| NFS4ERR_OPENMODE | LOCK, READ, SETATTR, WRITE | | NFS4ERR_OPENMODE | LOCK, READ, SETATTR, WRITE |
| | |
| NFS4ERR_OP_ILLEGAL | CB_ILLEGAL, ILLEGAL | | NFS4ERR_OP_ILLEGAL | CB_ILLEGAL, ILLEGAL |
| | |
| NFS4ERR_PERM | CREATE, OPEN, SETATTR | | NFS4ERR_PERM | CREATE, OPEN, SETATTR |
| | |
| NFS4ERR_RECLAIM_BAD | LOCK, OPEN | | NFS4ERR_RECLAIM_BAD | LOCK, OPEN |
| | |
| NFS4ERR_RECLAIM_CONFLICT | LOCK, OPEN | | NFS4ERR_RECLAIM_CONFLICT | LOCK, OPEN |
| | |
| NFS4ERR_RESOURCE | ACCESS, CLOSE, COMMIT, CREATE, | | NFS4ERR_RESOURCE | ACCESS, CLOSE, COMMIT, CREATE, |
| | DELEGPURGE, DELEGRETURN, GETATTR, | | | DELEGPURGE, DELEGRETURN, GETATTR, |
| | GETFH, LINK, LOCK, LOCKT, LOCKU, | | | GETFH, LINK, LOCK, LOCKT, LOCKU, |
| | LOOKUP, LOOKUPP, OPEN, OPENATTR, | | | LOOKUP, LOOKUPP, OPEN, OPENATTR, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, | | | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, |
| | READDIR, READLINK, RELEASE_LOCKOWNER, | | | READDIR, READLINK, RELEASE_LOCKOWNER, |
| | REMOVE, RENAME, RENEW, RESTOREFH, | | | REMOVE, RENAME, RENEW, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, SETCLIENTID, | | | SAVEFH, SECINFO, SETATTR, SETCLIENTID, |
| | SETCLIENTID_CONFIRM, VERIFY, WRITE | | | SETCLIENTID_CONFIRM, VERIFY, WRITE |
| | |
| NFS4ERR_RESTOREFH | RESTOREFH | | NFS4ERR_RESTOREFH | RESTOREFH |
| | |
| NFS4ERR_ROFS | COMMIT, CREATE, LINK, OPEN, OPENATTR, | | NFS4ERR_ROFS | COMMIT, CREATE, LINK, OPEN, OPENATTR, |
| | OPEN_DOWNGRADE, REMOVE, RENAME, | | | OPEN_DOWNGRADE, REMOVE, RENAME, |
| | SETATTR, WRITE | | | SETATTR, WRITE |
| | |
| NFS4ERR_SAME | NVERIFY | | NFS4ERR_SAME | NVERIFY |
| | |
| NFS4ERR_SERVERFAULT | ACCESS, CB_GETATTR, CB_RECALL, CLOSE, | | NFS4ERR_SERVERFAULT | ACCESS, CB_GETATTR, CB_RECALL, CLOSE, |
| | COMMIT, CREATE, DELEGPURGE, | | | COMMIT, CREATE, DELEGPURGE, |
| | DELEGRETURN, GETATTR, GETFH, LINK, | | | DELEGRETURN, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, | | | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, | | | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, PUTPUBFH, | | | OPEN_DOWNGRADE, PUTFH, PUTPUBFH, |
| | PUTROOTFH, READ, READDIR, READLINK, | | | PUTROOTFH, READ, READDIR, READLINK, |
| | RELEASE_LOCKOWNER, REMOVE, RENAME, | | | RELEASE_LOCKOWNER, REMOVE, RENAME, |
| | RENEW, RESTOREFH, SAVEFH, SECINFO, | | | RENEW, RESTOREFH, SAVEFH, SECINFO, |
| | SETATTR, SETCLIENTID, | | | SETATTR, SETCLIENTID, |
| | SETCLIENTID_CONFIRM, VERIFY, WRITE | | | SETCLIENTID_CONFIRM, VERIFY, WRITE |
| | |
| NFS4ERR_SHARE_DENIED | OPEN | | NFS4ERR_SHARE_DENIED | OPEN |
| | |
| NFS4ERR_STALE | ACCESS, CLOSE, COMMIT, CREATE, | | NFS4ERR_STALE | ACCESS, CLOSE, COMMIT, CREATE, |
| | DELEGRETURN, GETATTR, GETFH, LINK, | | | DELEGRETURN, GETATTR, GETFH, LINK, |
| | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, | | | LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, |
| | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, | | | NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, |
| | OPEN_DOWNGRADE, PUTFH, READ, READDIR, | | | OPEN_DOWNGRADE, PUTFH, READ, READDIR, |
| | READLINK, REMOVE, RENAME, RESTOREFH, | | | READLINK, REMOVE, RENAME, RESTOREFH, |
| | SAVEFH, SECINFO, SETATTR, VERIFY, | | | SAVEFH, SECINFO, SETATTR, VERIFY, |
| | WRITE | | | WRITE |
| | |
| NFS4ERR_STALE_CLIENTID | DELEGPURGE, LOCK, LOCKT, OPEN, | | NFS4ERR_STALE_CLIENTID | DELEGPURGE, LOCK, LOCKT, OPEN, |
| | RELEASE_LOCKOWNER, RENEW, | | | RELEASE_LOCKOWNER, RENEW, |
| | SETCLIENTID_CONFIRM | | | SETCLIENTID_CONFIRM |
| | |
| NFS4ERR_STALE_STATEID | CLOSE, DELEGRETURN, LOCK, LOCKU, | | NFS4ERR_STALE_STATEID | CLOSE, DELEGRETURN, LOCK, LOCKU, |
| | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, | | | OPEN_CONFIRM, OPEN_DOWNGRADE, READ, |
| | SETATTR, WRITE | | | SETATTR, WRITE |
| | |
| NFS4ERR_SYMLINK | COMMIT, LOOKUP, LOOKUPP, OPEN, READ, | | NFS4ERR_SYMLINK | COMMIT, LOOKUP, LOOKUPP, OPEN, READ, |
| | WRITE | | | WRITE |
| | |
| NFS4ERR_TOOSMALL | READDIR | | NFS4ERR_TOOSMALL | READDIR |
| | |
| NFS4ERR_WRONGSEC | LINK, LOOKUP, LOOKUPP, OPEN, PUTFH, | | NFS4ERR_WRONGSEC | LINK, LOOKUP, LOOKUPP, OPEN, PUTFH, |
| | PUTPUBFH, PUTROOTFH, RENAME, RESTOREFH | | | PUTPUBFH, PUTROOTFH, RENAME, RESTOREFH |
| | |
| NFS4ERR_XDEV | LINK, RENAME | | NFS4ERR_XDEV | LINK, RENAME |
| | |
+--------------------------+----------------------------------------+ +--------------------------+----------------------------------------+
Table 8 Table 8
14. NFSv4 Requests 14. NFSv4 Requests
For the NFSv4 RPC program, there are two traditional RPC procedures: For the NFSv4 RPC program, there are two traditional RPC procedures:
NULL and COMPOUND. All other functionality is defined as a set of NULL and COMPOUND. All other functionality is defined as a set of
operations and these operations are defined in normal XDR/RPC syntax operations and these operations are defined in normal XDR/RPC syntax
and semantics. However, these operations are encapsulated within the and semantics. However, these operations are encapsulated within the
skipping to change at page 205, line 44 skipping to change at page 206, line 36
It is possible that the server receives a request that contains an It is possible that the server receives a request that contains an
operation that is less than the first legal operation (OP_ACCESS) or operation that is less than the first legal operation (OP_ACCESS) or
greater than the last legal operation (OP_RELEASE_LOCKOWNER). In greater than the last legal operation (OP_RELEASE_LOCKOWNER). In
this case, the server's response will encode the opcode OP_ILLEGAL this case, the server's response will encode the opcode OP_ILLEGAL
rather than the illegal opcode of the request. The status field in rather than the illegal opcode of the request. The status field in
the ILLEGAL return results will set to NFS4ERR_OP_ILLEGAL. The the ILLEGAL return results will set to NFS4ERR_OP_ILLEGAL. The
COMPOUND procedure's return results will also be NFS4ERR_OP_ILLEGAL. COMPOUND procedure's return results will also be NFS4ERR_OP_ILLEGAL.
The definition of the "tag" in the request is left to the The definition of the "tag" in the request is left to the
implementor. It may be used to summarize the content of the compound implementer. It may be used to summarize the content of the compound
request for the benefit of packet sniffers and engineers debugging request for the benefit of packet sniffers and engineers debugging
implementations. However, the value of "tag" in the response SHOULD implementations. However, the value of "tag" in the response SHOULD
be the same value as provided in the request. This applies to the be the same value as provided in the request. This applies to the
tag field of the CB_COMPOUND procedure as well. tag field of the CB_COMPOUND procedure as well.
15.2.4.1. Current Filehandle 15.2.4.1. Current Filehandle
The current and saved filehandle are used throughout the protocol. The current and saved filehandle are used throughout the protocol.
Most operations implicitly use the current filehandle as a argument Most operations implicitly use the current filehandle as a argument
and many set the current filehandle as part of the results. The and many set the current filehandle as part of the results. The
skipping to change at page 213, line 29 skipping to change at page 214, line 11
until the buffer has either been flushed via a COMMIT operation or until the buffer has either been flushed via a COMMIT operation or
written via a WRITE operation with stable parameter set to FILE_SYNC4 written via a WRITE operation with stable parameter set to FILE_SYNC4
or DATA_SYNC4. This is done to prevent the buffer from being freed or DATA_SYNC4. This is done to prevent the buffer from being freed
and reused before the data can be flushed to stable storage on the and reused before the data can be flushed to stable storage on the
server. server.
When a response is returned from either a WRITE or a COMMIT operation When a response is returned from either a WRITE or a COMMIT operation
and it contains a write verifier that is different than previously and it contains a write verifier that is different than previously
returned by the server, the client will need to retransmit all of the returned by the server, the client will need to retransmit all of the
buffers containing uncommitted cached data to the server. How this buffers containing uncommitted cached data to the server. How this
is to be done is up to the implementor. If there is only one buffer is to be done is up to the implementer. If there is only one buffer
of interest, then it should probably be sent back over in a WRITE of interest, then it should probably be sent back over in a WRITE
request with the appropriate stable parameter. If there is more than request with the appropriate stable parameter. If there is more than
one buffer, it might be worthwhile retransmitting all of the buffers one buffer, it might be worthwhile retransmitting all of the buffers
in WRITE requests with the stable parameter set to UNSTABLE4 and then in WRITE requests with the stable parameter set to UNSTABLE4 and then
retransmitting the COMMIT operation to flush all of the data on the retransmitting the COMMIT operation to flush all of the data on the
server to stable storage. The timing of these retransmissions is server to stable storage. The timing of these retransmissions is
left to the implementor. left to the implementer.
The above description applies to page-cache-based systems as well as The above description applies to page-cache-based systems as well as
buffer-cache-based systems. In those systems, the virtual memory buffer-cache-based systems. In those systems, the virtual memory
system will need to be modified instead of the buffer cache. system will need to be modified instead of the buffer cache.
15.6. Operation 6: CREATE - Create a Non-Regular File Object 15.6. Operation 6: CREATE - Create a Non-Regular File Object
15.6.1. SYNOPSIS 15.6.1. SYNOPSIS
(cfh), name, type, attrs -> (cfh), cinfo, attrset (cfh), name, type, attrs -> (cfh), cinfo, attrset
skipping to change at page 258, line 46 skipping to change at page 260, line 16
15.28.5. IMPLEMENTATION 15.28.5. IMPLEMENTATION
NFSv3 required a different operator RMDIR for directory removal and NFSv3 required a different operator RMDIR for directory removal and
REMOVE for non-directory removal. This allowed clients to skip REMOVE for non-directory removal. This allowed clients to skip
checking the file type when being passed a non-directory delete checking the file type when being passed a non-directory delete
system call (e.g., unlink() [unlink] in POSIX) to remove a directory, system call (e.g., unlink() [unlink] in POSIX) to remove a directory,
as well as the converse (e.g., a rmdir() on a non-directory) because as well as the converse (e.g., a rmdir() on a non-directory) because
they knew the server would check the file type. NFSv4 REMOVE can be they knew the server would check the file type. NFSv4 REMOVE can be
used to delete any directory entry independent of its file type. The used to delete any directory entry independent of its file type. The
implementor of an NFSv4 client's entry points from the unlink() and implementer of an NFSv4 client's entry points from the unlink() and
rmdir() system calls should first check the file type against the rmdir() system calls should first check the file type against the
types the system call is allowed to remove before issuing a REMOVE. types the system call is allowed to remove before issuing a REMOVE.
Alternatively, the implementor can produce a COMPOUND call that Alternatively, the implementer can produce a COMPOUND call that
includes a LOOKUP/VERIFY sequence to verify the file type before a includes a LOOKUP/VERIFY sequence to verify the file type before a
REMOVE operation in the same COMPOUND call. REMOVE operation in the same COMPOUND call.
The concept of last reference is server specific. However, if the The concept of last reference is server specific. However, if the
numlinks field in the previous attributes of the object had the value numlinks field in the previous attributes of the object had the value
1, the client should not rely on referring to the object via a 1, the client should not rely on referring to the object via a
filehandle. Likewise, the client should not rely on the resources filehandle. Likewise, the client should not rely on the resources
(disk space, directory entry, and so on) formerly associated with the (disk space, directory entry, and so on) formerly associated with the
object becoming immediately available. Thus, if a client needs to be object becoming immediately available. Thus, if a client needs to be
able to continue to access a file after using REMOVE to remove it, able to continue to access a file after using REMOVE to remove it,
skipping to change at page 261, line 20 skipping to change at page 262, line 34
15.29.5. IMPLEMENTATION 15.29.5. IMPLEMENTATION
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 implementers 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
oldname or newname, and will result in the error NFS4ERR_BADNAME. In oldname or newname, and will result in the error NFS4ERR_BADNAME. In
addition, on many servers the case of oldname or newname being an addition, on many servers the case of oldname or newname being an
alias for the source directory will be checked for. Such servers alias for the source directory will be checked for. Such servers
will return the error NFS4ERR_INVAL in these cases. will return the error NFS4ERR_INVAL in these cases.
If either of the source or target filehandles are not directories, If either of the source or target filehandles are not directories,
the server will return NFS4ERR_NOTDIR. the server will return NFS4ERR_NOTDIR.
skipping to change at page 272, line 49 skipping to change at page 273, line 49
record with the same id string x, if the recorded principal does record with the same id string x, if the recorded principal does
not match that of SETCLIENTID call, then the server returns a not match that of SETCLIENTID call, then the server returns a
NFS4ERR_CLID_INUSE error. NFS4ERR_CLID_INUSE error.
For brevity of discussion, the remaining description of the For brevity of discussion, the remaining description of the
processing assumes that there was a DRC miss, and that where the processing assumes that there was a DRC miss, and that where the
server has previously recorded a confirmed record for client x, server has previously recorded a confirmed record for client x,
the aforementioned principal check has successfully passed. the aforementioned principal check has successfully passed.
o The server checks if it has recorded a confirmed record for { v, o The server checks if it has recorded a confirmed record for { v,
x, c, l, s }, where l may or may not equal k. If so, and since x, c, l, s }, where l may or may not equal k. If so, and since the
the id verifier v of the request matches that which is confirmed id verifier v of the request matches that which is confirmed and
and recorded, the server treats this as a probable callback recorded, the server treats this as a probable callback
information update and records an unconfirmed { v, x, c, k, t } information update and records an unconfirmed { v, x, c, k, t }
and leaves the confirmed { v, x, c, l, s } in place, such that t and leaves the confirmed { v, x, c, l, s } in place, such that t
!= s. It does not matter if k equals l or not. Any pre-existing != s. It does not matter if k equals l or not. Any pre-existing
unconfirmed { v, x, c, *, * } is removed. unconfirmed { v, x, c, *, * } is removed.
The server returns { c, t }. It is indeed returning the old The server returns { c, t }. It is indeed returning the old
clientid4 value c, because the client apparently only wants to clientid4 value c, because the client apparently only wants to
update callback value k to value l. It's possible this request is update callback value k to value l. It's possible this request is
one from the Byzantine router that has stale callback information, one from the Byzantine router that has stale callback information,
but this is not a problem. The callback information update is but this is not a problem. The callback information update is
only confirmed if followed up by a SETCLIENTID_CONFIRM { c, t }. only confirmed if followed up by a SETCLIENTID_CONFIRM { c, t }.
The server awaits confirmation of k via SETCLIENTID_CONFIRM { c, t The server awaits confirmation of k via SETCLIENTID_CONFIRM { c, t
}. }.
The server does NOT remove client (lock/share/delegation) state The server does NOT remove client (lock/share/delegation) state
skipping to change at page 273, line 38 skipping to change at page 274, line 38
The server awaits confirmation of { d, k } via SETCLIENTID_CONFIRM The server awaits confirmation of { d, k } via SETCLIENTID_CONFIRM
{ d, t }. { d, t }.
The server does NOT remove client (lock/share/delegation) state The server does NOT remove client (lock/share/delegation) state
for x. for x.
o The server has previously recorded a confirmed { u, x, c, l, s } o The server has previously recorded a confirmed { u, x, c, l, s }
record such that v != u, l may or may not equal k, and recorded an record such that v != u, l may or may not equal k, and recorded an
unconfirmed { w, x, d, m, t } record such that c != d, t != s, m unconfirmed { w, x, d, m, t } record such that c != d, t != s, m
may or may not equal k, m may or may not equal l, and k may or may may or may not equal k, m may or may not equal l, and k may or may
not equal l. Whether w == v or w != v makes no difference. The not equal l. Whether w == v or w != v makes no difference. The
server simply removes the unconfirmed { w, x, d, m, t } record and server simply removes the unconfirmed { w, x, d, m, t } record and
replaces it with an unconfirmed { v, x, e, k, r } record, such replaces it with an unconfirmed { v, x, e, k, r } record, such
that e != d, e != c, r != t, r != s. that e != d, e != c, r != t, r != s.
The server returns { e, r }. The server returns { e, r }.
The server awaits confirmation of { e, k } via SETCLIENTID_CONFIRM The server awaits confirmation of { e, k } via SETCLIENTID_CONFIRM
{ e, r }. { e, r }.
The server does NOT remove client (lock/share/delegation) state The server does NOT remove client (lock/share/delegation) state
for x. for x.
o The server has no confirmed { *, x, *, *, * } for x. It may or o The server has no confirmed { *, x, *, *, * } for x. It may or may
may not have recorded an unconfirmed { u, x, c, l, s }, where l not have recorded an unconfirmed { u, x, c, l, s }, where l may or
may or may not equal k, and u may or may not equal v. Any may not equal k, and u may or may not equal v. Any unconfirmed
unconfirmed record { u, x, c, l, * }, regardless whether u == v or record { u, x, c, l, * }, regardless whether u == v or l == k, is
l == k, is replaced with an unconfirmed record { v, x, d, k, t } replaced with an unconfirmed record { v, x, d, k, t } where d !=
where d != c, t != s. c, t != s.
The server returns { d, t }. The server returns { d, t }.
The server awaits confirmation of { d, k } via SETCLIENTID_CONFIRM The server awaits confirmation of { d, k } via SETCLIENTID_CONFIRM
{ d, t }. The server does NOT remove client (lock/share/ { d, t }. The server does NOT remove client (lock/share/
delegation) state for x. delegation) state for x.
The server generates the clientid and setclientid_confirm values and The server generates the clientid and setclientid_confirm values and
must take care to ensure that these values are extremely unlikely to must take care to ensure that these values are extremely unlikely to
ever be regenerated. ever be regenerated.
skipping to change at page 276, line 21 skipping to change at page 277, line 21
Otherwise, the confirmed { v, x, c, l, t } record is removed and Otherwise, the confirmed { v, x, c, l, t } record is removed and
the unconfirmed { v, x, c, k, s } is marked as confirmed, thereby the unconfirmed { v, x, c, k, s } is marked as confirmed, thereby
modifying recorded and confirmed callback and callback_ident modifying recorded and confirmed callback and callback_ident
information for client { x }. information for client { x }.
The server does not remove any relevant leased client state. The server does not remove any relevant leased client state.
The server returns NFS4_OK. The server returns NFS4_OK.
o The server has not recorded an unconfirmed { v, x, c, *, * } and o The server has not recorded an unconfirmed { v, x, c, *, * } and
has recorded a confirmed { v, x, c, *, s }. If the principals of has recorded a confirmed { v, x, c, *, s }. If the principals of
the record and of SETCLIENTID_CONFIRM do not match, the server the record and of SETCLIENTID_CONFIRM do not match, the server
returns NFS4ERR_CLID_INUSE without removing any relevant leased returns NFS4ERR_CLID_INUSE without removing any relevant leased
client state and without changing recorded callback and client state and without changing recorded callback and
callback_ident values for client { x }. callback_ident values for client { x }.
If the principals match, then what has likely happened is that the If the principals match, then what has likely happened is that the
client never got the response from the SETCLIENTID_CONFIRM, and client never got the response from the SETCLIENTID_CONFIRM, and
the DRC entry has been purged. Whatever the scenario, since the the DRC entry has been purged. Whatever the scenario, since the
principals match, as well as { c, s } matching a confirmed record, principals match, as well as { c, s } matching a confirmed record,
the server leaves client x's relevant leased client state intact, the server leaves client x's relevant leased client state intact,
skipping to change at page 276, line 45 skipping to change at page 277, line 45
o The server has not recorded a confirmed { *, *, c, *, * }, and has o The server has not recorded a confirmed { *, *, c, *, * }, and has
recorded an unconfirmed { *, x, c, k, s }. Even if this is a recorded an unconfirmed { *, x, c, k, s }. Even if this is a
retry from client, nonetheless the client's first retry from client, nonetheless the client's first
SETCLIENTID_CONFIRM attempt was not received by the server. Retry SETCLIENTID_CONFIRM attempt was not received by the server. Retry
or not, the server doesn't know, but it processes it as if were a or not, the server doesn't know, but it processes it as if were a
first try. If the principal of the unconfirmed { *, x, c, k, s } first try. If the principal of the unconfirmed { *, x, c, k, s }
record mismatches that of the SETCLIENTID_CONFIRM request the record mismatches that of the SETCLIENTID_CONFIRM request the
server returns NFS4ERR_CLID_INUSE without removing any relevant server returns NFS4ERR_CLID_INUSE without removing any relevant
leased client state. leased client state.
Otherwise, the server records a confirmed { *, x, c, k, s }. If Otherwise, the server records a confirmed { *, x, c, k, s }. If
there is also a confirmed { *, x, d, *, t }, the server MUST there is also a confirmed { *, x, d, *, t }, the server MUST
remove the client x's relevant leased client state, and overwrite remove the client x's relevant leased client state, and overwrite
the callback state with k. The confirmed record { *, x, d, *, t } the callback state with k. The confirmed record { *, x, d, *, t }
is removed. is removed.
Server returns NFS4_OK. Server returns NFS4_OK.
o The server has no record of a confirmed or unconfirmed { *, *, c, o The server has no record of a confirmed or unconfirmed { *, *, c,
*, s }. The server returns NFS4ERR_STALE_CLIENTID. The server *, s }. The server returns NFS4ERR_STALE_CLIENTID. The server
does not remove any relevant leased client state, nor does it does not remove any relevant leased client state, nor does it
modify any recorded callback and callback_ident information for modify any recorded callback and callback_ident information for
any client. any client.
skipping to change at page 280, line 16 skipping to change at page 281, line 16
Part of the write request is a specification of how the write is to Part of the write request is a specification of how the write is to
be performed. The client specifies with the stable parameter the be performed. The client specifies with the stable parameter the
method of how the data is to be processed by the server. If stable method of how the data is to be processed by the server. If stable
is FILE_SYNC4, the server must commit the data written plus all file is FILE_SYNC4, the server must commit the data written plus all file
system metadata to stable storage before returning results. This system metadata to stable storage before returning results. This
corresponds to the NFS version 2 protocol semantics. Any other corresponds to the NFS version 2 protocol semantics. Any other
behavior constitutes a protocol violation. If stable is DATA_SYNC4, behavior constitutes a protocol violation. If stable is DATA_SYNC4,
then the server must commit all of the data to stable storage and then the server must commit all of the data to stable storage and
enough of the metadata to retrieve the data before returning. The enough of the metadata to retrieve the data before returning. The
server implementor is free to implement DATA_SYNC4 in the same server implementer is free to implement DATA_SYNC4 in the same
fashion as FILE_SYNC4, but with a possible performance drop. If fashion as FILE_SYNC4, but with a possible performance drop. If
stable is UNSTABLE4, the server is free to commit any part of the stable is UNSTABLE4, the server is free to commit any part of the
data and the metadata to stable storage, including all or none, data and the metadata to stable storage, including all or none,
before returning a reply to the client. There is no guarantee before returning a reply to the client. There is no guarantee
whether or when any uncommitted data will subsequently be committed whether or when any uncommitted data will subsequently be committed
to stable storage. The only guarantees made by the server are that to stable storage. The only guarantees made by the server are that
it will not destroy any data without changing the value of verf and it will not destroy any data without changing the value of verf and
that it will not commit the data and metadata at a level less than that it will not commit the data and metadata at a level less than
that requested by the client. that requested by the client.
skipping to change at page 292, line 9 skipping to change at page 293, line 7
GETATTR for the fs_locations attribute, the attacker modifies the GETATTR for the fs_locations attribute, the attacker modifies the
results to cause the client migrate its traffic to a server results to cause the client migrate its traffic to a server
controlled by the attacker. controlled by the attacker.
Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are Because the operations SETCLIENTID/SETCLIENTID_CONFIRM are
responsible for the release of client state, it is imperative that responsible for the release of client state, it is imperative that
the principal used for these operations is checked against and match the principal used for these operations is checked against and match
the previous use of these operations. See Section 9.1.1 for further the previous use of these operations. See Section 9.1.1 for further
discussion. discussion.
Unicode in the form of UTF-8 is used for file component names (i.e.,
both directory and file components), as well as the owner and
owner_group attributes; other character sets may also be allowed for
file component names. String processing (e.g., Unicode
normalization) raises security concerns for string comparison - see
5.9 and 12 for further discussion and see [RFC6943] for related
identifier comparison security considerations. File component names
are identifiers with respect to the identifier comparison discussion
in [RFC6943] because they are used to identify the objects to which
ACLs are applied, see Section 6.
18. IANA Considerations 18. IANA Considerations
This section uses terms that are defined in [RFC5226]. This section uses terms that are defined in [RFC5226].
18.1. Named Attribute Definitions 18.1. Named Attribute Definitions
IANA has created a registry called the "NFSv4 Named Attribute IANA has created a registry called the "NFSv4 Named Attribute
Definitions Registry" for [RFC3530] and [RFC5661]. This section Definitions Registry" for [RFC3530] and [RFC5661]. This section
introduces no new changes, but it does recap the intent. introduces no new changes, but it does recap the intent.
skipping to change at page 292, line 47 skipping to change at page 294, line 8
Under the NFSv4 specification, the name of a named attribute can in Under the NFSv4 specification, the name of a named attribute can in
theory be up to 2^32 - 1 bytes in length, but in practice NFSv4 theory be up to 2^32 - 1 bytes in length, but in practice NFSv4
clients and servers will be unable to handle a string that long. clients and servers will be unable to handle a string that long.
IANA should reject any assignment request with a named attribute that IANA should reject any assignment request with a named attribute that
exceeds 128 UTF-8 characters. To give IESG the flexibility to set up exceeds 128 UTF-8 characters. To give IESG the flexibility to set up
bases of assignment of Experimental Use and Standards Action, the bases of assignment of Experimental Use and Standards Action, the
prefixes of "EXPE" and "STDS" are Reserved. The zero length named prefixes of "EXPE" and "STDS" are Reserved. The zero length named
attribute name is Reserved. attribute name is Reserved.
The prefix "PRIV" is allocated for Private Use. A site that wants to The prefix "PRIV" is allocated for Private Use. A site that wants to
make use of unregistered named attributes without risk of conflicting make use of unregistered named attributes without risk of conflicting
with an assignment in IANA's registry should use the prefix "PRIV" in with an assignment in IANA's registry should use the prefix "PRIV" in
all of its named attributes. all of its named attributes.
Because some NFSv4 clients and servers have case insensitive Because some NFSv4 clients and servers have case insensitive
semantics, the fifteen additional lower case and mixed case semantics, the fifteen additional lower case and mixed case
permutations of each of "EXPE", "PRIV", and "STDS", are Reserved permutations of each of "EXPE", "PRIV", and "STDS", are Reserved
(e.g. "expe", "expE", "exPe", etc. are Reserved). Similarly, IANA (e.g. "expe", "expE", "exPe", etc. are Reserved). Similarly, IANA
must not allow two assignments that would conflict if both named must not allow two assignments that would conflict if both named
attributes were converted to a common case. attributes were converted to a common case.
The registry of named attributes is a list of assignments, each The registry of named attributes is a list of assignments, each
containing three fields for each assignment. containing three fields for each assignment.
1. A US-ASCII string name that is the actual name of the attribute. 1. A US-ASCII string name that is the actual name of the attribute.
This name must be unique. This string name can be 1 to 128 UTF-8 This name must be unique. This string name can be 1 to 128 UTF-8
characters long. characters long.
skipping to change at page 293, line 39 skipping to change at page 294, line 47
18.1.2. Updating Registrations 18.1.2. Updating Registrations
The registrant is always permitted to update the point of contact The registrant is always permitted to update the point of contact
field. To make any other change will require Expert Review or IESG field. To make any other change will require Expert Review or IESG
Approval. Approval.
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-nfsv4-rfc3530bis-dot-x] [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR October 1969.
Description", draft-ietf-nfsv4-rfc3530bis-dot-x-21 (work
in progress), Feb 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998. 10646", RFC 2279, January 1998.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403, [RFC5403] Eisler, M., "RPCSEC_GSS Version 2", RFC 5403, February
February 2009. 2009.
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 5531, May 2009. Specification Version 2", RFC 5531, May 2009.
[RFC5665] Eisler, M., Ed., "IANA Considerations for Remote Procedure [RFC5665] Eisler, M., Ed., "IANA Considerations for Remote Procedure
Call (RPC) Network Identifiers and Universal Address Call (RPC) Network Identifiers and Universal Address
Formats", RFC 5665, January 2010. Formats", RFC 5665, January 2010.
[RFC5890] Klensin, J., "Internationalized Domain Names in [RFC5890] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010. Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC6649] Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC-EXP, and [RFC6649] Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC-EXP, and
Other Weak Cryptographic Algorithms in Kerberos", Other Weak Cryptographic Algorithms in Kerberos", RFC
RFC 6649, July 2012. 6649, July 2012.
[RFC6943] Thaler, D., "Issues in Identifier Comparison for Security
Purposes", RFC 6943, May 2013.
[RFCNFSv4XDR]
Haynes, T. and D. Noveck, "NFSv4 Version 0 XDR
Description", draft-ietf-nfsv4-rfc3530bis-dot-x-22 (work
in progress), Apr 2014.
[SPECIALCASING] [SPECIALCASING]
The Unicode Consortium, "SpecialCasing-6.3.0.txt", Unicode The Unicode Consortium, "SpecialCasing-6.3.0.txt", Unicode
Character Database , September 2013, <http:// Character Database , September 2013,
www.unicode.org/Public/6.3.0/ucd/SpecialCasing.txt>. <http://www.unicode.org/Public/6.3.0/ucd/
SpecialCasing.txt>.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
6.3.0", September 2013, 6.3.0", September 2013,
<http://www.unicode.org/versions/Unicode6.3.0/>. <http://www.unicode.org/versions/Unicode6.3.0/>.
[openg_symlink] [openg_symlink]
The Open Group, "Section 3.372 of Chapter 3 of Base The Open Group, "Section 3.372 of Chapter 3 of Base
Definitions of The Open Group Base Specifications Issue 6, Definitions of The Open Group Base Specifications Issue 6,
IEEE Std 1003.1, 2004 Edition, HTML Version IEEE Std 1003.1, 2004 Edition, HTML Version
(www.opengroup.org), ISBN 1931624232", 2004. (www.opengroup.org), ISBN 1931624232", 2004.
19.2. Informative References 19.2. Informative References
[Chet] Juszczak, C., "Improving the Performance and Correctness [Chet] Juszczak, C., "Improving the Performance and Correctness
of an NFS Server", USENIX Conference Proceedings , of an NFS Server", USENIX Conference Proceedings , June
June 1990. 1990.
[Floyd] Floyd, S. and V. Jacobson, "The Synchronization of [Floyd] Floyd, S. and V. Jacobson, "The Synchronization of
Periodic Routing Messages", IEEE/ACM Transactions on Periodic Routing Messages", IEEE/ACM Transactions on
Networking 2(2), pp. 122-136, April 1994. Networking 2(2), pp. 122-136, April 1994.
[ISEG_errata] [ISEG_errata]
IESG, "IESG Processing of RFC Errata for the IETF Stream", IESG, "IESG Processing of RFC Errata for the IETF Stream",
July 2008. July 2008.
[P1003.1e] [P1003.1e]
Institute of Electrical and Electronics Engineers, Inc., Institute of Electrical and Electronics Engineers, Inc.,
"IEEE Draft P1003.1e", 1997. "IEEE Draft P1003.1e", 1997.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
RFC 793, September 1981. 793, September 1981.
[RFC1094] Nowicki, B., "NFS: Network File System Protocol [RFC1094] Nowicki, B., "NFS: Network File System Protocol
specification", RFC 1094, March 1989. specification", RFC 1094, March 1989.
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813, June 1995. Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2",
RFC 1833, August 1995. RFC 1833, August 1995.
skipping to change at page 295, line 37 skipping to change at page 297, line 5
[RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055, [RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055,
October 1996. October 1996.
[RFC2224] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. [RFC2224] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997.
[RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues [RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues
and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5",
RFC 2623, June 1999. RFC 2623, June 1999.
[RFC2624] Shepler, S., "NFS Version 4 Design Considerations", [RFC2624] Shepler, S., "NFS Version 4 Design Considerations", RFC
RFC 2624, June 1999. 2624, June 1999.
[RFC2755] Chiu, A., Eisler, M., and B. Callaghan, "Security [RFC2755] Chiu, A., Eisler, M., and B. Callaghan, "Security
Negotiation for WebNFS", RFC 2755, January 2000. Negotiation for WebNFS", RFC 2755, January 2000.
[RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3010, December 2000. (NFS) version 4 Protocol", RFC 3010, December 2000.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121, Interface (GSS-API) Mechanism: Version 2", RFC 4121, July
July 2005. 2005.
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
Simple and Protected Generic Security Service Application Simple and Protected Generic Security Service Application
Program Interface (GSS-API) Negotiation Mechanism", Program Interface (GSS-API) Negotiation Mechanism", RFC
RFC 4178, October 2005. 4178, October 2005.
[RFC4506] Eisler, M., "XDR: External Data Representation Standard", [RFC4506] Eisler, M., "XDR: External Data Representation Standard",
RFC 4506, May 2006. RFC 4506, May 2006.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006. (LDAP): The Protocol", RFC 4511, June 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol", System (NFS) Version 4 Minor Version 1 Protocol", RFC
RFC 5661, January 2010. 5661, January 2010.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365,
September 2011.
[fcntl] The Open Group, "Section 'fcntl()' of System Interfaces of [fcntl] The Open Group, "Section 'fcntl()' of System Interfaces of
The Open Group Base Specifications Issue 6 IEEE Std The Open Group Base Specifications Issue 6 IEEE Std
1003.1, 2004 Edition, HTML Version (www.opengroup.org), 1003.1, 2004 Edition, HTML Version (www.opengroup.org),
ISBN 1931624232", 2004. ISBN 1931624232", 2004.
[fsync] The Open Group, "Section 'fsync()' of System Interfaces of [fsync] The Open Group, "Section 'fsync()' of System Interfaces of
The Open Group Base Specifications Issue 6 IEEE Std The Open Group Base Specifications Issue 6 IEEE Std
1003.1, 2004 Edition, HTML Version (www.opengroup.org), 1003.1, 2004 Edition, HTML Version (www.opengroup.org),
ISBN 1931624232", 2004. ISBN 1931624232", 2004.
skipping to change at page 297, line 30 skipping to change at page 299, line 7
[xnfs] The Open Group, "Protocols for Interworking: XNFS, Version [xnfs] The Open Group, "Protocols for Interworking: XNFS, Version
3W, ISBN 1-85912-184-5", February 1998. 3W, ISBN 1-85912-184-5", February 1998.
Appendix A. Acknowledgments Appendix A. Acknowledgments
A bis is certainly built on the shoulders of the first attempt. A bis is certainly built on the shoulders of the first attempt.
Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow, Spencer Shepler, Brent Callaghan, David Robinson, Robert Thurlow,
Carl Beame, Mike Eisler, and David Noveck are responsible for a great Carl Beame, Mike Eisler, and David Noveck are responsible for a great
deal of the effort in this work. deal of the effort in this work.
Tom Haynes would like to thank NetApp, Inc. for its funding of his
time on this project.
Rob Thurlow clarified how a client should contact a new server if a Rob Thurlow clarified how a client should contact a new server if a
migration has occurred. migration has occurred.
David Black, Nico Williams, Mike Eisler, Trond Myklebust, James David Black, Nico Williams, Mike Eisler, Trond Myklebust, James
Lentini, and Mike Kupfer read many drafts of Section 12 and Lentini, and Mike Kupfer read many drafts of Section 12 and
contributed numerous useful suggestions, without which the necessary contributed numerous useful suggestions, without which the necessary
revision of that section for this document would not have been revision of that section for this document would not have been
possible. possible.
Peter Staubach read almost all of the drafts of Section 12 leading to Peter Staubach read almost all of the drafts of Section 12 leading to
the published result and his numerous comments were always useful and the published result and his numerous comments were always useful and
contributed substantially to improving the quality of the final contributed substantially to improving the quality of the final
result. result.
Peter Saint-Andre was gracious enough to read the last draft of
Section 12 and provided some key insight as to the concerns of the
Internationalization community.
James Lentini graciously read the rewrite of Section 8 and his James Lentini graciously read the rewrite of Section 8 and his
comments were vital in improving the quality of that effort. comments were vital in improving the quality of that effort.
Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond Rob Thurlow, Sorin Faibish, James Lentini, Bruce Fields, and Trond
Myklebust were faithful attendants of the biweekly triage meeting and Myklebust were faithful attendants of the biweekly triage meeting and
accepted many an action item. accepted many an action item.
Bruce Fields was a good sounding board for both the Third Edge Bruce Fields was a good sounding board for both the Third Edge
Condition and Courtesy Locks in general. He was also the leading Condition and Courtesy Locks in general. He was also the leading
advocate of stamping out backport issues from [RFC5661]. advocate of stamping out backport issues from [RFC5661].
skipping to change at page 298, line 29 skipping to change at page 300, line 15
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCNFSv4XDR with RFCxxxx where xxxx is the replace all occurrences of RFCNFSv4XDR with RFCxxxx where xxxx is the
RFC number assigned to the XDR document.] RFC number assigned to the XDR document.]
[RFC Editor: Please note that there is also a reference entry that [RFC Editor: Please note that there is also a reference entry that
needs to be modified for the companion document.] needs to be modified for the companion document.]
Authors' Addresses Authors' Addresses
Thomas Haynes (editor) Thomas Haynes (editor)
NetApp Primary Data, Inc.
495 E Java Dr 4300 El Camino Real Ste 100
Sunnyvale, CA 95054 Los Altos, CA 94022
USA USA
Phone: +1 408 419 3018 Phone: +1 408 215 1519
Email: thomas@netapp.com Email: thomas.haynes@primarydata.com
David Noveck (editor) David Noveck (editor)
26 Locust Ave 26 Locust Ave
Lexington, MA 02421 Lexington, MA 02421
US US
Phone: +1 781 572 8038 Phone: +1 781 572 8038
Email: davenoveck@gmail.com Email: davenoveck@gmail.com
 End of changes. 207 change blocks. 
420 lines changed or deleted 575 lines changed or added

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