draft-ietf-nfsv4-rfc3530bis-27.txt   draft-ietf-nfsv4-rfc3530bis-28.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Obsoletes: 3530 (if approved) D. Noveck, Ed. Obsoletes: 3530 (if approved) D. Noveck, Ed.
Intended status: Standards Track EMC Intended status: Standards Track EMC
Expires: February 17, 2014 August 16, 2013 Expires: April 22, 2014 October 19, 2013
Network File System (NFS) Version 4 Protocol Network File System (NFS) Version 4 Protocol
draft-ietf-nfsv4-rfc3530bis-27.txt draft-ietf-nfsv4-rfc3530bis-28.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 49 skipping to change at page 1, line 49
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 February 17, 2014. This Internet-Draft will expire on April 22, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 3, line 7
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 . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1. NFS Version 4 Goals . . . . . . . . . . . . . . . . . . 8 1.1. NFS Version 4 Goals . . . . . . . . . . . . . . . . . . 9
1.2. Definitions in the companion document NFS Version 4 1.2. Definitions in the companion document NFS Version 4
Protocol are Authoritative . . . . . . . . . . . . . . . 8 Protocol are Authoritative . . . . . . . . . . . . . . . 9
1.3. Overview of NFSv4 Features . . . . . . . . . . . . . . . 9 1.3. Overview of NFSv4 Features . . . . . . . . . . . . . . . 10
1.3.1. RPC and Security . . . . . . . . . . . . . . . . . . 9 1.3.1. RPC and Security . . . . . . . . . . . . . . . . . . 10
1.3.2. Procedure and Operation Structure . . . . . . . . . 9 1.3.2. Procedure and Operation Structure . . . . . . . . . 10
1.3.3. Filesystem Model . . . . . . . . . . . . . . . . . . 10 1.3.3. Filesystem Model . . . . . . . . . . . . . . . . . . 11
1.3.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 12 1.3.4. OPEN and CLOSE . . . . . . . . . . . . . . . . . . . 13
1.3.5. File Locking . . . . . . . . . . . . . . . . . . . . 12 1.3.5. File Locking . . . . . . . . . . . . . . . . . . . . 13
1.3.6. Client Caching and Delegation . . . . . . . . . . . 12 1.3.6. Client Caching and Delegation . . . . . . . . . . . 13
1.4. General Definitions . . . . . . . . . . . . . . . . . . 13 1.4. General Definitions . . . . . . . . . . . . . . . . . . 14
1.5. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 15 1.5. Changes since RFC 3530 . . . . . . . . . . . . . . . . . 16
1.6. Changes since RFC 3010 . . . . . . . . . . . . . . . . . 16 1.6. Changes since RFC 3010 . . . . . . . . . . . . . . . . . 17
2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 17 2. Protocol Data Types . . . . . . . . . . . . . . . . . . . . . 18
2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 17 2.1. Basic Data Types . . . . . . . . . . . . . . . . . . . . 18
2.2. Structured Data Types . . . . . . . . . . . . . . . . . 19 2.2. Structured Data Types . . . . . . . . . . . . . . . . . 20
3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 23 3. RPC and Security Flavor . . . . . . . . . . . . . . . . . . . 24
3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 23 3.1. Ports and Transports . . . . . . . . . . . . . . . . . . 24
3.1.1. Client Retransmission Behavior . . . . . . . . . . . 24 3.1.1. Client Retransmission Behavior . . . . . . . . . . . 25
3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 25 3.2. Security Flavors . . . . . . . . . . . . . . . . . . . . 26
3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . 25 3.2.1. Security mechanisms for NFSv4 . . . . . . . . . . . 26
3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 26 3.3. Security Negotiation . . . . . . . . . . . . . . . . . . 27
3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . 27 3.3.1. SECINFO . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 27 3.3.2. Security Error . . . . . . . . . . . . . . . . . . . 28
3.3.3. Callback RPC Authentication . . . . . . . . . . . . 27 3.3.3. Callback RPC Authentication . . . . . . . . . . . . 28
4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 28 4. Filehandles . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 28 4.1. Obtaining the First Filehandle . . . . . . . . . . . . . 29
4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 29 4.1.1. Root Filehandle . . . . . . . . . . . . . . . . . . 30
4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 29 4.1.2. Public Filehandle . . . . . . . . . . . . . . . . . 30
4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 30 4.2. Filehandle Types . . . . . . . . . . . . . . . . . . . . 31
4.2.1. General Properties of a Filehandle . . . . . . . . . 30 4.2.1. General Properties of a Filehandle . . . . . . . . . 31
4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 31 4.2.2. Persistent Filehandle . . . . . . . . . . . . . . . 32
4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 31 4.2.3. Volatile Filehandle . . . . . . . . . . . . . . . . 32
4.2.4. One Method of Constructing a Volatile Filehandle . . 32 4.2.4. One Method of Constructing a Volatile Filehandle . . 33
4.3. Client Recovery from Filehandle Expiration . . . . . . . 33 4.3. Client Recovery from Filehandle Expiration . . . . . . . 34
5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 34 5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 35 5.1. REQUIRED Attributes . . . . . . . . . . . . . . . . . . 36
5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 35 5.2. RECOMMENDED Attributes . . . . . . . . . . . . . . . . . 36
5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 36 5.3. Named Attributes . . . . . . . . . . . . . . . . . . . . 37
5.4. Classification of Attributes . . . . . . . . . . . . . . 37 5.4. Classification of Attributes . . . . . . . . . . . . . . 38
5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 38 5.5. Set-Only and Get-Only Attributes . . . . . . . . . . . . 39
5.6. REQUIRED Attributes - List and Definition References . . 38 5.6. REQUIRED Attributes - List and Definition References . . 39
5.7. RECOMMENDED Attributes - List and Definition 5.7. RECOMMENDED Attributes - List and Definition
References . . . . . . . . . . . . . . . . . . . . . . . 39 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 5.8.2. Definitions of Uncategorized RECOMMENDED
Attributes . . . . . . . . . . . . . . . . . . . . . 42 Attributes . . . . . . . . . . . . . . . . . . . . . 43
5.9. Interpreting owner and owner_group . . . . . . . . . . . 48 5.9. Interpreting owner and owner_group . . . . . . . . . . . 49
5.10. Character Case Attributes . . . . . . . . . . . . . . . 51 5.10. Character Case Attributes . . . . . . . . . . . . . . . 52
6. Access Control Attributes . . . . . . . . . . . . . . . . . . 51 6. Access Control Attributes . . . . . . . . . . . . . . . . . . 52
6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2. File Attributes Discussion . . . . . . . . . . . . . . . 52 6.2. File Attributes Discussion . . . . . . . . . . . . . . . 53
6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 52 6.2.1. Attribute 12: acl . . . . . . . . . . . . . . . . . 53
6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 67 6.2.2. Attribute 33: mode . . . . . . . . . . . . . . . . . 68
6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 67 6.3. Common Methods . . . . . . . . . . . . . . . . . . . . . 68
6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 67 6.3.1. Interpreting an ACL . . . . . . . . . . . . . . . . 68
6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 68 6.3.2. Computing a Mode Attribute from an ACL . . . . . . . 69
6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 69 6.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 70
6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 70 6.4.1. Setting the mode and/or ACL Attributes . . . . . . . 71
6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 71 6.4.2. Retrieving the mode and/or ACL Attributes . . . . . 72
6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 71 6.4.3. Creating New Objects . . . . . . . . . . . . . . . . 72
7. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 73 7. NFS Server Name Space . . . . . . . . . . . . . . . . . . . . 74
7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 73 7.1. Server Exports . . . . . . . . . . . . . . . . . . . . . 74
7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 73 7.2. Browsing Exports . . . . . . . . . . . . . . . . . . . . 74
7.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 74 7.3. Server Pseudo Filesystem . . . . . . . . . . . . . . . . 75
7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 74 7.4. Multiple Roots . . . . . . . . . . . . . . . . . . . . . 75
7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 75 7.5. Filehandle Volatility . . . . . . . . . . . . . . . . . 76
7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 75 7.6. Exported Root . . . . . . . . . . . . . . . . . . . . . 76
7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 75 7.7. Mount Point Crossing . . . . . . . . . . . . . . . . . . 76
7.8. Security Policy and Name Space Presentation . . . . . . 76 7.8. Security Policy and Name Space Presentation . . . . . . 77
8. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 76 8. Multi-Server Namespace . . . . . . . . . . . . . . . . . . . 77
8.1. Location Attributes . . . . . . . . . . . . . . . . . . 77 8.1. Location Attributes . . . . . . . . . . . . . . . . . . 78
8.2. File System Presence or Absence . . . . . . . . . . . . 77 8.2. File System Presence or Absence . . . . . . . . . . . . 78
8.3. Getting Attributes for an Absent File System . . . . . . 78 8.3. Getting Attributes for an Absent File System . . . . . . 79
8.3.1. GETATTR Within an Absent File System . . . . . . . . 78 8.3.1. GETATTR Within an Absent File System . . . . . . . . 79
8.3.2. READDIR and Absent File Systems . . . . . . . . . . 79 8.3.2. READDIR and Absent File Systems . . . . . . . . . . 80
8.4. Uses of Location Information . . . . . . . . . . . . . . 80 8.4. Uses of Location Information . . . . . . . . . . . . . . 81
8.4.1. File System Replication . . . . . . . . . . . . . . 81 8.4.1. File System Replication . . . . . . . . . . . . . . 82
8.4.2. File System Migration . . . . . . . . . . . . . . . 81 8.4.2. File System Migration . . . . . . . . . . . . . . . 82
8.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 82 8.4.3. Referrals . . . . . . . . . . . . . . . . . . . . . 83
8.5. Location Entries and Server Identity . . . . . . . . . . 83 8.5. Location Entries and Server Identity . . . . . . . . . . 84
8.6. Additional Client-Side Considerations . . . . . . . . . 83 8.6. Additional Client-Side Considerations . . . . . . . . . 84
8.7. Effecting File System Referrals . . . . . . . . . . . . 84 8.7. Effecting File System Referrals . . . . . . . . . . . . 85
8.7.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 85 8.7.1. Referral Example (LOOKUP) . . . . . . . . . . . . . 86
8.7.2. Referral Example (READDIR) . . . . . . . . . . . . . 89 8.7.2. Referral Example (READDIR) . . . . . . . . . . . . . 90
8.8. The Attribute fs_locations . . . . . . . . . . . . . . . 91 8.8. The Attribute fs_locations . . . . . . . . . . . . . . . 92
8.8.1. Inferring Transition Modes . . . . . . . . . . . . . 93 8.8.1. Inferring Transition Modes . . . . . . . . . . . . . 94
9. File Locking and Share Reservations . . . . . . . . . . . . . 94 9. File Locking and Share Reservations . . . . . . . . . . . . . 95
9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 95 9.1. Opens and Byte-Range Locks . . . . . . . . . . . . . . . 96
9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 96 9.1.1. Client ID . . . . . . . . . . . . . . . . . . . . . 97
9.1.2. Server Release of Client ID . . . . . . . . . . . . 99 9.1.2. Server Release of Client ID . . . . . . . . . . . . 100
9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 99 9.1.3. Stateid Definition . . . . . . . . . . . . . . . . . 100
9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 105 9.1.4. lock-owner . . . . . . . . . . . . . . . . . . . . . 106
9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 106 9.1.5. Use of the Stateid and Locking . . . . . . . . . . . 107
9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 108 9.1.6. Sequencing of Lock Requests . . . . . . . . . . . . 109
9.1.7. Recovery from Replayed Requests . . . . . . . . . . 109 9.1.7. Recovery from Replayed Requests . . . . . . . . . . 110
9.1.8. Interactions of multiple sequence values . . . . . . 109 9.1.8. Interactions of multiple sequence values . . . . . . 110
9.1.9. Releasing state-owner State . . . . . . . . . . . . 110 9.1.9. Releasing state-owner State . . . . . . . . . . . . 111
9.1.10. Use of Open Confirmation . . . . . . . . . . . . . . 111 9.1.10. Use of Open Confirmation . . . . . . . . . . . . . . 112
9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 112 9.2. Lock Ranges . . . . . . . . . . . . . . . . . . . . . . 113
9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 113 9.3. Upgrading and Downgrading Locks . . . . . . . . . . . . 114
9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 113 9.4. Blocking Locks . . . . . . . . . . . . . . . . . . . . . 114
9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 114 9.5. Lease Renewal . . . . . . . . . . . . . . . . . . . . . 115
9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 115 9.6. Crash Recovery . . . . . . . . . . . . . . . . . . . . . 116
9.6.1. Client Failure and Recovery . . . . . . . . . . . . 115 9.6.1. Client Failure and Recovery . . . . . . . . . . . . 116
9.6.2. Server Failure and Recovery . . . . . . . . . . . . 116 9.6.2. Server Failure and Recovery . . . . . . . . . . . . 117
9.6.3. Network Partitions and Recovery . . . . . . . . . . 117 9.6.3. Network Partitions and Recovery . . . . . . . . . . 118
9.7. Recovery from a Lock Request Timeout or Abort . . . . . 125 9.7. Recovery from a Lock Request Timeout or Abort . . . . . 126
9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 125 9.8. Server Revocation of Locks . . . . . . . . . . . . . . . 126
9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 127 9.9. Share Reservations . . . . . . . . . . . . . . . . . . . 128
9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 127 9.10. OPEN/CLOSE Operations . . . . . . . . . . . . . . . . . 128
9.10.1. Close and Retention of State Information . . . . . . 128 9.10.1. Close and Retention of State Information . . . . . . 129
9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 129 9.11. Open Upgrade and Downgrade . . . . . . . . . . . . . . . 130
9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 130 9.12. Short and Long Leases . . . . . . . . . . . . . . . . . 131
9.13. Clocks, Propagation Delay, and Calculating Lease 9.13. Clocks, Propagation Delay, and Calculating Lease
Expiration . . . . . . . . . . . . . . . . . . . . . . . 130 Expiration . . . . . . . . . . . . . . . . . . . . . . . 131
9.14. Migration, Replication and State . . . . . . . . . . . . 131 9.14. Migration, Replication and State . . . . . . . . . . . . 132
9.14.1. Migration and State . . . . . . . . . . . . . . . . 131 9.14.1. Migration and State . . . . . . . . . . . . . . . . 132
9.14.2. Replication and State . . . . . . . . . . . . . . . 132 9.14.2. Replication and State . . . . . . . . . . . . . . . 133
9.14.3. Notification of Migrated Lease . . . . . . . . . . . 132 9.14.3. Notification of Migrated Lease . . . . . . . . . . . 133
9.14.4. Migration and the Lease_time Attribute . . . . . . . 133 9.14.4. Migration and the Lease_time Attribute . . . . . . . 134
10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 134 10. Client-Side Caching . . . . . . . . . . . . . . . . . . . . . 135
10.1. Performance Challenges for Client-Side Caching . . . . . 134 10.1. Performance Challenges for Client-Side Caching . . . . . 135
10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 135 10.2. Delegation and Callbacks . . . . . . . . . . . . . . . . 136
10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 137 10.2.1. Delegation Recovery . . . . . . . . . . . . . . . . 138
10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 141 10.3. Data Caching . . . . . . . . . . . . . . . . . . . . . . 142
10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 142 10.3.1. Data Caching and OPENs . . . . . . . . . . . . . . . 143
10.3.2. Data Caching and File Locking . . . . . . . . . . . 143 10.3.2. Data Caching and File Locking . . . . . . . . . . . 144
10.3.3. Data Caching and Mandatory File Locking . . . . . . 144 10.3.3. Data Caching and Mandatory File Locking . . . . . . 145
10.3.4. Data Caching and File Identity . . . . . . . . . . . 145 10.3.4. Data Caching and File Identity . . . . . . . . . . . 146
10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 146 10.4. Open Delegation . . . . . . . . . . . . . . . . . . . . 147
10.4.1. Open Delegation and Data Caching . . . . . . . . . . 148 10.4.1. Open Delegation and Data Caching . . . . . . . . . . 149
10.4.2. Open Delegation and File Locks . . . . . . . . . . . 149 10.4.2. Open Delegation and File Locks . . . . . . . . . . . 150
10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 150 10.4.3. Handling of CB_GETATTR . . . . . . . . . . . . . . . 151
10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 153 10.4.4. Recall of Open Delegation . . . . . . . . . . . . . 154
10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 155 10.4.5. OPEN Delegation Race with CB_RECALL . . . . . . . . 156
10.4.6. Clients that Fail to Honor Delegation Recalls . . . 155 10.4.6. Clients that Fail to Honor Delegation Recalls . . . 156
10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 156 10.4.7. Delegation Revocation . . . . . . . . . . . . . . . 157
10.5. Data Caching and Revocation . . . . . . . . . . . . . . 157 10.5. Data Caching and Revocation . . . . . . . . . . . . . . 158
10.5.1. Revocation Recovery for Write Open Delegation . . . 157 10.5.1. Revocation Recovery for Write Open Delegation . . . 158
10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 158 10.6. Attribute Caching . . . . . . . . . . . . . . . . . . . 159
10.7. Data and Metadata Caching and Memory Mapped Files . . . 160 10.7. Data and Metadata Caching and Memory Mapped Files . . . 161
10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 162 10.8. Name Caching . . . . . . . . . . . . . . . . . . . . . . 163
10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 163 10.9. Directory Caching . . . . . . . . . . . . . . . . . . . 164
11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 164 11. Minor Versioning . . . . . . . . . . . . . . . . . . . . . . 165
12. Internationalization . . . . . . . . . . . . . . . . . . . . 167 12. Internationalization . . . . . . . . . . . . . . . . . . . . 168
12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 167 12.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 168
12.2. String Encoding . . . . . . . . . . . . . . . . . . . . 167 12.2. String Encoding . . . . . . . . . . . . . . . . . . . . 169
12.3. Normalization . . . . . . . . . . . . . . . . . . . . . 168 12.3. Normalization . . . . . . . . . . . . . . . . . . . . . 169
12.4. Types with Processing Defined by Other Internet Areas . 168 12.4. Types with Processing Defined by Other Internet Areas . 170
12.5. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 169 12.5. UTF-8 Related Errors . . . . . . . . . . . . . . . . . . 171
13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 170 12.6. Handling of component names that are not valid UTF-8
13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 170 strings . . . . . . . . . . . . . . . . . . . . . . . . 172
13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 172 13. Error Values . . . . . . . . . . . . . . . . . . . . . . . . 173
13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 173 13.1. Error Definitions . . . . . . . . . . . . . . . . . . . 173
13.1.3. Compound Structure Errors . . . . . . . . . . . . . 174 13.1.1. General Errors . . . . . . . . . . . . . . . . . . . 175
13.1.4. File System Errors . . . . . . . . . . . . . . . . . 175 13.1.2. Filehandle Errors . . . . . . . . . . . . . . . . . 176
13.1.5. State Management Errors . . . . . . . . . . . . . . 177 13.1.3. Compound Structure Errors . . . . . . . . . . . . . 177
13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 178 13.1.4. File System Errors . . . . . . . . . . . . . . . . . 178
13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 179 13.1.5. State Management Errors . . . . . . . . . . . . . . 180
13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 179 13.1.6. Security Errors . . . . . . . . . . . . . . . . . . 181
13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 181 13.1.7. Name Errors . . . . . . . . . . . . . . . . . . . . 182
13.1.10. Client Management Errors . . . . . . . . . . . . . . 181 13.1.8. Locking Errors . . . . . . . . . . . . . . . . . . . 182
13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 182 13.1.9. Reclaim Errors . . . . . . . . . . . . . . . . . . . 184
13.2. Operations and their valid errors . . . . . . . . . . . 182 13.1.10. Client Management Errors . . . . . . . . . . . . . . 184
13.3. Callback operations and their valid errors . . . . . . . 189 13.1.11. Attribute Handling Errors . . . . . . . . . . . . . 185
13.4. Errors and the operations that use them . . . . . . . . 190 13.2. Operations and their valid errors . . . . . . . . . . . 185
14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 194 13.3. Callback operations and their valid errors . . . . . . . 192
14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 195 13.4. Errors and the operations that use them . . . . . . . . 193
14.2. Evaluation of a Compound Request . . . . . . . . . . . . 195 14. NFSv4 Requests . . . . . . . . . . . . . . . . . . . . . . . 197
14.3. Synchronous Modifying Operations . . . . . . . . . . . . 196 14.1. Compound Procedure . . . . . . . . . . . . . . . . . . . 198
14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 196 14.2. Evaluation of a Compound Request . . . . . . . . . . . . 198
15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 197 14.3. Synchronous Modifying Operations . . . . . . . . . . . . 199
15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 197 14.4. Operation Values . . . . . . . . . . . . . . . . . . . . 199
15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 197 15. NFSv4 Procedures . . . . . . . . . . . . . . . . . . . . . . 200
15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 201 15.1. Procedure 0: NULL - No Operation . . . . . . . . . . . . 200
15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 204 15.2. Procedure 1: COMPOUND - Compound Operations . . . . . . 200
15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 205 15.3. Operation 3: ACCESS - Check Access Rights . . . . . . . 204
15.6. Operation 6: CREATE - Create a Non-Regular File Object . 207 15.4. Operation 4: CLOSE - Close File . . . . . . . . . . . . 207
15.5. Operation 5: COMMIT - Commit Cached Data . . . . . . . . 208
15.6. Operation 6: CREATE - Create a Non-Regular File Object . 210
15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting 15.7. Operation 7: DELEGPURGE - Purge Delegations Awaiting
Recovery . . . . . . . . . . . . . . . . . . . . . . . . 210 Recovery . . . . . . . . . . . . . . . . . . . . . . . . 213
15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 211 15.8. Operation 8: DELEGRETURN - Return Delegation . . . . . . 214
15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 212 15.9. Operation 9: GETATTR - Get Attributes . . . . . . . . . 215
15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 214 15.10. Operation 10: GETFH - Get Current Filehandle . . . . . . 217
15.11. Operation 11: LINK - Create Link to a File . . . . . . . 215 15.11. Operation 11: LINK - Create Link to a File . . . . . . . 218
15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 216 15.12. Operation 12: LOCK - Create Lock . . . . . . . . . . . . 219
15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 220 15.13. Operation 13: LOCKT - Test For Lock . . . . . . . . . . 223
15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 222 15.14. Operation 14: LOCKU - Unlock File . . . . . . . . . . . 225
15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 223 15.15. Operation 15: LOOKUP - Lookup Filename . . . . . . . . . 226
15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 225 15.16. Operation 16: LOOKUPP - Lookup Parent Directory . . . . 228
15.17. Operation 17: NVERIFY - Verify Difference in 15.17. Operation 17: NVERIFY - Verify Difference in
Attributes . . . . . . . . . . . . . . . . . . . . . . . 226 Attributes . . . . . . . . . . . . . . . . . . . . . . . 229
15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 227 15.18. Operation 18: OPEN - Open a Regular File . . . . . . . . 230
15.19. Operation 19: OPENATTR - Open Named Attribute 15.19. Operation 19: OPENATTR - Open Named Attribute
Directory . . . . . . . . . . . . . . . . . . . . . . . 237 Directory . . . . . . . . . . . . . . . . . . . . . . . 240
15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 238 15.20. Operation 20: OPEN_CONFIRM - Confirm Open . . . . . . . 241
15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 240 15.21. Operation 21: OPEN_DOWNGRADE - Reduce Open File Access . 243
15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 241 15.22. Operation 22: PUTFH - Set Current Filehandle . . . . . . 244
15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 242 15.23. Operation 23: PUTPUBFH - Set Public Filehandle . . . . . 245
15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 243 15.24. Operation 24: PUTROOTFH - Set Root Filehandle . . . . . 246
15.25. Operation 25: READ - Read from File . . . . . . . . . . 244 15.25. Operation 25: READ - Read from File . . . . . . . . . . 247
15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 246 15.26. Operation 26: READDIR - Read Directory . . . . . . . . . 249
15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 250 15.27. Operation 27: READLINK - Read Symbolic Link . . . . . . 253
15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 251 15.28. Operation 28: REMOVE - Remove Filesystem Object . . . . 254
15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 253 15.29. Operation 29: RENAME - Rename Directory Entry . . . . . 256
15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 255 15.30. Operation 30: RENEW - Renew a Lease . . . . . . . . . . 258
15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 256 15.31. Operation 31: RESTOREFH - Restore Saved Filehandle . . . 259
15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 257 15.32. Operation 32: SAVEFH - Save Current Filehandle . . . . . 260
15.33. Operation 33: SECINFO - Obtain Available Security . . . 258 15.33. Operation 33: SECINFO - Obtain Available Security . . . 261
15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 262 15.34. Operation 34: SETATTR - Set Attributes . . . . . . . . . 265
15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 264 15.35. Operation 35: SETCLIENTID - Negotiate Client ID . . . . 267
15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 268 15.36. Operation 36: SETCLIENTID_CONFIRM - Confirm Client ID . 271
15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 271 15.37. Operation 37: VERIFY - Verify Same Attributes . . . . . 274
15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 273 15.38. Operation 38: WRITE - Write to File . . . . . . . . . . 276
15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner 15.39. Operation 39: RELEASE_LOCKOWNER - Release Lockowner
State . . . . . . . . . . . . . . . . . . . . . . . . . 277 State . . . . . . . . . . . . . . . . . . . . . . . . . 280
15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 278 15.40. Operation 10044: ILLEGAL - Illegal operation . . . . . . 281
16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 279 16. NFSv4 Callback Procedures . . . . . . . . . . . . . . . . . . 282
16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 279 16.1. Procedure 0: CB_NULL - No Operation . . . . . . . . . . 282
16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 279 16.2. Procedure 1: CB_COMPOUND - Compound Operations . . . . . 282
16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 281 16.2.6. Operation 3: CB_GETATTR - Get Attributes . . . . . . 284
16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 282 16.2.7. Operation 4: CB_RECALL - Recall an Open Delegation . 285
16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback 16.2.8. Operation 10044: CB_ILLEGAL - Illegal Callback
Operation . . . . . . . . . . . . . . . . . . . . . 283 Operation . . . . . . . . . . . . . . . . . . . . . 286
17. Security Considerations . . . . . . . . . . . . . . . . . . . 284 17. Security Considerations . . . . . . . . . . . . . . . . . . . 287
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 286 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 289
18.1. Named Attribute Definitions . . . . . . . . . . . . . . 286 18.1. Named Attribute Definitions . . . . . . . . . . . . . . 289
18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 287 18.1.1. Initial Registry . . . . . . . . . . . . . . . . . . 290
18.1.2. Updating Registrations . . . . . . . . . . . . . . . 287 18.1.2. Updating Registrations . . . . . . . . . . . . . . . 290
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 287 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 290
19.1. Normative References . . . . . . . . . . . . . . . . . . 287 19.1. Normative References . . . . . . . . . . . . . . . . . . 290
19.2. Informative References . . . . . . . . . . . . . . . . . 288 19.2. Informative References . . . . . . . . . . . . . . . . . 291
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 291 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 294
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 292 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 295
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 292 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 295
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 18, line 9 skipping to change at page 19, line 9
| nfs_ftype4 | enum nfs_ftype4; | | nfs_ftype4 | enum nfs_ftype4; |
| | Various defined file types. | | | Various defined file types. |
| nfsstat4 | enum nfsstat4; | | nfsstat4 | enum nfsstat4; |
| | Return value for operations. | | | Return value for operations. |
| offset4 | typedef uint64_t offset4; | | offset4 | typedef uint64_t offset4; |
| | Various offset designations (READ, WRITE, LOCK, | | | Various offset designations (READ, WRITE, LOCK, |
| | COMMIT). | | | COMMIT). |
| qop4 | typedef uint32_t qop4; | | qop4 | typedef uint32_t qop4; |
| | Quality of protection designation in SECINFO. | | | Quality of protection designation in SECINFO. |
| sec_oid4 | typedef opaque sec_oid4<>; | | sec_oid4 | typedef opaque sec_oid4<>; |
| | Security Object Identifier. The sec_oid4 data | | | Security Object Identifier. The sec_oid4 data |
| | 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 utf8str_cs 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 39, line 31 skipping to change at page 40, line 31
+-----------------+----+------------+-----+------------------+ +-----------------+----+------------+-----+------------------+
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.
+-------------------+----+--------------+-----+------------------+ +-------------------+----+-----------------+-----+------------------+
| Name | Id | Data Type | Acc | Defined in: | | Name | Id | Data Type | Acc | Defined in: |
+-------------------+----+--------------+-----+------------------+ +-------------------+----+-----------------+-----+------------------+
| acl | 12 | nfsace4<> | R W | Section 6.2.1 | | acl | 12 | nfsace4<> | R W | Section 6.2.1 |
| aclsupport | 13 | uint32_t | R | Section 6.2.1.2 | | aclsupport | 13 | uint32_t | R | Section 6.2.1.2 |
| archive | 14 | bool | R W | Section 5.8.2.1 | | archive | 14 | bool | R W | Section 5.8.2.1 |
| cansettime | 15 | bool | R | Section 5.8.2.2 | | cansettime | 15 | bool | R | Section 5.8.2.2 |
| case_insensitive | 16 | bool | R | Section 5.8.2.3 | | case_insensitive | 16 | bool | R | Section 5.8.2.3 |
| case_preserving | 17 | bool | R | Section 5.8.2.4 | | case_preserving | 17 | bool | R | Section 5.8.2.4 |
| chown_restricted | 18 | bool | R | Section 5.8.2.5 | | chown_restricted | 18 | bool | R | Section 5.8.2.5 |
| fileid | 20 | uint64_t | R | Section 5.8.2.6 | | fileid | 20 | uint64_t | R | Section 5.8.2.6 |
| files_avail | 21 | uint64_t | R | Section 5.8.2.7 | | files_avail | 21 | uint64_t | R | Section 5.8.2.7 |
| files_free | 22 | uint64_t | R | Section 5.8.2.8 | | files_free | 22 | uint64_t | R | Section 5.8.2.8 |
| files_total | 23 | uint64_t | R | Section 5.8.2.9 | | files_total | 23 | uint64_t | R | Section 5.8.2.9 |
| fs_locations | 24 | fs_locations | R | Section 5.8.2.10 | | fs_locations | 24 | fs_locations | R | Section 5.8.2.10 |
| hidden | 25 | bool | R W | Section 5.8.2.11 | | hidden | 25 | bool | R W | Section 5.8.2.11 |
| homogeneous | 26 | bool | R | Section 5.8.2.12 | | homogeneous | 26 | bool | R | Section 5.8.2.12 |
| maxfilesize | 27 | uint64_t | R | Section 5.8.2.13 | | maxfilesize | 27 | uint64_t | R | Section 5.8.2.13 |
| maxlink | 28 | uint32_t | R | Section 5.8.2.14 | | maxlink | 28 | uint32_t | R | Section 5.8.2.14 |
| maxname | 29 | uint32_t | R | Section 5.8.2.15 | | maxname | 29 | uint32_t | R | Section 5.8.2.15 |
| maxread | 30 | uint64_t | R | Section 5.8.2.16 | | maxread | 30 | uint64_t | R | Section 5.8.2.16 |
| maxwrite | 31 | uint64_t | R | Section 5.8.2.17 | | maxwrite | 31 | uint64_t | R | Section 5.8.2.17 |
| mimetype | 32 | utf8<> | R W | Section 5.8.2.18 | | mimetype | 32 | ascii_ | R W | Section 5.8.2.18 |
| mode | 33 | mode4 | R W | Section 6.2.2 | | | | REQUIRED4<> | | |
| mounted_on_fileid | 55 | uint64_t | R | Section 5.8.2.19 | | mode | 33 | mode4 | R W | Section 6.2.2 |
| no_trunc | 34 | bool | R | Section 5.8.2.20 | | mounted_on_fileid | 55 | uint64_t | R | Section 5.8.2.19 |
| numlinks | 35 | uint32_t | R | Section 5.8.2.21 | | no_trunc | 34 | bool | R | Section 5.8.2.20 |
| owner | 36 | utf8<> | R W | Section 5.8.2.22 | | numlinks | 35 | uint32_t | R | Section 5.8.2.21 |
| owner_group | 37 | utf8<> | R W | Section 5.8.2.23 | | owner | 36 | utf8<> | R W | Section 5.8.2.22 |
| quota_avail_hard | 38 | uint64_t | R | Section 5.8.2.24 | | owner_group | 37 | utf8<> | R W | Section 5.8.2.23 |
| quota_avail_soft | 39 | uint64_t | R | Section 5.8.2.25 | | quota_avail_hard | 38 | uint64_t | R | Section 5.8.2.24 |
| quota_used | 40 | uint64_t | R | Section 5.8.2.26 | | quota_avail_soft | 39 | uint64_t | R | Section 5.8.2.25 |
| rawdev | 41 | specdata4 | R | Section 5.8.2.27 | | quota_used | 40 | uint64_t | R | Section 5.8.2.26 |
| space_avail | 42 | uint64_t | R | Section 5.8.2.28 | | rawdev | 41 | specdata4 | R | Section 5.8.2.27 |
| space_free | 43 | uint64_t | R | Section 5.8.2.29 | | space_avail | 42 | uint64_t | R | Section 5.8.2.28 |
| space_total | 44 | uint64_t | R | Section 5.8.2.30 | | space_free | 43 | uint64_t | R | Section 5.8.2.29 |
| space_used | 45 | uint64_t | R | Section 5.8.2.31 | | space_total | 44 | uint64_t | R | Section 5.8.2.30 |
| system | 46 | bool | R W | Section 5.8.2.32 | | space_used | 45 | uint64_t | R | Section 5.8.2.31 |
| time_access | 47 | nfstime4 | R | Section 5.8.2.33 | | system | 46 | bool | R W | Section 5.8.2.32 |
| time_access_set | 48 | settime4 | W | Section 5.8.2.34 | | time_access | 47 | nfstime4 | R | Section 5.8.2.33 |
| time_backup | 49 | nfstime4 | R W | Section 5.8.2.35 | | time_access_set | 48 | settime4 | W | Section 5.8.2.34 |
| time_create | 50 | nfstime4 | R W | Section 5.8.2.36 | | time_backup | 49 | nfstime4 | R W | Section 5.8.2.35 |
| time_delta | 51 | nfstime4 | R | Section 5.8.2.37 | | time_create | 50 | nfstime4 | R W | Section 5.8.2.36 |
| time_metadata | 52 | nfstime4 | R | Section 5.8.2.38 | | time_delta | 51 | nfstime4 | R | Section 5.8.2.37 |
| time_modify | 53 | nfstime4 | R | Section 5.8.2.39 | | time_metadata | 52 | nfstime4 | R | Section 5.8.2.38 |
| time_modify_set | 54 | settime4 | W | Section 5.8.2.40 | | time_modify | 53 | nfstime4 | R | Section 5.8.2.39 |
+-------------------+----+--------------+-----+------------------+ | 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
skipping to change at page 50, line 20 skipping to change at page 51, line 20
server should be the value used for the "dns_domain". server should be the value used for the "dns_domain".
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 equivalent o The string representing the domain may be converted to equivalent
U-label (see [RFC5890]), if presented using a form other than a a U-label (see [RFC5890]), if presented using a form other than a
U-label. See Section 12.4 for details. U-label. See Section 12.4 for details.
o The user or group may be returned in a different form, due to o The user or group may be returned in a different form, due to
normalization issues, although it will always be a canonically normalization issues, although it will always be a canonically
equivalent string. equivalent string.
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
skipping to change at page 52, line 47 skipping to change at page 53, line 47
(ACEs) that are associated with the file system object. Although the (ACEs) that are associated with the file system object. Although the
client can read and write the acl attribute, the server is client can read and write the acl attribute, the server is
responsible for using the ACL to perform access control. The client responsible for using the ACL to perform access control. The client
can use the OPEN or ACCESS operations to check access without can use the OPEN or ACCESS operations to check access without
modifying or reading data or metadata. modifying or reading data or metadata.
The NFS ACE structure is defined as follows: The NFS ACE structure is defined as follows:
typedef uint32_t acetype4; typedef uint32_t acetype4;
typedef uint32_t aceflag4; typedef uint32_t aceflag4;
typedef uint32_t acemask4; typedef uint32_t acemask4;
struct nfsace4 { struct nfsace4 {
acetype4 type; acetype4 type;
aceflag4 flag; aceflag4 flag;
acemask4 access_mask; acemask4 access_mask;
utf8str_mixed who; utf8str_mixed who;
}; };
To determine if a request succeeds, the server processes each nfsace4 To determine if a request succeeds, the server processes each nfsace4
skipping to change at page 73, line 40 skipping to change at page 74, line 40
7.1. Server Exports 7.1. Server Exports
On a UNIX server the name space describes all the files reachable by On a UNIX server the name space describes all the files reachable by
pathnames under the root directory or "/". On a Windows NT server pathnames under the root directory or "/". On a Windows NT server
the name space constitutes all the files on disks named by mapped the name space constitutes all the files on disks named by mapped
disk letters. NFS server administrators rarely make the entire disk letters. NFS server administrators rarely make the entire
server's file system name space available to NFS clients. More often server's file system name space available to NFS clients. More often
portions of the name space are made available via an "export" portions of the name space are made available via an "export"
feature. In previous versions of the NFS protocol, the root feature. In previous versions of the NFS protocol, the root
filehandle for each export is obtained through the MOUNT protocol; filehandle for each export is obtained through the MOUNT protocol;
the client sends a string that identifies the export of name space the client sends a string that identifies an object in the exported
and the server returns the root filehandle for it. The MOUNT name space and the server returns the root filehandle for it. The
protocol supports an EXPORTS procedure that will enumerate the MOUNT protocol supports an EXPORTS procedure that will enumerate the
server's exports. server's exports.
7.2. Browsing Exports 7.2. Browsing Exports
The NFSv4 protocol provides a root filehandle that clients can use to The NFSv4 protocol provides a root filehandle that clients can use to
obtain filehandles for these exports via a multi-component LOOKUP. A obtain filehandles for these exports via a multi-component LOOKUP. A
common user experience is to use a graphical user interface (perhaps common user experience is to use a graphical user interface (perhaps
a file "Open" dialog window) to find a file via progressive browsing a file "Open" dialog window) to find a file via progressive browsing
through a directory tree. The client must be able to move from one through a directory tree. The client must be able to move from one
export to another export via single-component, progressive LOOKUP export to another export via single-component, progressive LOOKUP
skipping to change at page 75, line 24 skipping to change at page 76, line 24
pseudo file system, the NFS client should expect that pseudo file pseudo file system, the NFS client should expect that pseudo file
system filehandles are volatile. This can be confirmed by checking system filehandles are volatile. This can be confirmed by checking
the associated "fh_expire_type" attribute for those filehandles in the associated "fh_expire_type" attribute for those filehandles in
question. If the filehandles are volatile, the NFS client must be question. If the filehandles are volatile, the NFS client must be
prepared to recover a filehandle value (e.g., with a multi-component prepared to recover a filehandle value (e.g., with a multi-component
LOOKUP) when receiving an error of NFS4ERR_FHEXPIRED. LOOKUP) when receiving an error of NFS4ERR_FHEXPIRED.
7.6. Exported Root 7.6. Exported Root
If the server's root file system is exported, one might conclude that If the server's root file system is exported, one might conclude that
a pseudo-file system is not needed. This would be wrong. Assume the a pseudo file system is not needed. This would be wrong. Assume the
following file systems on a server: following file systems on a server:
/ disk1 (exported) / disk1 (exported)
/a disk2 (not exported) /a disk2 (not exported)
/a/b disk3 (exported) /a/b disk3 (exported)
Because disk2 is not exported, disk3 cannot be reached with simple Because disk2 is not exported, disk3 cannot be reached with simple
LOOKUPs. The server must bridge the gap with a pseudo-file system. LOOKUPs. The server must bridge the gap with a pseudo file system.
7.7. Mount Point Crossing 7.7. Mount Point Crossing
The server file system environment may be constructed in such a way The server file system environment may be constructed in such a way
that one file system contains a directory which is 'covered' or that one file system contains a directory which is 'covered' or
mounted upon by a second file system. For example: mounted upon by a second file system. For example:
/a/b (file system 1) /a/b (file system 1)
/a/b/c/d (file system 2) /a/b/c/d (file system 2)
skipping to change at page 167, line 9 skipping to change at page 168, line 9
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 describes NFSv4.0 internationalization as implemented by This section uses NFSv4.0 internationalization, as implemented by
existing clients and servers. As a result, the keywords "MUST", existing clients and servers, as the basis upon which NFSv4.0 clients
"SHOULD", and "MAY", even though they retain their normal meanings, may implement internationalization support. This procedure, while
reflect patterns of existing implementation: necessary, may result in confusion if we do not clearly understand
that we are mixing prescription and description, and why, in this
particular case, this is a valid thing to do.
Note that in this chapter, the keywords "MUST", "SHOULD", and "MAY",
retain their normal meanings. However, in deriving this
specification from implementation patterns, we document below how the
normative terms used derive from the behavior of existing
implementations.
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
existing ones to be assured of interoperability. existing ones to be assured of interoperability. While it is
possible that different behavior might be workable, we have found
no case where this seems reasonable.
o Behavior implemented by no existing clients or servers is o Behavior implemented by no existing clients or servers is
described using "MUST NOT", if such behavior poses described using "MUST NOT", if such behavior poses
interoperability problems. interoperability problems.
o Behavior implemented by most existing clients or servers, where o Behavior implemented by most existing clients or servers, where
that behavior is more desirable than any alternative is described that behavior is more desirable than any alternative is described
using "SHOULD", since new implementations need to follow that using "SHOULD", since new implementations need to follow that
existing practice unless there are strong reasons to do otherwise. existing practice unless there are strong reasons to do otherwise.
This also holds for "SHOULD NOT". This also holds for "SHOULD NOT".
o Behavior implemented by some not all existing clients or servers, o Behavior implemented by some not all existing clients or servers,
is described using "MAY", indicating that new implementations have is described using "MAY", indicating that new implementations have
a choice as to whether they will behave in that way. a choice as to whether they will behave in that way. Thus, new
implementations will have the same flexibility that existing ones
do.
o Behavior implemented by all existing clients or servers, so far as o Behavior implemented by all existing clients or servers, so far as
is known, but where there remains some uncertainty as to details is known, but where there remains some uncertainty as to details
is described using "should". Such cases primary concern details is described using "should". Such cases primarily concern details
of error returns. New implementations should follow existing of error returns. New implementations should follow existing
practice even though such situations generally do not affect practice even though such situations generally do not affect
interoperability. interoperability.
In the case of a MAY, SHOULD, or SHOULD NOT that applies to servers,
clients need to be aware that there are servers which may or may nlot
take the specified action, and they need to be prepared for either
eventuality.
12.2. String Encoding 12.2. String Encoding
Strings that potentially contain non-ASCII Characters are represented Strings that potentially contain non-ASCII Characters are represented
in NFSv4 using the UTF-8 encoding of Unicode. See [RFC2279] for in NFSv4 using the UTF-8 encoding of Unicode. See [RFC2279] for
precise encoding and decoding rules. 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 that are component names, any non-ASCII characters o For strings that are component names, any non-ASCII characters
MUST be represented using the UTF-8 encoding of Unicode. SHOULD be represented using the UTF-8 encoding of Unicode.
In many cases, clients have no knowledge of the encoding being
used, with the encoding done at user-level under control of a per-
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
encodings can be problematic since it may interfere with access to
files stored using encoding and because normalization-related
processing (see Section 12.3) would result in name aliasing in the
case of a non-UTF-8 encoding resulted characters strings that have
multiple equivalent Unicode encodings.
o For strings whose form is defined by other internet standards, o For strings whose form is defined by other internet standards,
non-ASCII characters MUST be represented using the UTF-8 encoding non-ASCII characters MUST be represented using the UTF-8 encoding
of Unicode. In addition other sorts of restrictions defined by of Unicode. In addition other sorts of restrictions defined by
those standards need to be addressed. See section 11.4 for those standards need to be addressed. See Section 12.4 for
details. details.
o The contents of symbolic links (of type linktext4 in the XDR) MUST
be treated as opaque data by NFSv4 servers. Although UTF-8
encoding is often used, it need not be. In this respect, the
contents of symbolic links are like the contents of regular files
in that their encoding is not within the scope of this
specification.
o For other sorts of strings, any non-ASCII characters SHOULD be o For other sorts of strings, any non-ASCII characters SHOULD be
represented using the UTF-8 encoding of Unicode. represented using the UTF-8 encoding of Unicode.
12.3. Normalization 12.3. Normalization
The client and server operating environments may differ in their The client and server operating environments may differ in their
policies and operational methods with respect to character policies and operational methods with respect to character
normalization (See [Unicode1] for a discussion of normalization normalization (See [Unicode1] for a discussion of normalization
forms). This difference may also exist between applications on the forms). This difference may also exist between applications on the
same client. This adds to the difficulty of providing a single same client. This adds to the difficulty of providing a single
skipping to change at page 168, line 38 skipping to change at page 170, line 25
unnormalized characters within protocol requests and responses. If unnormalized characters within protocol requests and responses. If
the operating environment requires normalization, then the the operating environment requires normalization, then the
implementation must normalize the various UTF-8 encoded strings implementation must normalize the various UTF-8 encoded strings
within the protocol before presenting the information to an within the protocol before presenting the information to an
application (at the client) or local file system (at the server). application (at the client) or local file system (at the server).
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. Servers MUST NOT reject a to match a particular normalization form. Except in cases in which
file name because it doesn't a conform to a particular normalization component names are excluded from normalization-related handling
form. 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
normalization and whether to do normalization-insensitive string
comparisons) in the same way for all accesses to a particular
filesystem. Servers MUST NOT reject a file name because it doesn't a
conform to a particular normalization form.
12.4. Types with Processing Defined by Other Internet Areas 12.4. Types with Processing Defined by Other Internet Areas
There are two types of strings which NFSv4 deals with whose There are two types of strings which NFSv4 deals with whose
processing is defined by other Internet standards, and where issues processing is defined by other Internet standards, and where issues
related to different handling choices by server operating systems or related to different handling choices by server operating systems or
server file systems do not apply. server file systems do not apply.
These are as follows: These are as follows:
o Server names as they appear in the fs_locations attribute. Note o Server names as they appear in the fs_locations attribute. Note
that for most purposes, such server names will only be sent by the that for most purposes, such server names will only be sent by the
server to the client. The exception is use of the fs_locations server to the client. The exception is use of the fs_locations
attribute in a VERIFY or NVERIFY operation. attribute in a VERIFY or NVERIFY operation.
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 role the 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 a U-label although it MAY be The string sent SHOULD be in the form of a U-label although it MAY be
in the form of an A-label or a UTF-8 string that would not map to in the form of an A-label or a UTF-8 string that would not map to
itself when canonicalized by applying ToUnicode(ToASCII(...)). The itself when canonicalized by applying ToUnicode(ToASCII(...)). The
receiver needs to be able to accept domain and server names in any of receiver needs to be able to accept domain and server names in any of
the formats allowed. The server MUST reject, using the error the formats allowed. The server MUST reject, using the error
NFS4ERR_INVAL, a string which is not valid UTF-8 or which begins with NFS4ERR_INVAL, a string which is not valid UTF-8 or which begins with
"xn--" and violates the rules for a valid A-label. "xn--" and violates the rules 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, the server
SHOULD map domain strings which are A-labels or are UTF-8 domain SHOULD map domain strings which are A-labels (see [RFC5890]) or are
names which are not U-labels, to the corresponding U-label, using UTF-8 domain names which are not U-labels, to the corresponding
ToUnicode(domain) or ToUnicode(ToASCII(domain)). As a result, the U-label, using ToUnicode(domain) or ToUnicode(ToASCII(domain)). As a
domain name returned within a userid on a GETATTR may not match that result, the domain name returned within a userid on a GETATTR may not
sent when the userid is set using SETATTR, although when this match that sent when the userid is set using SETATTR, although when
happens, the domain will be in the form of a U-label. When the this happens, the domain will be in the form of a U-label. When the
server does not map domain strings which are not U-labels into a 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 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 domain returned on a GETATTR of the userid MUST be the same as that
used when setting the userid by the SETATTR. used when setting the userid by the SETATTR.
The server MAY implement VERIFY and NVERIFY without translating The server MAY implement VERIFY and NVERIFY without translating
internal state to a string form, so that, for example, a user internal state to a string form, so that, for example, a user
principal which represents a specific numeric user id, will match a principal which represents a specific numeric user id, will match a
different principal string which represents the same numeric user id. different principal string which represents the same numeric user id.
12.5. UTF-8 Related Errors 12.5. UTF-8 Related Errors
Where the client sends an invalid UTF-8 string, the server SHOULD Where the client sends an invalid UTF-8 string, the server MAY return
return an NFS4ERR_INVAL error. This includes cases in which an NFS4ERR_INVAL error. This includes cases in which inappropriate
inappropriate prefixes are detected and where the count includes prefixes are detected and where the count includes trailing bytes
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
valid UTF-8, when a server does not return NFS4ERR_INVAL in response
to receiving these are described in Section 12.6.
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 characters that have value for that string (e.g., names containing slashes or characters
more than two octets on a file system that supports Unicode that have more than two octets on a filesystem that supports Unicode
characters only), the server should return an NFS4ERR_BADCHAR error. characters only), 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 situations in which the server error NFS4ERR_BADNAME. This includes such situations as file system
file system imposes a normalization constraint on name strings, but prohibitions of "." and ".." as file names for certain operations,
will also include such situations as file system prohibitions of "." and similar constraints
and ".." as file names for certain operations, and other such
constraints. 12.6. Handling of component names that are not valid UTF-8 strings
In cases in which the server receives a component name that is not a
valid UTF-8 string, the required handling depends on whether a file
object is being created or looked up. Object creation happens for
the component name in LINK and CREATE, and the second component name
in RENAME. Object lookup happens for the component name in LOOKUP
and REMOVE, and the first component name in RENAME. The component
name in OPEN will result in object lookup and also object creation if
the lookup fails and the other OPEN parameters allow file creation.
With regard to normalization-related processing, it is generally
inhibited, both in the case of object creation and object lookup:
o Characters which are not valid UTF-8, have no canonically
equivalent Unicode string so normalization-related processing
cannot happen.
o In cases in which a string has valid UTF-8 character strings that
do have canonically equivalent Unicode strings, but if the
component name is not valid UTF-8, the server MAY perform
normalization-related processing on valid UTF-8 substrings within
it that do have canonical equivalents.
When creation of a component name which is not valid UTF-8 occurs,
and is allowed by the server:
o A subsequent lookup of the same component name in the same
directory MUST result in finding the created file object.
o A READDIR of the directory in which the name is created MUST
result in an entry containing the component name used for the
creation.
o A subsequent lookup using any other string as the component name
SHOULD NOT find the originally created object.
o A subsequent lookup using any valid UTF-8 string MUST NOT find the
originally created object.
When a lookup of a component name which is not valid UTF-8 occurs,
and is allowed by the server:
o The result of the lookup MUST NOT be any directory entry created
with a valid UTF-8 component name.
o The result of the lookup MUST be a directory entry created with
the identical invalid UTF-8 string, if one exists in the
directory.
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 176, line 17 skipping to change at page 179, line 12
Filesystem object too large. The operation would have caused a file Filesystem object too large. The operation would have caused a file
system object to grow beyond the server's limit. system object to grow beyond the server's limit.
13.1.4.5. NFS4ERR_FILE_OPEN (Error Code 10046) 13.1.4.5. NFS4ERR_FILE_OPEN (Error Code 10046)
The operation is not allowed because a file system object involved in The operation is not allowed because a file system object involved in
the operation is currently open. Servers may, but are not required the operation is currently open. Servers may, but are not required
to disallow linking-to, removing, or renaming open file system to disallow linking-to, removing, or renaming open file system
objects. objects.
13.1.4.6. NFS4ERR_IO (Error Code 6) 13.1.4.6. NFS4ERR_IO (Error Code 5)
Indicates that an I/O error occurred for which the file system was Indicates that an I/O error occurred for which the file system was
unable to provide recovery. unable to provide recovery.
13.1.4.7. NFS4ERR_MLINK (Error Code 31) 13.1.4.7. NFS4ERR_MLINK (Error Code 31)
The request would have caused the server's limit for the number of The request would have caused the server's limit for the number of
hard links a file system object may have to be exceeded. hard links a file system object may have to be exceeded.
13.1.4.8. NFS4ERR_NOENT (Error Code 2) 13.1.4.8. NFS4ERR_NOENT (Error Code 2)
skipping to change at page 176, line 41 skipping to change at page 179, line 36
13.1.4.9. NFS4ERR_NOSPC (Error Code 28) 13.1.4.9. NFS4ERR_NOSPC (Error Code 28)
Indicates no space left on device. The operation would have caused Indicates no space left on device. The operation would have caused
the server's file system to exceed its limit. the server's file system to exceed its limit.
13.1.4.10. NFS4ERR_NOTEMPTY (Error Code 66) 13.1.4.10. NFS4ERR_NOTEMPTY (Error Code 66)
An attempt was made to remove a directory that was not empty. An attempt was made to remove a directory that was not empty.
13.1.4.11. NFS4ERR_NXIO (Error Code 5) 13.1.4.11. NFS4ERR_NXIO (Error Code 6)
I/O error. No such device or address. I/O error. No such device or address.
13.1.4.12. NFS4ERR_RESTOREFH (Error Code 10030) 13.1.4.12. NFS4ERR_RESTOREFH (Error Code 10030)
The RESTOREFH operation does not have a saved filehandle (identified The RESTOREFH operation does not have a saved filehandle (identified
by SAVEFH) to operate upon. by SAVEFH) to operate upon.
13.1.4.13. NFS4ERR_ROFS (Error Code 30) 13.1.4.13. NFS4ERR_ROFS (Error Code 30)
skipping to change at page 286, line 15 skipping to change at page 289, line 15
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.
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 had 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.
The NFSv4 protocol supports the association of a file with zero or The NFSv4 protocol supports the association of a file with zero or
more named attributes. The name space identifiers for these more named attributes. The name space identifiers for these
attributes are defined as string names. The protocol does not define attributes are defined as string names. The protocol does not define
the specific assignment of the name space for these file attributes. the specific assignment of the name space for these file attributes.
The IANA registry promotes interoperability where common interests The IANA registry promotes interoperability where common interests
exist. While application developers are allowed to define and use exist. While application developers are allowed to define and use
attributes as needed, they are encouraged to register the attributes attributes as needed, they are encouraged to register the attributes
skipping to change at page 288, line 35 skipping to change at page 291, line 35
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 6649, July 2012. RFC 6649, July 2012.
[Unicode1]
The Unicode Consortium, "The Unicode Standard, Version
3.0, ISBN 0-201-61633-5".
[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 ,
skipping to change at page 291, line 46 skipping to change at page 294, line 50
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.
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, and James David Black, Nico Williams, Mike Eisler, Trond Myklebust, James
Lentini read many drafts of Section 12 and contributed numerous Lentini, and Mike Kupfer read many drafts of Section 12 and
useful suggestions, without which the necessary revision of that contributed numerous useful suggestions, without which the necessary
section for this document would not have been possible. revision of that section for this document would not have been
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.
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
 End of changes. 44 change blocks. 
327 lines changed or deleted 427 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/