RFC 7530, "Network File System (NFS) Version 4 Protocol", March 2015

Note: This RFC has been updated by RFC 7931, RFC 8587

Errata ID: 7595
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David Noveck
Date Reported: 2023-08-10

Section 13.1.7 says:

13.1.7.  Name Errors

   Names in NFSv4 are UTF-8 strings.  When the strings are not of length
   zero, the error NFS4ERR_INVAL results.  When they are not valid
   UTF-8, the error NFS4ERR_INVAL also results, but servers may
   accommodate file systems with different character formats and not
   return this error.  Besides this, there are a number of other errors
   to indicate specific problems with names.

13.1.7.1.  NFS4ERR_BADCHAR (Error Code 10040)

   A UTF-8 string contains a character that is not supported by the
   server in the context in which it is being used.

13.1.7.2.  NFS4ERR_BADNAME (Error Code 10041)

   A name string in a request consisted of valid UTF-8 characters
   supported by the server, but the name is not supported by the server
   as a valid name for current operation.  An example might be creating
   a file or directory named ".." on a server whose file system uses
   that name for links to parent directories.

   This error should not be returned due to a normalization issue in a
   string.  When a file system keeps names in a particular normalization
   form, it is the server's responsibility to do the appropriate
   normalization, rather than rejecting the name.

It should say:

13.1.7.  Name Errors

Names in NFSv4 often are UTF-8 strings. However, in order to provide
compatibility with NFSv3 and with local filesystems that do not impose any such
restrictions on the form of name strings, UTF-8-unaware file systems are
supported.  For such file systems,  the server is, for the most part, unaware of
the encoding of names chosen by the client and is therefore unable to support
normalization-related processing or case-insensitivity.  In order to provide
proper support for the errors NFS4ERR_BADCHAR and NFS4ERR_BADNAME, the encoding
used by clients MUST use the same encoding as UTF-8 for all printable ASCII
characters.

For file systems which are UTF-8-aware,  when strings are not valid UTF-8
strings,  the error NFS4ERR_INVAL results.  As a result, clients can determine
whether the current file system is UTF-8-aware by looking up a string which is
not valid UTF-8 (e..g. the single byte 0x80)  and using an error return of
NFS4ERR_INVAl as indicating that only valid UTF-8 strings may be used.

When a string of length zero is passed, the error NFS4ERR_INVAL also results. 
but servers may accommodate file systems with different character formats and
return this error only in this case.  Besides this, there are a number of other
errors to indicate specific problems with names.

13.1.7.1.  NFS4ERR_BADCHAR (Error Code 10040)

A UTF-8 string contains a character that is not supported by the server file
system as part of a  file name.  For example, the forward slash is often
reserved for use to indicate multiple names within a path, making the creation
of file or directory names with embedded slashes problematic.

13.1.7.2.  NFS4ERR_BADNAME (Error Code 10041)

A name string in a request consists of a valid string supported by the server,
whether UTF-8 or otherwise, but the name is not supported by the server as a
valid name for the current operation.  An example might be creating a file or
directory named ".." on a server whose file system uses that name for links to
parent directories.  This error MUST NOT result in case in which  a 
(UTF-8-aware) server file system prefers a particular normalization for strings.
In such cases, it is the server's responsibility to do the appropriate
normalization, rather than rejecting the name.

Notes:

It has been brought to my attention that there is a fundamental contradiction between the idea
(derived from NFSv3) that file name strings can be opaque, and the existence of the errors
NFS4ERR_BADCHAR and NFS4ERR_BADNAME, which, by their nature presume at least some
knowledge of the character encoding being used.

This has not turned out to be a problem in practice because clients always use encodings that
meet certain criteria explained in the replacement text. However, these criteria need to be
documented clearly and appropriate warnings given. These criteria were observed by
implementers of NFSv3 but are not explicitly mentioned in RFC1813.

Report New Errata