nautilus ftp file transfer hangs when transferring directories

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

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.

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.

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.

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

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 https://wiki.ubuntu.com/Bugs/Upstream/GNOME. 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.

This might be upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=630348 ? But doesn’t look like there is very much happening upstream.

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

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

the same isssue:( VERY annoying

Still in issue in Precise.

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?

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: libgvfscommon-dnssd.so, not installed any
    more (it's just an internal library).
  * debian/control.in: Bump glib build dependency as per configure.ac.
  * 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
    failures.
  * 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

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

Can someone backport this to Ubuntu 12.04?

> 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

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

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.

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

gvfs-ftp still hangs up in ubuntu 13.04.

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?

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

Enjoy!

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