mounted samba share stops working for file access

Bug #1077696 reported by AndreK on 2012-11-11
This bug affects 42 people
Affects Status Importance Assigned to Milestone
gvfs (Ubuntu)

Bug Description

Ubuntu 12.10 - same problem when acessing SMB shares from two computers
same for shares both on Ubuntu 12.10 server, and a windows server.

it helps if you play a video/movie using vlc or mplayer from share. the file should be open for hours. (use pause)
- when unpaused, the file will play fine.
-no new big files on that share will open, small files may work.
unmounting + remounting the SMB share may fixe the problem, but other processes may be affected:
VLC - while stuck with such samba problem, is impossible to kill, same for smplayer
sudo killall vlc -s KILL
.. will not kill it.
and so unmounting the share takes >10 attempts..

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: gvfs-backends 1.14.0-0ubuntu6
ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7
Uname: Linux 3.5.0-18-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.6.1-0ubuntu6
Architecture: amd64
Date: Sun Nov 11 20:30:49 2012
ExecutablePath: /usr/lib/gvfs/gvfsd-smb
MarkForUpload: True
 PATH=(custom, no user)
SourcePackage: gvfs
UpgradeStatus: Upgraded to quantal on 2012-10-17 (25 days ago)

AndreK (andre-k) wrote :
Jussi H. (jussi-h) wrote :

I'm using quantal 12.10 and gvfs 1.14

I have the same problem you can't kill VLC when it gets stuck which happens about 50% of the you try to start video.
Same happens with GNOME mplayer if you open two of them to play same file.
Only way to kill all stuck processes is to kill gvfsd-smb.
Tried upgrading fuse to 2.9.2 since it has some kind deadlock fixes. I though gvfsd-smb used fuse but building fuse and upgrading it to 2.9.2 didn't help.

gvfsd-fuse seems to be stuck as well. Because if i try to kill gvfsd-fuse it doesn't get killed until gvfsd-smb is killed.

Stack traces.


[<ffffffff810aacfd>] futex_wait_queue_me+0xcd/0x100
[<ffffffff810ab49c>] futex_wait+0x19c/0x2d0
[<ffffffff810ad46c>] do_futex+0x11c/0xa40
[<ffffffff810ade1d>] sys_futex+0x8d/0x190
[<ffffffff81689d29>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff


[<ffffffff81194549>] poll_schedule_timeout+0x49/0x70
[<ffffffff81195b9a>] do_sys_poll+0x3ba/0x4d0
[<ffffffff81195d8b>] sys_poll+0x6b/0x100
[<ffffffff81689d29>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff

Launchpad Janitor (janitor) wrote :

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

Changed in gvfs (Ubuntu):
status: New → Confirmed
Jussi H. (jussi-h) wrote :

Like to add that VLC and GNOME mplayer accesing same file doesn't always deadlock but deadlocks most of the time.
My laptop is dual core, this deadlock might not happen with single core computer.

AndreK (andre-k) wrote :

Also: I've never seen this problem on 11.04 32bit. It started the day I upgraded.

Jussi H. (jussi-h) wrote :

I'm also using 64bit ubuntu.

Jussi H. (jussi-h) wrote :

Tried ubuntu 12.10 32bit and gvfs-1.14.0-0ubuntu6 and same problem exists. Vlc and Gnome MPlayer still hangs still hangs when trying to play same file. Only way to kill processes is to kill gvfsd-smb. VLC sometimes hangs when just playing one file, maybe it accesses same file from multiple threads?

[<c109974f>] futex_wait_queue_me+0xcf/0xf0
[<c1099ded>] futex_wait+0x16d/0x270
[<c109b8f2>] do_futex+0x112/0x910
[<c109c170>] sys_futex+0x80/0x130
[<c15d14df>] sysenter_do_call+0x12/0x28
[<ffffffff>] 0xffffffff

[<c115f647>] poll_schedule_timeout+0x37/0x60
[<c1160840>] do_sys_poll+0x310/0x430
[<c1160a0a>] sys_poll+0x5a/0xd0
[<c15d14df>] sysenter_do_call+0x12/0x28
[<ffffffff>] 0xffffffff

AndreK (andre-k) wrote :

when I wrote "Also: I've never seen this problem on 11.04 32bit. It started the day I upgraded."
it was 12.04 - not 11.04.

Jussi H. (jussi-h) wrote :

I tested this problem on Linux Mint 13 based on Ubuntu 12.04 and with gvfs 1.12.1-0ubuntu1.1 and this bug is not there. Eveything works, so something must have changed between ubuntu 12.04 and 12.10.
This bug is also in Linux Mint 14 RC based on Ubuntu 12.10.

bwat47 (bwat47) wrote :

I've seen this problem on a fresh install of 12.10. It doesn't happen often but when it does its impossible for me to kill vlc or unmount the share, I have to log out and back in.

I've found a good workaround to avoid the bug completely though (this work around also fixes a separate problem with vlc, where videos played from mounted smb shares do not respect VLC's network buffer setting, because vlc treats videos opened via gvfs as local files). Instead of double clicking the video in nautilus, drag and drop the video into vlc. Doing this uses vlc's inbuilt smb access module instead of gvfs. Note: for this to work you probably need to go into vlc's settings and fill in your smb username and password (tools > preferences > all > input and codecs > access modules > SMB)

Rob Tongue (robtongue) wrote :

I have this as well but not with VLC. When using anything that isn't aware of the workings of fuse/gvfs, so it relies on the mounted folder that it creates. With things like Shotwell, MusicBrainz Picard, etc, after a few minutes of doing its thing importing stuff, gvfsd-fuse and all associated processes keel over on me and cannot be killed. Seems there are some sys calls that are confusing it that these apps may use. I can provide any info that is needed, as long as I know how to retrieve it.

Solomoriah (chris-gonnerman) wrote :

I'm experiencing this with a new install. Lubuntu 12.10, fully updated, 64 bit. Seems to happen any time a "large" amount of data is copied; generally, it copies one whole file, maybe two, then hangs up. I've even tested with a gvfs-smb mount using cp from the command line, same results, the cp becomes unkillable after a file or two.

Solomoriah (chris-gonnerman) wrote :

Addendum: mount.cifs on the same machine, no problem, so definitely a gvfs or fuse problem.

Steven Parks (stevenparks58) wrote :

Confirmed on Linux Mint 14. Application hangs in "read" call, cannot kill the process.
File is samba share mounted with fuse.
Was able to open, read and close a few files before hang occured. Happens every time.

Phil Abbott (abbott-pa) wrote :

I'm assuming this bug is the reason why neither banshee, rhymbox or clemetine can import my smb mounted music libary.

All either hang, after partially importing a few songs from a few albums.

Download full text (3.3 KiB)

I have a very similar hang when copying files. After a few files copied, it hangs. Forever. I have a kernel warning stack trace:

Dec 21 19:30:29 romano-asus kernel: [ 5760.344269] INFO: task cp:4312 blocked for more than 120 seconds.
Dec 21 19:30:29 romano-asus kernel: [ 5760.348136] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 21 19:30:29 romano-asus kernel: [ 5760.352336] cp D c1075e1e 0 4312 4279 0x00000004
Dec 21 19:30:29 romano-asus kernel: [ 5760.352359] f0b1dd4c 00000046 f0b1dcf4 c1075e1e 3528f000 c183f240 f09ec000 000004cb
Dec 21 19:30:29 romano-asus kernel: [ 5760.352384] c196be00 c196be00 00000000 000004cb f6bece00 eef732c0 f0b1dd20 c106d6c5
Dec 21 19:30:29 romano-asus kernel: [ 5760.352405] 00000000 00000000 00000003 ee152c34 f0b1dd20 00000296 f0b1dd24 c1037af8
Dec 21 19:30:29 romano-asus kernel: [ 5760.352425] Call Trace:
Dec 21 19:30:29 romano-asus kernel: [ 5760.352448] [<c1075e1e>] ? try_to_wake_up+0x18e/0x230
Dec 21 19:30:29 romano-asus kernel: [ 5760.352463] [<c106d6c5>] ? __wake_up_common+0x45/0x70
Dec 21 19:30:29 romano-asus kernel: [ 5760.352477] [<c1037af8>] ? default_spin_lock_flags+0x8/0x10
Dec 21 19:30:29 romano-asus kernel: [ 5760.352491] [<c15ca49d>] ? _raw_spin_lock_irqsave+0x2d/0x40
Dec 21 19:30:29 romano-asus kernel: [ 5760.352503] [<c10657dc>] ? prepare_to_wait+0x4c/0x80
Dec 21 19:30:29 romano-asus kernel: [ 5760.352514] [<c15c95d3>] schedule+0x23/0x60
Dec 21 19:30:29 romano-asus kernel: [ 5760.352528] [<c123d885>] fuse_request_send+0xd5/0x290
Dec 21 19:30:29 romano-asus kernel: [ 5760.352541] [<c12e184c>] ? __percpu_counter_add+0x8c/0xb0
Dec 21 19:30:29 romano-asus kernel: [ 5760.352552] [<c1065580>] ? finish_wait+0x70/0x70
Dec 21 19:30:29 romano-asus kernel: [ 5760.352564] [<c1244c1e>] fuse_flush+0xce/0x120
Dec 21 19:30:29 romano-asus kernel: [ 5760.352577] [<c114c623>] filp_close+0x33/0x80
Dec 21 19:30:29 romano-asus kernel: [ 5760.352589] [<c1049b65>] put_files_struct+0x75/0xc0
Dec 21 19:30:29 romano-asus kernel: [ 5760.352600] [<c1049c56>] exit_files+0x46/0x60
Dec 21 19:30:29 romano-asus kernel: [ 5760.352611] [<c104a09a>] do_exit+0x14a/0x7a0
Dec 21 19:30:29 romano-asus kernel: [ 5760.352624] [<c110333f>] ? generic_file_aio_read+0x49f/0x740
Dec 21 19:30:29 romano-asus kernel: [ 5760.352636] [<c1056837>] ? recalc_sigpending+0x17/0x50
Dec 21 19:30:29 romano-asus kernel: [ 5760.352647] [<c1056ae2>] ? dequeue_signal+0x32/0x180
Dec 21 19:30:29 romano-asus kernel: [ 5760.352658] [<c104a994>] do_group_exit+0x34/0xa0
Dec 21 19:30:29 romano-asus kernel: [ 5760.352670] [<c1058c05>] get_signal_to_deliver+0x175/0x5a0
Dec 21 19:30:29 romano-asus kernel: [ 5760.352683] [<c115c5bf>] ? path_openat+0xcf/0x380
Dec 21 19:30:29 romano-asus kernel: [ 5760.352696] [<c101049d>] do_signal+0x2d/0x890
Dec 21 19:30:29 romano-asus kernel: [ 5760.352709] [<c114ed03>] ? rw_verify_area+0x63/0x110
Dec 21 19:30:29 romano-asus kernel: [ 5760.352721] [<c114e620>] ? do_sync_write+0xf0/0xf0
Dec 21 19:30:29 romano-asus kernel: [ 5760.352732] [<c114f1e9>] ? vfs_read+0x89/0x160
Dec 21 19:30:29 romano-asus kernel: [ 5760.352744] [<c114e620>] ? do_sync_write+0xf0/0xf0...


I can confirm that mount.cifs seems to work ok. Gvfs problem. Anyone listening? I am available (well, after Xmas holidays) to help in debugging.

AndreK (andre-k) wrote :

while canonical likes corporate users, paying support, I am surprised how long this bug is left unfixed - SMB bug is a real killer for many corporate uses..

Thomas Barandon (anapivirtua) wrote :

Same problem.
Running version 1.14.0-0ubuntu6 (under mint 14 kernel 3.7).

description: updated
Joao Serras (jserras) wrote :

I have the same problems when using VLC, sometimes it opens a video ok, sometimes it just hangs there, cant close or kill it, but i found that if i unmount it VLC closes.

Running version 1.14.0-0ubuntu6 (under mint 14 kernel 3.5).

This bug affect me in a Ubuntu 12.10 / Mint 14 network. It has become impossible to play movies from one computer to the other over Samba. I'm using both Nautilus and Nemo. Same problem with both.

apinunt (apinunt) wrote :

Same here, both Totem and VLC fail to play videos off my NAS drive, and Totem cannot be killed but VLC can be killed but remains shown as a zombie. The NAS drive cannot be unmounted as it shows in use by Totem, and I have to reboot to clear that.

Why is /home/user/.gvfs no longer used and instead /run/user/user/gvfs/ used to display the mount?

This is a very major problem for me in how my systems are used, so hopefully it will get some attention quickly.

Nicolas Binkowski (argonnate) wrote :

Same problem for me..

I'm on linux Mint 14. All of my movies are on my NAS. I open Nemo, go on my NAS and play one of my movies.

With VLC, the first play work fine. I can close vlc. If i start another movie, vlc start but don't play movie. I can't kill vlc (me too sudo killall vlc -s KILL don't work :/) and i can't unmount share folder... gvfsd-fuse use the share...

with totem, same problem...

Joey Perry (zimmatic) wrote :

Same problem for me, and also affects playing flac/mp3 off a windows share with Audacious. Usually I can kill the task, but it stays around zombified. Started after the upgrade from 12.04 -> 12.10.

Alexandre BELLONI (abelloni) wrote :

Hum, I don't believe this is a duplicate of bug #1075923. I have the issue using vlc but I can copy multiple Gbs of data to/from my NAS without any issue.

Junki Kizuka (k-falconws) wrote :

>Alexandre BELLONI (abelloni)
I think so too. Don't duplicate it.
My enviroment of the same you.

cholldorff (cholldorff) wrote :

This also affects me on Xubuntu 13.04 :(
Solution in #10 works, though.

Junki Kizuka (k-falconws) wrote :

When will fix this bug ?
Is Ubuntu 13.10 include this bug fix ?

I am quite sure that this is a duplicate of

It seems fixed --- I cannot test it myself now.

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

Other bug subscribers