nautilus ftp file transfer hangs when transferring directories

Bug #932935 reported by Adam Niedling on 2012-02-15
This bug affects 78 people
Affects Status Importance Assigned to Milestone
Fix Released
gvfs (Ubuntu)

Bug Description

Update by André aka Papou. Workaround. See comment #26 for details.
I had the idea to work with links instead of canonical (ahem) names.
ln -sfT ~/.gvfs/"FTP as username on hostname" my.local.alias
And there went the folder copies happily to and from that my.local.alias link.
Working with an alias and Gigolo has other advantages.
--- EOU ---

This report is basically the same as bug #574693 but it is already closed as fixed and won't be reopened.

I ran into this issue in Ubuntu 11.10 x64 while copying from the FTP server to my Ubuntu box. Please see attached video.
gvfs: 1.10.0-0ubuntu1
nautilus: 1:3.2.1-0ubuntu3.2
Linux: 3.0.0-16-generic
FTP server: OpenWRT Backfire (10.03.1, r29592), Linux, vsftpd 2.3.4-2

List of files I tried to copy: ./Sample/thuck-wtts-sample.avi thick-wtts.nfo thick-wtts.r00 ... thick-wtts.r57 thick-wtts.rar thick-wtts.sfv
The name of the directory:
The size of the whole directory is approx 1.1 Gbytes. The rar files are approx 20 Mbytes. 64 files, 1 subdirectory.
(This material is of course a public domain home made footage)

I already reproduced this bug three times, copying only worked when I tried to copy the files themselves and not the whole directory. The operation always stops around 20 megabytes.
When I close all nautilus windows, the little copying bar still remains in the Launcher on the icon of nautilus indicating that some operation is still ongoing but nothing is actually happening.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: gvfs 1.10.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-16.28-generic 3.0.17
Uname: Linux 3.0.0-16-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
CheckboxSubmission: e2c1dd7c516ed88e0de43a227ceb28c1
CheckboxSystem: 2954e74ba17fb0e37fc942cd1d9fab4e
Date: Wed Feb 15 18:35:20 2012
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
SourcePackage: gvfs
UpgradeStatus: No upgrade log present (probably fresh install)

Adam Niedling (krychek) wrote :
Adam Niedling (krychek) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gvfs (Ubuntu):
status: New → Confirmed

I can confirm this for Precise: Copying files via FTP hangs, in my case even after two tiny files. Commandline ftp or BareFTP work perfectly fine.

tags: added: precise
summary: - nautilus ftp file transfer hangs in oneiric
+ nautilus ftp file transfer hangs

Frederik: does it hang only when you drag&drop directories containing files or it's the same with just files and no directories?

Adam: You’re right, it only hangs when copying directories. Single files work fine.

Strange thing is that nautilus actually created the target directory and transferred two of the contained files before it hang.

summary: - nautilus ftp file transfer hangs
+ nautilus ftp file transfer hangs when transferring directories
Adam Niedling (krychek) wrote :

Frederik: I have another question which is not really related to this bug. When you connect to a password protected FTP server with nautilus there is an option to remember password. Do you know if this one has any actual functionality? I can't seem to find a way to load back the saved password so I don't have to type it all over again the next time I connect to the FTP server.

Adam: You’re right, nautilus doesn’t seem to remember the password. Once I unmounted the FTP share, I have to re-type the password if I want to mount it again. But this really seems to be a different bug.

Adam Niedling (krychek) wrote :

Frederik: do you want to report it as a new bug? Please tell me the bug number if you do. Thanks. :)

Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Changed in gvfs (Ubuntu):
importance: Undecided → High

This might be upstream bug ? But doesn’t look like there is very much happening upstream.

Adam Niedling (krychek) wrote :

Frederik: That upstream bug report is already closed as fixed. Do we have to open a new one there or can we reopen it?

no longer affects: gvfs
Adam Niedling (krychek) wrote :

Nevermind, I mixed it up with another one, sorry.

Changed in gvfs:
importance: Unknown → Medium
status: Unknown → In Progress
ngsupb (ngsupb) wrote :

the same isssue:( VERY annoying

Adam Niedling (krychek) wrote :

Still in issue in Precise.

Yanick Rochon (yanick-rochon) wrote :

Do we actually have an idea as to why it hangs like this? And why there isn't any report from nautilus? Even when I try to cancel the transfer, it still does not respond, I have to use xkill on the transfer window (which closes all nautilus windows too) This is not hardware dependant issue, so it is easy to reproduce, thus should be easy to fix. Why does it take so long?

Changed in gvfs:
status: In Progress → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gvfs - 1.13.9-0ubuntu1

gvfs (1.13.9-0ubuntu1) quantal; urgency=low

  * New upstream release:
    - Some code cleanup
    - Lots of translation updates
    - Bug fixes
    - gmountsource: Always use NULL-terminated arrays (LP: #1033275)
    - Remove final parts of libdbus (LP: #932935)
  * Disable 04_hurd_path_max.patch; not required for Ubuntu and does not apply
    any more.
  * Update 05_shared_libdaemon.patch for new upstream version.
  * Drop check-gdu-pool.patch, applied upstream.
  * Update build_old_libgphoto.patch for new upstream version.
  * debian/gvfs-backends.install:, not installed any
    more (it's just an internal library).
  * debian/ Bump glib build dependency as per
  * debian/tests/gvfs-test: Rename Sftp.test_localhost() to test_rsa(), and
    factor out the checks on the gvfs mount.
  * debian/tests: Direct sshd log into a file, and cat it if there are test
  * debian/tests/gvfs-test: Add test case for RSA authentication for unknown
    host. This reproduces the crash in LP #1033275.
  * debian/tests/gvfs-test: Relax expected gvfs-mount -li output for working
    with 1.13.9.
 -- Martin Pitt <email address hidden> Thu, 20 Sep 2012 14:52:13 +0200

Changed in gvfs (Ubuntu):
status: Confirmed → Fix Released
qwazi (chris-mckitterick) wrote :

It is unclear to me that this is fixed. If I mount a cifs share manually using the mount command, I have no problem reading and copying files from it.

However, if I use gvfs-mount and then try to copy many files, rsync or nautilus (whichever I'm using for file copying) will fail and I will need to kill the process. I'm using a fully up-to-date Ubuntu 12.10 which is using: gvfs (1.14.0-0ubuntu5) quantal; urgency=low

Reloweb (reloweb) wrote :

Can someone backport this to Ubuntu 12.04?

Sebastien Bacher (seb128) wrote :

> Can someone backport this to Ubuntu 12.04?

Not likely, the fix is "rewrite most of the backend code to use another dbus client library", rewrites to use new technologies don't qualify for stable update, they are too hard to review and with a high chance of regression in the update

Reloweb (reloweb) wrote :

It's possible to install gvfs from quantal repository? Can someone post the package list to upgrade gvfs?

cengopon (pognonec) wrote :

Using Nautilus to connect to a server, I also get a frozen transfer after a few percent. The little tranfer icon in the left pannel remains "on" even after killing the main transfer window.

miknen (miknen) wrote :

I'm facing same issues with nautilus, copying folders from server to client hangs. This same bug is also present in openSUSE.

Dmitry Misharov (quarckster) wrote :

gvfs-ftp still hangs up in ubuntu 13.04.

Pat McCaffrey (pkmccaffrey) wrote :

This bug is driving me insane. It just started happening last night. Prior to yesterday, I was able to upload directories just fine, now it freezes after only a few kB's get transferred.

Any sort of a fix?

André Pirard (a.pirard) wrote :

Workaround within.

I am surprised to upgrade to 12.04 with updates up to 13.06 and to meet this very serious problem reported 12.02 that did not exist with 10.04.

In my mind, a bug report system should contain not only a Bug description and a Bug Discussion sections but also a Bug solution section where the user can find in everybody's terms what he must do to solve the problem in the LTS system he is running (and not another one).
I am surprised that this doesn't seem to be Canonical's view.

In consequence, I have written the summary of what would have remained hidden in here as an update to Bug Description to serve as a Bug Solution/Workaround.

After upgrading to 12.04 updated 13.06, I met the bug described here.
Typically, I was unable to download a folder from the FTP server (make a backup).
I had the idea to work with links instead of canonical (ahem) names.
ln -sfT ~/.gvfs/"FTP as username on hostname" my.local.alias
And there went the folder copy happily to that link.
Even made the copy test both ways simultaneously.
Well, there were a few files on which the Copy stopped with a error.
But that's because my server makes frequent size limits, aborts, timeouts and such.
File Copy should have a retry option and I retried manually.

Now I still have to see if another PITA remains.
Sometimes, the information obtained from a subsequetly opened FTP connection predates what's supposed to be accomplished on the first connection (race condition), such as an application creating a file and then trying to rename it and getting a "does not exist" [yet] result.

Another problem is that opening the canonical name opens Firefox instead of Nautilus.
Also worked around with the symbolic link.

> nobody probably cares about ftp these days ;)
Oh yes. Think twice. It's often the only way to access a free server and you shouldn't tell them that gvfs-ftp and Gigolo make it as easy as anything.

> it would be quite helpful if somebody experiencing it could send the bug the to the people writing the software.
Ubuntu users should not be requested to know where Canonical gets its software and to do that.
(even a triager once sent me to the wrong place)
This bug report should be peered with an "upstream" bug by Canonical so that everybody can contribute from Launchpad without the need to make dozens of OpenIDless other subscriptions.
And so would the Ubuntu users get all the Ubuntu information in the Ubuntu database.
I've seen attempts to peer BugDBx with BugDBy. That's a N*N effort.
Maybe create a central hub and make it a N effort?

> Adam: You’re right, nautilus doesn’t seem to remember the password. Once I unmounted the FTP share, I have to re-type the password if I want to mount it again. But this really seems to be a different bug.
Use Gigolo, it does it, and be happy.

Made in Belgium, with chocolate and beer ;-)


description: updated
CRAFT (craft37) wrote :

Seems like it affects me in Ubuntu 14.10.
Nautilus version 3.10.1

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.