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

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:

 

 

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)

 

-or-

 

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:

 

 

If this occurs, simply give the system more time and try the "nss /Hardlinks=volname " command again later.

 

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.

 

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.)

 

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."