OES: pure-ftpd can't upload files to NSS: 226-Rename/move failure

  • 7000662
  • 11-Jun-2008
  • 23-Jul-2018


Novell Open Enterprise Server 2 (OES 2)
Novell Open Enterprise Server 11 (OES 11)
Novell Open Enterprise Server 2015 (OES 2015)
Novell Open Enterprise Server 2018 (OES 2018)


It is expected that the exact problem described here will only occur on OES 2 or it's early support packs.  However, newer editions of OES are mentioned in order to describe behaviors which have evolved over time. This knowledge may be relevant to troubleshooting different variations and causes of the errors mentioned.
A LUM-enabled user is attempting to upload a file through pure-ftpd to a NSS volume on OES 2.  Even though the user has all rights, the upload fails to NSS volumes with either of the following errors:
226-Rename/move failure: Invalid argument
553-Rename/move failure: Invalid argument
The user can upload successfully to non-NSS file systems on the same server.


Because this document was originally intended only for OES 2, some of it's details or suggestions may not be relevant to current OES systems.  For now, however, it is being kept available (a) for those who may be using older OES systems, and (b) to preserve certain useful statements about how OES FTP and pure-ftpd function.  It is recommended that all the special notes and updates later in this document be read, in order to be aware of the evolution of this topic.
This situation is connected with a combination of two of pure-ftpd's practices.  First is the practice that pure-ftpd 1.0.22 (or older) will upload files to temporary names and then rename them to an intended final name, after the upload is complete.  Second is the optional practice of using the "AutoRename" feature.  The purpose of this feature is to upload files in such a way that existing files of the same name will not be overwritten.  If this feature is on and the filename being uploaded already exists at the target destination, unique characters will be appended to the destination filename in order to avoid overwriting the existing file.
To expand on these practices in more detail:
In pure-ftpd 1.0.22 and older, all uploads through pure-ftpd are first saved to a temporary filename in the format .pureftpd-upload*.   After the upload is complete, the file is "renamed" to the final, intended name.  However, this could be handled in two different ways, depending on configuration.
-  If pure-ftpd.conf has "AutoRename no", the file is simply renamed (moved) to it's intended (original) name, overwriting the previous copy.
- If pure-ftpd.conf has "AutoRename yes", an additional hard link is created to the uploaded temporary file.  The new hard link is given the new, unique destination name, and then the temporarily-named link is removed.  A previously existing file with the same name will remain untouched.
This hard link procedure can result in an error on NSS volumes, because by default, NSS volumes do not support hard links.  If this error is occurring, the 2 options are to either:
1.  Set "AutoRename no",  then restart pure-ftpd (rcpure-ftpd restart)
2.  Enable hard links on the NSS volume.
To check whether hard links are enabled for a volume, in nsscon, run
nss /volumes
and then look for "Hardlinks" in the attribute column. If it is not shown for the specific volume in question, it should be enabled.
NOTE:  The following upgrade of the NSS media format is not reversible.  As a precaution, a current backup should exist so that recovery is possible in case something goes wrong in this procedure, or in case some production process does not like the resulting new format.  Problems with this procedure are rare, but a backup is always recommended.
To enable had link support, do the following in nsscon:
nss /ZLSSUpgradeCurrentVolumeMediaFormat=volname
nss /Hardlinks=volname
NOTE:  The ZLSS upgrade may take some time, depending on the size and contents of the volume.  However, the nsscon prompt will return immediately.  The upgrade continues in the background.  If you give the "nss /Hardlinks=volume " command before the upgrade is actually finished, you will get an error stating:
Hardlinks may not be created on volume "volname" until it is upgraded using the "ZLSSUpgradeCurrentVolumeMediaFormat" command...
If this occurs, simply give the system more time and try the "nss /Hardlinks=volname " command again later.

Special note for OES 2 SP2:

Changes in OES 2 SP2 appear, in some cases, to allow the upload / renaming procedure to complete successfully even with "AutoRename yes" and no hardlink support.  Not all the details are known, but it is suspected that admin users will upload and rename successfully, but still show the 226 error.  Non-admin users will likely get the 553 error and the file will not be present afterwards.  Either way, Novell considers it necessary to either enable hard link support or to set "AutoRename no" for cases where FTP users need to upload to NSS volumes.

Special note for OES 2 SP3, OES 11, and newer:

A change to OES pure-ftpd, originating in OES 2 SP3, introduced a new policy within the code:  Now, if "remote_server yes" is in use, the normal outcome of the AutoRename feature will be suppressed, i.e. the newly uploaded file will overwrite the old one, rather than be given a unique new name.  This avoids the hard-link usage.  Therefore, these newer OES versions should never run into the problem which this document original described.  (Note:  This does not avoid the use of a temporary upload name, it only alters the handling of the final name of the uploaded file.)

Special note for OES 2015 SP1 and OES 2018:

Maintenance updates to the package "novell-oes-pure-ftpd" in these newer versions of OES bring the base package version up to 1.0.43.  One of the changes in the newer version is to decrease the usage of temporary files for uploads.  In the base pure-ftpd 1.0.43 code, files are uploaded to their regular names (not a temporary name) except when "NoTruncate" or "AutoRename" are set to "yes".  When either of those settings is "yes", use of a temporary upload file name will still occur.
As one final clarification of the behavior in 1.0.43:  If "remote_server yes" and "AutoRename yes" are both set, a file which is uploaded will first be given a temporary name, and later renamed (moved) to it's intended name.  This process will overwrite an existing file of the same name.  This is consistent with the suppression of the AutoRename outcome, mentioned in a previous "Special note."

Change Log

Darcy Partridge, 2018-07-23:  Added details about v1.0.43's changes to the usage of temporary filenames during uploads.  Made minor modifications throughout to help the entire document be self-consistent.