Bug 202746 - file upload fails if destination is nfs volume
file upload fails if destination is nfs volume
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: vsftpd (Show other bugs)
4.4
All Linux
medium Severity high
: ---
: ---
Assigned To: Martin Nagy
:
: 202747 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-16 05:02 EDT by Vilius Šumskas
Modified: 2016-07-26 19:46 EDT (History)
5 users (show)

See Also:
Fixed In Version: vsftpd-2.0.1-5.EL4.5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-04 03:23:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vilius Šumskas 2006-08-16 05:02:52 EDT
Description of problem:
File uploads fails if destination is nfs volume. Upload progress bar just 
hangs there till I cancel upload. And after that forked vsftpd process remains 
in process list and you can not kill it. It worked fine with RedHat ES 4 
Update 3. Upload to local file storage works fine too.


Version-Release number of selected component (if applicable):
vsftpd-2.0.1-5.EL4.5

How reproducible:
Always

Steps to Reproduce:
1. Mount any NFS volume.
2. Upload any file to that volume.
  
Actual results:


Expected results:


Additional info:
Worked with ealier versions of vsftpd
Comment 1 Nalin Dahyabhai 2006-08-16 06:58:54 EDT
*** Bug 202747 has been marked as a duplicate of this bug. ***
Comment 2 Brian DeFeyter 2006-08-31 17:10:31 EDT
I had the exact same problem after installing the latest RHEL4 update set and
rebooting. The vsftpd processes would attempt to obtain a lock and then would be
forever stuck in disk sleep waiting on rpc_ex.

It appears that rpc.statd is not able to start via the init scripts. I needed to
manually execute /sbin/rpc.statd after booting to resolve the problem.
Comment 3 Vilius Šumskas 2007-05-21 16:02:01 EDT
I can confirm this bug as fixed in RHEL5.
Comment 4 Martin Poole 2007-06-04 07:06:43 EDT
There was a change between vsftpd-2.0.1-5.EL4.3 and vsftpd-2.0.1-5.EL4.5 in the
way files were handled for uploads. This involved including locking code for
both reads and writes and means the daemon will attempt to obtain locks on any
file it reads on a GET/PUT operation. If the file is NFS mounted then the NFS
locking systems also need to work.

There is a workaround if you are not worried about simultaneous uploads to the
same file. Simply add

 lock_upload_files=NO

to the /etc/vsftpd/vsftpd.conf file and restart the daemon.
Comment 5 Nalin Dahyabhai 2007-12-11 10:37:05 EST
Are other applications which attempt to use file locking on the NFS volume also
getting stuck attempting to obtain a lock?  If so, then I think this would point
to a problem in nfs-utils rather than in vsftpd itself.
Comment 6 Vilius Šumskas 2007-12-11 10:48:25 EST
I don't have RHEL4 anymore, but as far as I remember it worked with simple MC 
copy file command to NFS volume.

Also as I pointed out, this doesn't happen in RHEL5.
Comment 7 Martin Nagy 2008-02-04 03:23:32 EST
I can reproduce this issue on RHEL-4.6 after I kill rpc.statd, otherwise it
works okay, so it appears there was some bug in RHEL-4.4 in nfs-utils but is
already resolved in RHEL-4.6. Thus closing as CURRENTRELEASE.

Note You need to log in before you can comment on or make changes to this bug.