Tips for getting anonymous vsftpd to use an NSS volume

1.  The NSS volume was called FTPVOL, so it's local access path was /media/nss/FTPVOL.  This was to be the root of the ftp anonymous area.

2.  To access an NSS volume, the user has to be LUM enabled.   The vsftpd uses the 'ftp' account with uid 40 when handling anonymous access, so that is the user to focus on.  Other methods were tested.  For example, creating a new user 'vsftpuser' and LUM enabling it, and then setting nopriv_user=vsftpuser.  This approach assumes that anonymous access would then use the vsftpuser account instead.   This did not work as expected.  No matter what value was set for nopriv_user, vsftpd was always trying to use user 'ftp' with uid 40.   It would not use 'ftp' if it had a different uid, either.  Possibly the name 'ftp' doesn't matter at all.  Maybe *any* name is okay as long as it has uid 40.  This point was not verified.  But it would not work without uid 40.  So to summarize the working scenario: user 'ftp' with uid 40 existed in eDirectory and was LUM enabled.  No other user called 'ftp' or with UID 40 existed anywhere.

3.  The anonymous home area can be specified by the home directory setting in the Linux Profile of the ftp user (uid 40), or with anon_root=/path in vsftpd.conf.  If both are set, the vsftpd.conf will override.

NOTE:  If the Linux Profile of an already-existing user is changed, it may take a while for the name caches to flush and get the new information.  Execute 'rcnamcd restart' and 'rcnscd restart' to flush them early, then wait a few minutes beyond that.  Test with 'su ftp' and then 'id' to see if the uid is correct.  Do 'cd ~' and 'pwd' to check if the home directory is correct.

4.  Knowing that vsftpd does not allow the 'root' of the anonymous area to give write access to the anonymous user, if uploads are desired, created an 'upload' subdir underneath this, where anonymous would be able to have write access.  Use chown to set the 'upload' directory to be owned by user 'ftp'.

5.  By default, an NSS volume shows permissions of 777 on any directory.  The directory /media/nss/FTPVOL was is owned by root:root, so in theory it was just the 'other' access that needs to be decreased.  However, NSS's 'fake' permissions are very picky about how they can be set.  Keep the permissions the same for all 3 categories.  So 'chmod 555' will be accepted, but chmod 775 will not succeed (no error, but no success).  Alternatively, one could do chmod u-w, because NSS accepts that and automatically takes 'w' away from group and other as well.  So again, permissions end up as 555.  Another possible approach is to use an NCP client to add the read-only attribute to the directory, and that would cause permissions to change to 555.  (This NCP client method was not tested by the author.)

6.  Remember that true access to the NSS volume depends on trustee rights.  Used the 'rights' command to make sure the ftp user in eDirectory had trustee rights RF to /media/nss/FTPVOL and RFEMWC to /media/nss/FTPVOL/upload.

With those things done, vsftpd anonymous access to an NSS volume works very well.