Ubuntu

nautilus hangs copying large directories from a samba share

Reported by Alessandro Lazzari on 2012-11-07
This bug affects 206 people
Affects Status Importance Assigned to Milestone
gvfs
Fix Released
Medium
gvfs (Ubuntu)
High
Unassigned
Precise
High
Unassigned
Raring
High
Unassigned

Bug Description

Impact:
copies from/to samba share often end up hanging

Test case:
- visit a smb location in nautilus
- copies data from/to it (some non trivial directories makes the issues easier to trigger)
- the copy should complete without hanging

Regression potentiel:
Check that nautilus is still working correctly and than you don't have issues copying data from/to remote locations

---

Problem
=======
Copying files to and from samba shares (this includes Windows shares) is unreliable in Ubuntu 12.10 and Ubuntu 13.04 when using nautilus' integrated samba client (gvfs-smb): The copy randomly hangs after a few files or a few GB.

Workaround
==========
Until gvfs-smb is fixed, use the kernel samba client (cifs) that works reliably, is faster, but needs some terminal commands to get going:
# sudo -s
# mkdir /mnt/cifs
# mount -t cifs -o user=YOUR_SAMBA_USER -o uid=YOUR_LINUX_USER "//SAMBA_SERVER/SAMBA_SHARE" /mnt/cifs
It will ask for you password, you can then access the shared files at /mnt/cifs.

description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in nautilus (Ubuntu):
status: New → Confirmed
Bud (vud) wrote :

I am having the same problem copying large directories with many files from a Win2003Server samba share to my desktop. Worked fine on 11.04 and 11.10, but not on 12.04 or 12.10. Was happy to see 12.10 release as I wanted this problem fixed, but still there. Couldn't find any other mention of it in the forums. Sorry to say, I'm still stuck using an old laptop with reliable 11.04 to accomplish the server backup. File transfer is identical to Alessandro. Hangs quickly or almost gets to finish. Starts out quickly then just peters out and hangs. No error messages. Have to reboot to get out of the transfer Nautilus thinks it's performing. Cancel has so effect. Running on a 1000/100 ether lan with mostly (16) windows vista machines, 5 XP, 4 win7, 5 OSx, and 4 Ubuntu boxes. I can dual-boot into XP and have no problem, so that removes any faulty hardware. If anyone has an idea... I'm all ears. Thanks, Bud

cackharot (cackharot) wrote :

I too have the exact problem when trying to copy large files between hard disks. Unfortunately I just clean installed 12.10 over 12.04. :(

I have this problem since updating the client to 12.10. On large copies from an 12.04 Server over samba mounted using gvfs (nautilus). I tried nautilus itself, rsync and cp. All of them stop working after around 100-600MB. The curious thing is, i tried to copy images/videos from an iphone with just the same problem. After 100-600MB nautilus stops copying.

Because of this i think it isnt related to smb only. I have to restart the whole client to start the copy again because the copy process gets zombies after a kill. There is no log entry, no dmesg output related to this error on client or server.

You are using manually cifs mount or nautilus?

I tried using the nautilus shortcut and also tried copying from /run/user/<username>/gvfs/<share>. No difference whatsoever.
I also think gvfs might be involved, too.

Steffen Grosser (sg83) wrote :

I had this problem with Debian squeeze and it disappeared under Ubuntu 12.04, but reappeared now with 12.10.

File copy stalls copying directories with many (>100, >1000) files from a network share.

And in not only happens with NAUTILUS, but also with THUNAR, the xfce file manager, so it probably is not really a nautilus problem.

Today I tried to copy my big directory from the share straight to a usb drive. It worked without a hitch. I'm not sure how it could be useful, but it's worth sharing nevertheless.

MrHobbit (buelens-paul) wrote :

I'm having the same problem when copying files from my camera (connected via USB) to a local hard disk.
The copying starts and after some time (sometimes after copying 2 files, sometimes after 100), it hangs.
Can't find any messages in /var/log, no unusual cpu usage .... just no progress anymore.

I have this same problem, but it also affect me when I copy files from my digital camera. Only started since the upgrade to 12.04.

I suffer from that problem, too.

Client is 12.10 x64 and server is 12.04 . Reading from the shares work, but copying stops after around 100-500MB and the copy is not responsive anymore. Problem exists with rsync and cp, too.

I have nothing at the logs. Problem wasnt existing in 12.04.

Nico Timeo (n-timeo) wrote :

It also affects me.
When I try to copy files from QNAP NAS share, samba randomly hangs without any notice.
Using a clean install of Ubuntu 12.10 (32 bit).
This problem was not present in Ubuntu 12.04.

Phillip G. (thedimmu) wrote :

I also think that this is not really a bug in Nautilus but in GVFS-Mounts. I have the problem (on 12.10, x64) when copying to my NAS when it is mounted with GVFS as SMB or as FTP. It works for me when using GVFS over SFTP.
There are also no Problems on my other machine with 12.04.

Phillip G. (thedimmu) on 2013-01-11
tags: added: gvfs network
Phillip G. (thedimmu) wrote :

Happens not only with Nautilus but also for example with Deja-Dup which (like Nautilus) uses GVFS for mounting.

affects: nautilus (Ubuntu) → gvfs (Ubuntu)
Simon (simon-george) wrote :

I had the same problem having a over 500 files on a smaba share (samba4). No problems accessing it with my desktop running 12.04 (samba3 client) but kept hanging (with no crash as per bug description) on my laptop running 12.10 (samba3 client).

I have since installed fusesmb and the problem seems to have gone away although I have not carried out extensive testing.

Pete (superpete-5) wrote :

Can confirm this, too, on Ubuntu 12.10. Copying works if I mount smb as cifs, but using Nautilus it gets randomly stuck... (Only happend copying large directories, in particular with many files, but maybe that just raises the chance...)

Destain Duckert (dduckert) wrote :

I have the same problem on Ubuntu 12.10. I have tried 2 fresh installs and both the exact same issue. Copying about 45gig of music around 11,000 files the copy freezes anywhere from 200 to 600 meg. I thought I would try Ubuntu 13.04 just to see... and it's plagued with the same problem. Haven't moved to 12.10 because of this bug.

Nico Timeo (n-timeo) wrote :

I do not understand why, after over two months, this confirmed bug is still Unassigned... :-(

Erwin (errvv1n) wrote :

I have the same problem too, but only on Ubuntu 12.10 and more than 2 GB transfer (SAMBA)! I go back to 12.04 LTS ... it works fine.

I'm also wondering why this bug is being ignored. Everybody posting here please don't forget to mark this bug as affecting you. I don't know of another way to bring this to the devs attention.

AndreK (andre-k) wrote :

I asked a question "how to get some attention to a important bug" - during an chat with one of the guys from ubuntu. "ubuntu on air"

he told me I needed to contact "developer team" - easier said, than done, after much searching I found mail address of somewhat significant member, team admin. Sent mail, explaining that this is very important to many users, business users, and very, very, discouraging to anyone that tries Ubuntu at home and have som sort of network/NAS/server.

no response - that was >1 week ago.

Sebastien Bacher (seb128) wrote :

The bug is not ignored, but we lack of manpower and people who know about samba, there is just too much to do, anyone is welcome to work on the issue and submit a patch though

AndreK (andre-k) wrote :

why not revert to the version that was used in 12.04 ? - at least it worked reliably ?

Sebastien Bacher (seb128) wrote :

because gvfs does tons of things, the main one is handling of disks and mounts. samba is only one of the backends (it has some for ftp, sftp, webdav, etc etc etc). The new version has lot of bugs fixed, and usually GNOME components should be on the same version so you would need to downgrade nautilus to and old version as well

Changed in gvfs (Ubuntu):
importance: Undecided → High
Christopher Hill (ch6574) wrote :

I believe this bug also impacts me too.

Some simple tests made against the same remote network mount (windows server via 100mbps Ethernet) when rsyncing a 1GB file produce quite different results.

First when mounted via Nautilus (i.e. via /var/run/user/$user/gvfs/foo) I get a transfer rate of under 3MB/s.

Then when using a permanent mount (i.e. mount -t cifs //foo/bar /mnt/bar) I get a transfer rate of over 9MB/s, which is nearly saturating the Ethernet link.

I've repeated these checks in reverse order to eliminate the effects of caching, and it seems that gvfs is having the problem.

Kanehekili (jentiger-moratai) wrote :

This bug affects me in Ubuntu 12.10 /Mint. I am not able to play videos on an SMB Share. VLC starts, stutters and freezes after a short time. Only killing of the gvfsd shuts down VLC as well.
No problem in other distros, such as Fedora!

Sebastien Bacher (seb128) wrote :

> No problem in other distros, such as Fedora!

depends of what version of fedora you use (or rather what gvfs version), no problem on Ubuntu precise either...

Fedora has gvfs 1.15 (http://koji.fedoraproject.org/koji/packageinfo?packageID=5487) while Quantal has 1.14, which has been rapidly deleted on Fedora. I have not time to dig this more, but, if there is a PPA with a 1.15 build, I am available to test it out.

Bart Jansen (spem-bartjansen) wrote :

This bug affects me in Ubuntu 12.10 64bit with Gnome Shell.

I am letting MatLab (numerical computing environment) read 'large' quantities (80 at the moment) of image files of 2MB each. I use the /run/user/$user/gvfs/... as directory to access. When experimenting I have also tried letting the MatLab script sleep for 10 seconds in between reading every image file, but to no avail. Maybe the bug is not time-related?

Somewhere in the process of reading the files the MatLab script just freezes and then it does not even react to the abort command Ctrl+C. After trying to kill the MatLab process using System Monitor or by running the kill command in terminal, the process becomes a Zombie process which I cannot kill.

The same happens when copying the files with PC Man FM file manager or copying using the terminal. I have tried both on a wireless and a wired network connection.

I hope this information is somehow helpful.

Sebastien Bacher (seb128) wrote :

gvfs 1.15 is an unstable version and depends on new unstable series of glib/libsoup, it's available in raring though

jack (jsaury) wrote :

yes me to i am affected in mint 14 mate kernel 3.5.0-22 generic , CPU Intel Pentium 4 3.2 Ghz
when copying files or reading video with any from network disc
no way to kill VLC , gnome player , caja ( Mate file browser) also freeze when file tranfers
small file transfer and browsing folders do not cause problems

apinunt (apinunt) wrote :

Same problem her, and I have to use xkill to kill everything.
Previously when I mounted an NAS drive I had an entry in /home/$USER/.gvfs showing the content. After installing Mint 14 /home/$USER/.gvfs no longer shows the NAS drive connected, but instead I find it appears in both /run/user/$USER/gvfs AND in /var/run/user/$USER/gvfs, with /var/run being a link to /run. Why this change? And is this change in any way related to being the cause of the problem?
In my opinion, this is a very serious problem.

Bud (vud) wrote :

Can copy/move many files/directories via usb and Nautilus - no problem.
Can't do the same over network with smb. Even booted many machines from live cd and same problem.
YES... THIS IS A VERY SERIOUS PROBLEM. Can't use this release at all.
Surprised this problem made it through testing to an actual release.
Thanks,
Bud

Kanehekili (jentiger-moratai) wrote :

I would like to answer to comment #27. It was Fedora 17 that worked without any problems.
I could solve the problem by removing gvfs and using the package "cifs-utils". Once defined the proper data and credentials in "/etc/fstab" cifs works without problems and about twice as fast. The average upload/download rate from/to the smb server (which runs on a puppy linux) increased from 7MB/s to 13 MB/s
(This was tested on Linux Mint 14)

Removing gvfs from xubuntu (12.10) and replacing it with cifs showed similar results: Thunar now starts fast and no locks occurred.
So I would advise anybody who has problems with gvfs to replace it with cifs....

Nico Timeo (n-timeo) wrote :

Kanehekili, please can you explain how to remove gvfs and replace it with cifs in Ubuntu 12.10?
This would be a workaround.... Thanks!

apinunt (apinunt) wrote :

Looking at synaptic in Mint 14, I found "cifs-utils" is already installed and I believe it only provides another method of mounting an external drive in addition to gvfs, but I'm hoping the problem with gvfs will be fixed soon.

Kanehekili (jentiger-moratai) wrote :

Well, you should not remove all of gvfs, but the gvfs-fuse package.
That can be done using the "sudo apt-get remove gvfs-fuse" command or using the "Synaptic" package manager.
After that I created an entry in the file /etc/fstab - there is a lot of documentation around- I'll recommend the "arch wiki"
(https://wiki.archlinux.org/index.php/Samba#Automatic_Mounting)

After mounting (without sudo!) my shares like "mount /home/YOUR_USER_NAME/AFOLDER" the samba share could be accessed via the defined folder.
To my surprise nemo (yes I'm using Linux Mint after years of Ubuntu...) remembered those mount points by displaying the in the bookmarks panel.
So I have simply to click it and my share is mounted.

If you remove all of gvfs, you won't even see on your desktop whats mounted- if you insert an usb stick, you would have to mount it yourself....
So removing "gvfs-fuse" , installing "cifs-utils" and altering the /etc/fstab file turned out to be a very elegant solution.
I am tempted to check if there are further alternatives to all the gvfs packages....
Removing gvfs-backends for example made Thunar (on my xubuntu machine) very fast on startup.. but the price is that you don't have any "mount" icons...

apinunt (apinunt) wrote :

I'd prefer that be called a work-around, and NOT a solution. Fixing gvfs is the solution.

AndreK (andre-k) wrote :

still unassigned.. all if ubuntu devs are playing with Ubuntu phone ?

Sebastien Bacher (seb128) wrote :

> still unassigned.. all if ubuntu devs are playing with Ubuntu phone ?

no, but no gvfs hacker in the current team, we welcome somebody to step and join though ;-)

information type: Public → Public Security
information type: Public Security → Public
Changed in gvfs (Ubuntu):
status: Confirmed → Triaged
Changed in gvfs:
importance: Unknown → Medium
status: Unknown → New
Paul White (paulw2u) on 2013-04-30
tags: added: raring
description: updated
Changed in gvfs:
status: New → Confirmed
121 comments hidden view all 201 comments
Karl Frisk (karl-frisk) wrote :

Romano: Yes I am pretty sure. I also had unkillable nautilus and vlc processes but as soon as _gvfsd-smb_ is gone these processes terminate as well.

Sebastien Bacher (seb128) wrote :

shrug, with all those users hitting the issue could one of you provide the infos upstream need to work on this bug?
https://bugzilla.gnome.org/show_bug.cgi?id=697782#c21
that would probably more useful than keeping adding comments here...

Nicolas Binkowski (argonnate) wrote :

Hi,

i have new for me with the last update of Linux Mint Nadia (14)... when i copying some files on My NAS, the transfert ends correctly but i can't use nemo anymore ... I can't start system monitor !!! to kill gvfsd-smb..

i have to use terminal commande (killall gvfsd-smb) and nemo is usable again ..

I started getting miserable performance after upgrading from 12.10 to 13.04. It's affecting any and all apps being served by gvfs: Nemo, Nautilus, mplayer, Firefox—anything at all that's accessing a remote filesystem. Again, tests with simply sftp-ing files around or using proper cifs mounts show dramatic speed increases.

In this case, I'm getting ~500KiB/s with gvfs and ~80MIB/s without. The server I'm testing against was also recently upgraded (12.04 -> 13.04 via 12.10), but I've confirmed that my scheduled rsyncs between the file server and the backup file server (also 13.04, slower hardware) can crack ~110MiB/s.

The laptop I'm on only supports "half-jumbo" frames (MTU 4,078), whereas the primary and backup file servers are using full-size (MTU 9,000) frames, so I know why speed is capped at ≤ 80MiB/s in this case.

Does anyone know how to mess with gvfs knobs, short of replacing binaries with scripts? Things like /usr/lib/gvfs/gvfsd-fuse support ~60 cmdline parms that we could be experimenting with.

apinunt (apinunt) wrote :

Could this be a handshake/timing problem?
I've experienced this problem on 3 different computers, a 15 yr old IBM ThinkPad notebook, a Compaq notebook with a Celeron 560 CPU, an HP desktop with a dual core E5300 CPU, and noticed that the IBM was most affected and along with the Compaq unable to play a video file off the NAS, the HP was less often affected and could sometimes play a video off the NAS as long as I did not advance the slider several minutes into the video. I just replaced the old IBM notebook with a Samsung NP700G7C having a quad core i7-3630QM CPU and have yet to be affected by the problem, able to transfer more than 36GB of files from the NAS without a problem and able to play videos directly off the NAS without locking up.

rod singleton (rod40cool) wrote :

apinunt, you could be on to something here. Definitely speed of computer seems to have some bearing on this bug. I just upgraded my Lenovo T400 core 2 Duo 4G to Lenovo T520 Core i7 8G and i'm back to using Nautilus GVFS shares to Windows server and so far I haven't had the same lock ups copying files or opening and saving Libreoffice docs on the shares either...

JaSauders (jasauders) wrote :

I'm not sure if the issue I am facing is exactly the same or not, but I figured I'd chime in. In my case, copying a single large file works, but copying a dozen files 1-2MB in size (each) locks up when using Nautilus and GVFS. Oddly enough, I only have this issue on my Lenovo, not my Toshiba. The Lenovo is an AMD APU E450 unit, so it doesn't exactly have a ton of horsepower. It does however have 6GB of RAM and an SSD. My Toshiba on the other hand has a mobile i5, 6GB RAM, and SSD. So all things compared, they stack up against each other decently with the exception of the CPU. I have yet to have a successful transfer with multiple small files on the Lenovo. Meanwhile, the Toshiba works brilliantly each and every time. Both are running Ubuntu GNOME 13.04 64 bit, fully updated.

park (k3park) wrote :

I have Same Problem with version 1.16.3.-2
File transfer became very unstable compared to previous version
Sometimes could not find file regardless size
As a result Application which use gvfs-smb hanged

My Server running with samba
samba-3.6.9-151.el6.x86_64 in Centos with option max protocol = SMB2

Hope this bug will be assigned as soon

taj (othertaj) wrote :

Bug exists with Thunar in 13.04 64-bit up-to-date Xubuntu.
The bug likely also crashes libreoffice (3.x and 4.x) when it wants to save a file that you opened on the samba share. Workaround for that: save on the local drive and copy to the share afterwards. That may not work, but at least you'll have your document.

NB mount workaround will be a problem if you do not have root privileges. Then try FTP, or if you have dual boot save to a place where Windows can access your data. Then reboot and use Windows to copy to the shared drive.

gvfs-smb Bug #1075923 Workaround:

downgrade gvfs-* to Version 1.12 of 12.10 with:
- add /etc/apt/sources.list
deb http://de.archive.ubuntu.com/ubuntu precise main
deb-src http://de.archive.ubuntu.com/ubuntu precise main

- run: sudo apt-get update
- install synaptic: sudo apt-get install synaptic
- run synaptic: sudo synaptic
- remove all gvfs-* nautilus with synaptics
- search gvfs-*, select, press CTRL+E (Force Menu)
- select: gvfs-* Versions 1.12
- install by run install button
- search and install nautilus again..

Voila...Test Nautilus copy 1TB Files without freeze

Linuxonlinehelp_de: I tried to follow your steps and in the end when I commit the run button I get the following errors.
Can you please help me?

"
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Unable to correct dependencies
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Unable to correct dependencies
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Unable to correct dependencies
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Unable to correct dependencies
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Unable to correct dependencies
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Unable to correct dependencies
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Unable to correct dependencies
E: Unable to lock the download directory
"
I'm running Mint 15

Any help is appreciated.

@ Artyom Pavlichenko (artyompyandex)

check out with

dpkg -l | grep gvfs

that all versions and deps of gvfs-1.16 are removed !!!

then do changes and reinstall gvfs-1.12 (same default on Debian Wheezy)

i tested 2 Acer fresh installed Laptops P253-E

please mail me errors..

Remark: Possible that Mint uses more deps (added Programs/Libs) for gvfs than Default Ubuntu!!!!

Hope the Maintainer of gvfs solve this BIG Bug!!! Most People lost DATA if they save to Samba Servers!!!

Just triggered again now. Another nice feature of this bug: if you try to umount (force umount, whatever) the "locked" share, you will have the prompt (in my case, the gnome shell one) telling that is impossible because the share is busy. Ok. But pressing either "cancel" or "ignore, unount anyway" will simply re-pop-up the prompt. And givien that the darn prompt is modal, you are locked.
The only solution is ginfg to a VC and issuing killall gvfs-smb. But how many users will know this?
I understand that the big effort now is to have the ubuntu phone thing. But this is a really big issue. Please....

gerlos (gerlosgm) wrote :

I'm affected too, running Ubuntu 12.10.

Based on comment #43 I created a (a little) more friendly workaround for my users, based on a shell script prompting the user using zenity. I'm sharing it here, hoping it can be useful to someone. Hope we won't need it for a long time.

Consider that I'm using this script on PCs rurring in a office, where a Windows Server is always running, so I don't care about umounting the shares.

First time setup:
-----------------------
sudo mkdir /mnt/cifs

And then, for each user:
sudo mkdir /mnt/username
sudo chown username:users /mnt/username

Also added to sudoers a line like this (I know it may be a security hole):
%users ALL=NOPASSWD:/bin/mount

Here's the script, you will need to edit the list of shares in 3rd line and your domain in sixt line, and put it somewhere in your path:
#!/bin/bash
# MountShare.sh
SHARE=`zenity --list --text="Choose the share you want to mount" --column="Share" FirstShare SecondShare ThirdShare`
SUSER=`zenity --entry --text='Insert your user name' --entry-text=$USER`
SPASS=`zenity --password`
DOM='mydomain.net'

mkdir /mnt/cifs/$USER/$SHARE
sudo mount -t cifs -o user=$SUSER,pass=$SPASS,domain=$DOM -o uid=$USER \
    "//192.168.0.3/$SHARE" /mnt/cifs/$USER/$SHARE && \
    zenity --info --text="Share $SHARE mounted, look in /mnt/$USER/$SHARE" & \
    nautilus /mnt/cifs/$USER/$SHARE

Also created a .desktop launcher to make it easy to run this script:
#!/usr/bin/env xdg-open
[Desktop Entry]
Name=Mount Samba Shares
Comment=Mount shares from our server
Exec=MountShare.sh
Terminal=true
Icon=/usr/share/icons/Human/48x48/places/gnome-fs-smb.png
Type=Application
Categories=Network;FileTransfer;
Version=1.0

I leaved the option "Terminal=true" cause my user, that is in the sudo group, still get sudo password query (any tip?). This way I see the query and can answer to it.

Every time
----------------
To mount shares, it's enough that users double click on the .desktop launcher and provide the needed informations. In our network, it happens only once a day, and only when needed.

It's a temporary solution I hope we won't need. Anyway, any suggestion and tip is welcome.

eris23 (jdkatz23) wrote :

I have 2 machines running Saucy amd64 mixed Ubuntu/Xubuntu/Kubuntu/etc

Problem still exist with Nautilus, Nemo, PCManFM

gvfs 1.17.2-0ubuntu3

Dolphin works fine.

I've just installed Krusader to use as an alternative file handler when network access is required. It seems to work fine with my NAS, copying large directories (3 GB+) of photos (4 - 5 MB each) without trouble (although it does slow a bit towards the end). It will do until the gvfs problem is solved.

Before this solution, I played with Fedora 19.1 but it had the same problem so I didn't switch.

Sb (sb56637) wrote :

Just got bit by this bug. I have two laptops running 13.04. The faster one with an Intel Core I5 is running x86, and the slower one is running amd64. (I prefer x86, but the slower laptop had a different bug that prevented me from using x86.) The fast laptop doesn't have any Nautilus / Samba / GVFS problems, but the slow laptop is completely broken for file transfers. I don't know if this has to do with the speed or if 32bit vs 64bit makes the difference.

With regards to the workaround proposed in comment #171, thanks a lot for the tip, that version of GVFS solved the problem. However, the best way to implement the workaround is with APT pinning. To do this:

0. Add the Precise repos mentioned in comment #171

1. Create a file called "gvfs-pin" or whatever you want in /etc/apt/preferences.d

2. Edit /etc/apt/preferences/gvfs-pin as follows:
Package: gvfs*
Pin: release a=precise
Pin-Priority: 999

3. sudo apt-get upgrade

Claudio (claudio-fischer) wrote :

it has to do something with speed. I get this problem very often on my older PC (Dual Core 2.6 Ghz).
On my newer PC (Intel i7) I have to start a lot more videos or file transfers to get this.

adam (capes-adam) wrote :

+1 to the slow PC problem. My loan laptop is a celeron 1.6ghz, 2gb RAM. This is really inconvenient when I am using this laptop at school as I sometimes need to copy large shared folders to our hard drives for use out-of-school, and copying each file induvidually and recreating directory structures is very time consuming

Claudio (claudio-fischer) wrote :

Ross Lagerwall has done some fxes / patch to gvfs.
Copying large files should work better with this.

The patch can be added and tested as a ppa:
https://launchpad.net/~rosslagerwall/+archive/bugfixes

see also: GNOME Bugzilla – Bug 697782
https://bugzilla.gnome.org/show_bug.cgi?id=697782

Walter Ribeiro (wribeirojr) wrote :

Thanks, Claudio, for the info. And thank you Ross for the patch!!
I copied 2 GB of a shared folder of Windows without problems.
This was a serious issue of Ubuntu and now seems to be resolved.

Scott Moore (scottbomb) wrote :

I don't think it's just Nautilus. I'm having the same problem with Xubuntu 13.04 using Thunar.

Sebastien Bacher (seb128) wrote :

Thanks to Ross Lagerwall a fix was commited upstream:
https://git.gnome.org/browse/gvfs/patch/?id=bdc3babbe21e5fed06876db4d56d1b13915fe1cb

I've just uploaded to saucy and I'm going to SRU the fix to precise and raring next

Changed in gvfs (Ubuntu):
status: Triaged → Fix Committed
Changed in gvfs (Ubuntu Raring):
importance: Undecided → High
Changed in gvfs (Ubuntu Precise):
status: New → In Progress
Changed in gvfs (Ubuntu Raring):
status: New → In Progress
Changed in gvfs (Ubuntu Precise):
importance: Undecided → High
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gvfs - 1.18.1-0ubuntu2

---------------
gvfs (1.18.1-0ubuntu2) saucy; urgency=low

  * debian/patches/git_fix_hanging_jobs.patch:
    - "daemon: Emit signal before returning dbus value",
      that should fix the issues where nautilus copies of directories
      over samba hang after a while, thanks Ross Lagerwall (lp: #1075923)
 -- Sebastien Bacher <email address hidden> Mon, 30 Sep 2013 19:08:34 +0200

Changed in gvfs (Ubuntu):
status: Fix Committed → Fix Released
Changed in gvfs:
status: Confirmed → Fix Released

Thank you, Ross.

description: updated
description: updated

Hello Alessandro, or anyone else affected,

Accepted gvfs into raring-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gvfs/1.16.1-0ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in gvfs (Ubuntu Raring):
status: In Progress → Fix Committed
tags: added: verification-needed

Tested by moving and copying a directory of 64845 files - 47,7GB large, three times from and to my usual samba server.
No issues experienced, the bug is fixed for me.

The tested packages are gvfs, gvfs-fuse, gvfs-backends, gvfs-libs, gvfs-bin, gvfs-common, gvfs-daemons, all at version 1.16.1-0ubuntu1.1

tags: added: verification-done
removed: verification-needed
MadFranky (madfranky) wrote :

Look fine for me! :-)

Many thanks!

Everything works well for me after updating to version 1.16.1-0ubuntu1.1
I could download 1.7GB of photos from my camera without any trouble.

Scott Moore (scottbomb) wrote :

I enabled raring-proposed, updated, and tested it tonight with a large directory and I'm happy to say it works. The bug appears to have existed on the client side as no changes were made to the host system.

Thanks!

Sebastian Ilea (s3b4) wrote :

Ross Lagerwall's fix works for me too (Ubuntu 13.04 64 bit - using raring-proposed repository to update gvfs, gvfs-fuse, gvfs-common, gvfs-daemons, gvfs-bin, gvfs-libs and gvfs-backends to version 1.16.1-0ubuntu1.1).

I copied over LAN (from a Windows PC to a Ubuntu PC) around 40GB of pictures (more than 24.000 files) with no problems.

Thanks for the patch.

Sb (sb56637) wrote :

1.18.1 is working great for me on Arch, thank you SO MUCH for patching this extremely annoying bug.

tjboadwa (tjboadwa) wrote :

 I've been running Ubuntu for about 7 months now, and currently have 12.10 running on a Dell Precision M90. I am experiencing this problem with my NAS. The files copied fine but when I try to read or copy the other way (to my computer from the NAS) with large directories the Nautilus hangs.

Can someone give me step by step instructions on how to follow through on this fix? It is not entirely clear to me how to do this. One thing I should mention, I've only been into the command line a few times, so I'm pretty new to the Linux world.

Update to 13.10
On 15 Oct 2013 02:15, "tjboadwa" <email address hidden> wrote:

> I've been running Ubuntu for about 7 months now, and currently have
> 12.10 running on a Dell Precision M90. I am experiencing this problem
> with my NAS. The files copied fine but when I try to read or copy the
> other way (to my computer from the NAS) with large directories the
> Nautilus hangs.
>
> Can someone give me step by step instructions on how to follow through
> on this fix? It is not entirely clear to me how to do this. One thing
> I should mention, I've only been into the command line a few times, so
> I'm pretty new to the Linux world.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1077696).
> https://bugs.launchpad.net/bugs/1075923
>
> Title:
> nautilus hangs copying large directories from a samba share
>
> Status in GVFS:
> Fix Released
> Status in “gvfs” package in Ubuntu:
> Fix Released
> Status in “gvfs” source package in Precise:
> In Progress
> Status in “gvfs” source package in Raring:
> Fix Committed
>
> Bug description:
> Impact:
> copies from/to samba share often end up hanging
>
> Test case:
> - visit a smb location in nautilus
> - copies data from/to it (some non trivial directories makes the issues
> easier to trigger)
> - the copy should complete without hanging
>
> Regression potentiel:
> Check that nautilus is still working correctly and than you don't have
> issues copying data from/to remote locations
>
> ---
>
> Problem
> =======
> Copying files to and from samba shares (this includes Windows shares) is
> unreliable in Ubuntu 12.10 and Ubuntu 13.04 when using nautilus' integrated
> samba client (gvfs-smb): The copy randomly hangs after a few files or a few
> GB.
>
> Workaround
> ==========
> Until gvfs-smb is fixed, use the kernel samba client (cifs) that works
> reliably, is faster, but needs some terminal commands to get going:
> # sudo -s
> # mkdir /mnt/cifs
> # mount -t cifs -o user=YOUR_SAMBA_USER -o uid=YOUR_LINUX_USER
> "//SAMBA_SERVER/SAMBA_SHARE" /mnt/cifs
> It will ask for you password, you can then access the shared files at
> /mnt/cifs.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gvfs/+bug/1075923/+subscriptions
>

Andrei Shevchuk (shvchk) wrote :

tjboadwa, or you could write to package maintainer to update the package, see here: http://packages.ubuntu.com/quantal/gvfs

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gvfs - 1.16.1-0ubuntu1.1

---------------
gvfs (1.16.1-0ubuntu1.1) raring; urgency=low

  * debian/patches/git_fix_hanging_jobs.patch:
    - "daemon: Emit signal before returning dbus value",
      that should fix the issues where nautilus copies of directories
      over samba hang after a while, thanks Ross Lagerwall (lp: #1075923)
 -- Sebastien Bacher <email address hidden> Mon, 30 Sep 2013 19:47:06 +0200

Changed in gvfs (Ubuntu Raring):
status: Fix Committed → Fix Released

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Sebastien Bacher (seb128) wrote :

the issue doesn't affect the precise version

Changed in gvfs (Ubuntu Precise):
status: In Progress → Invalid
tjboadwa (tjboadwa) wrote :

Well I updated to 13.04 and checked Pre-Released. Works like a charm now either way.

Displaying first 40 and last 40 comments. View all 201 comments or add a comment.
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.