gvfs-smb: strange timeouts

[Javier Martin (Habbit)]

Binary package hint: gvfs-backends

The new gvfs backend system for Nautilus et al. in Hardy beta seems to have some problems browsing SMB shares (both Windows and Samba). I'm subscribing this just to gvfs-smb, but I haven't tested other network backends like ftp. The problem is as follows: trying to "enter" SMB shares from the network view in Nautilus or from a "mounted" share in the desktop nearly always times out. This didn't happen in older versions (with the gnomevfs backend), and does not happen with gnomevfs in Hardy, as shown:

With GNOMEVFS (works)
$ gnomevfs-ls smb://salon/Documents
. (Directory, x-directory/normal) size 0 mode 0755
.. (Directory, x-directory/normal) size 0 mode 0755
mythtv_config (Directory, x-directory/normal) size 0 mode 0755
StepMania-3.9 (Directory, x-directory/normal) size 0 mode 0755
mediacenter (Directory, x-directory/normal) size 0 mode 0755
mythtv.log (Regular, text/x-log) size 6785 mode 0644
docs (Directory, x-directory/normal) size 0 mode 0755

With GVFS (request additional mount step, which I figure is by design, but then times out)
$ gvfs-ls smb://salon/Documents
Error: La ubicación especificada no está montada (translation: specified location is not mounted)
$ gvfs-mount smb://salon/Documents
$ gvfs-ls smb://salon/Documents
Error: Expiró el tiempo de conexión (translation: connection timed out)

I can confirm this is _not_ due to users/credentials problems, as I control both machines and have adjusted all required permissions.

Release: Ubuntu hardy (development branch) 8.04 - i.e. Hardy beta
gvfs-backends version: 0.2.2-1 (last available)
Expected behaviour: system lists files in SMB share, as old gnomevfs did
Actual behaviour: "connection timeout" error

[Sebastien Bacher (seb128)]

Thank you for your bug report. What smb server do you use? Does it work every time or can you use it sometimes? Could you run /usr/lib/gvfs/gvfsd -r on a command line, try yo mount and use the share and copy to a comment what is displayed there?

[Javier Martin (Habbit) (habbit)]

In addition to the computer I'm testing from, there are two SMB servers: "salon" (Mythbuntu Hardy beta i686, Samba) and my brother's computer (Windows XP Pro SP2 32 bits). Running gvfsd on a terminal and then running the command-line gvfs-* apps seems to work most of the time, sometimes immediately, sometimes with a ~20 seconds delay, though I still get the occasional timeout. This* is exceptionally bad performance, since the experiment is performed on a completely good, low-traffic LAN and gnomevfs-* utils work all right. This makes /me think the issue might be at least partially related to local DBUS connections from Nautilus to gvfsd, or between the gvfs daemons, but I don't really know the architecture.

The output of the gvfsd instance showed nothing related to the timeouts - there were just two lines per mount request

Added new job source 0x644060 (GVfsBackendSmb)
Queued new job 0x644830 (GVfsJobMount)

*Side note: I did not kill the running gvfsd instance, nor start my own as root, just run the command you asked as my user. Do you want me to kill the running gvfsd and redo the experiment in order to check if the timeouts still happen?

[Javier Martin (Habbit) (habbit)]

Update: the delays and timeouts still happen, even if I kill the running gvfsd/gvfsd-smb instance and let just my own. The delays are ~20 seconds compared to the ~1.5 secs gnomevfs-ls (i.e. the old VFS backend) takes to successfully display contents. No new output in the terminal-borne gvfsd instance.

[Sebastien Bacher (seb128)]

now the description is confusing, do you get a delay or do you get timeout? those are different things and a bug should describe only one issue

[Javier Martin (Habbit) (habbit)]

Both: depending on (apparently) whether the current microfortnight is even or odd, gvfs-ls shows the contents of the SMB share after about ~20 secs, or it just times out. If I get really, really lucky (i.e. when the current ufn is a multiple of 42), it works correctly without delays. All of this could be adscribed to a faulty server or network, but as I said, performing the same tests with gnomevfs-ls (which is unrelated to the new gvfs framework) or just mounting the share with mount.cifs (also unrelated to gvfs) and browsing it, the requested operation is always completed successfully in under 3 seconds. This makes me think the error is in the gvfs framework, possibly the communication system it uses (dbus), but I might be wrong.

[Sebastien Bacher (seb128)]

could you try running gvfsd-smb manually and see if there is any issue there? could you also attach .xsession-errors, messages and syslog when getting the issue?

[Javier Martin (Habbit) (habbit)]

Did so, and the results are basically non. Turns out that gvfsd-smb is not to be run manually (request some "key-value pairs"). On the other hand, .xsession-errors, dmesg, /var/log/messages and /var/log/syslog say nothing about gvfs*, smb*, cifs* or whatever related to the problem.

[Sebastien Bacher (seb128)]

not really an useful bug, could you attach the log anyway, maybe you have some dbus, network, etc issue on your box? could you try using ssh and see if you get the same issues there? are local copies, etc working correctly?

[Javier Martin (Habbit) (habbit)]

1) The log: there is just nothing there! in "messages", there are a lot of --MARK-- messages each 20 mins or so, while "syslog" contains some pulseaudio errors, the hourly run of cron and more --MARK--s.
2) DBUS issues: any possible issue would have been brought by the Hardy beta upgrade. Furthermore, HAL (which is also based on DBUS) works fine
3) Network issues: no sugar. As I said, using anything other than gvfs/nautilus for browsing it works fine - gnomevfs, mount.cifs, xsmbrowser... So no network problems
4) Going to the other box: no need to run ssh, I could do it locally. However, that box uses Mythbuntu, so no gvfs to toy with (and I don't feel like installing a nonworking app on a working computer)
5) Local copies et al work correctly, yes. Even big files are copied OK between other gvfs backends (i.e. trash, burn, ftp...)

The strange thing with this is that _sometimes_ it works and sometimes it doesn't. A thing, however, that always fails is copying large files over SMB, even when browsing had previously worked. This might indicate that gvfsd-smb may have a problem with bulk transfers. Concretely, after 5~10 MiB, the transfer stops and can't even be cancelled without killing gvfsd-smb. An analysis with Wireshark reveals that it's my Ubuntu box the one that stopped requesting data, not the Windows box who stopped serving them, and the last messages exchanged don't reveal anything special (no errors, etc).

[Sebastien Bacher (seb128)]

could you try to use ssh locations on the box you are using to try gvfs smb? you should have gvfs and ssh installed there no? could you also try to attach gdb to gvfsd-smb after the mount and note if it's crashing or something when the copy breaks?

[Sebastien Bacher (seb128)]

you can run gvfsd-smb server=server_name share=share_name if the share is an anonymous one

[Javier Martin (Habbit) (habbit)]

Big sigh. Updated everything to the latest version (35 updated today, wow) and results here:

* Yes, SSH connections, or any kind of gvfs backend _other than_ smb works OK: ftp, ssh, burn, etc.
* I attached gdb to gvfsd-smb and started a big file copy (which miraculously completed successfully -_-), then turned to browse another SMB share on the same box and the lovely delays were once again there - even worse, but maybe that can be attached to running with the debugger. Finally, the magic timeout error. Apart from some new-thread, thread-exited messages on file copies, and a SIGPIPE on a copy cancellation, there is no GDB output whatsoever, not even when the "timeout" error happened.
* I can't run gvfsd-smb CLI because I have no anonymous shares, nor the will to open them, since this network is heavily Internet-exposed. Besides, I'm in the middle of an exam week and have nearly no free time.
* Once again, none in dmesg, syslog or messages

[Javier Martin (Habbit) (habbit)]

Once again, updated everything to the latest version in the repositories. The problem has been reduced from ~90% of SMB access trials to about ~50%, but big file copies are still impossible, as they hang after about 8 MiB (hang as in have-to-kill-gvfsd-smb-to-remove-stuck-dialog).

I've rerun gvfsd-smb in gdb but there are no news: threads are created sometimes; successful accesses write nothing in any log, while timeouts make gdb print a "thread 0xhexnum (LWP nnnn) exited" message. Sometimes Nautilus hangs during accesses, sometimes it does not, which is making this painfully difficult to diagnose, since I don't know where to f*** point the debugger at!! I have even had moments where not just the active Nautilus window, but gnome-panel and the Desktop would hang, which makes me reinforce my hypothesis that this has something to do with the communications between the daemons, since how could several programs hang at once else than trying to communicate with the same, hung, daemon?.

By the way, has any of this been forwarded upstream? I understand that I and the submitter of bug #210746 seem to be the only ones with this problem, but still... This computer was running pretty fine before updating to Hardy beta (lucky it's not a production computer) except for the video drivers, which I think don't have anything to do with this. Besides, gvfs is a newly installed program AND gnomevfs apps work perfectly smooth (i.e. I can play a song through SMB in Totem, with still uses gnomevfs, while gvfsd-smb is timing out trying to access the same share) so this is even weirder.

[Sebastien Bacher (seb128)]

no, the bug has not been forwarded upstream, you are the only to get the issue and there is not enough detail to make it useful

[Sebastien Bacher (seb128)]

you are welcome to send the bug upstream though, since you are the one getting the issue you can reply to their questions

[Javier Martin (Habbit) (habbit)]

Ludicrous. AFAIK there is at least another person with this problem,
bug #210746, which is _also_ tagged as "incomplete" even though the
submitter did everything you asked from him/her and nobody has
answered in a week. But it's OK, I don't want to start the typical
"this is why Linux/Ubuntu/GNOME will not (whatever)" flame. Just tell
me where to report this bug upstream and I'll be gone. So long and
thanks for all the fish.

2008/4/14, Sebastien Bacher <email address hidden>:
> you are welcome to send the bug upstream though, since you are the one
> getting the issue you can reply to their questions
>
>
> --
> gvfs-smb: strange timeouts
> https://bugs.launchpad.net/bugs/209271
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Sebastien Bacher (seb128)]

The upstream bug tracker is bugzilla.gnome.org, you can start a discussion about why a very small team is not able to fix thousand of issues a week on code they didn't write but that's not going to bring a lot there. Those bugs are not trivial, we don't have gvfs hackers in the team and the standard debug informations show nothing weird, that would probably require somebody having the issue to debug those

[Simage (simage)]

Just a quick note that I'm running into the same problem with large file transfers laptop is running hardy heron, desktop is running gusty gibbon. any large file transfer in Nautilus (>~200 MB) will time out, downloading with SMB client works with no problems. Haven't done any real digging into the problem yet. figured I'd let it be known that the problem is still out there tho.

[Javier Martin (Habbit) (habbit)]

I think I have pinpointed the problem: after a clean reinstall Ubuntu Hardy, the gvfs samba client worked flawlessly until I added the "wins" option to the "hosts" line in /etc/nsswitch.conf in order to make firefox able to resolve netbios names in the workgroup. Then, the timeouts appeared again. I removed the "wins" option and back to joy. Does this make any sense?

[Javier Martin (Habbit) (habbit)]

Reopening, new data added

[Philip Peitsch (philip-peitsch)]

Habbit, the timeouts can also be avoided by using the ip-address rather than the hostname. Strange how this is not working

[Philip Peitsch (philip-peitsch)]

Check out: http://mail.gnome.org/archives/gvfs-list/2008-May/msg00005.html

Specifically:

- we have username, domain, server and share parameters available to be
set into mountspec. However username and domain shouldn't be set unless
we really need them. At the moment, non-anonymous mounts have both
username and domain set which confuses Nautilus.
This causes troubles when user gvfs-mount's smb://server/share but
gvfs-ls can't find this location mounted then because it has username
and domain set in mountspec.

[mike morrison (mike-morrison)]

I had the same issue as described here. Bug #259978 (which i'd say is a duplicate of this bug) contains a workaround.

[Sebastien Bacher (seb128)]

does anybody still get the issue in intrepid?

[Sebastien Bacher (seb128)]

could the people having the issue attach their smb.conf to the bug?

[Sebastien Bacher (seb128)]

We are closing this bug report as it lacks the information, described in the previous comments, we need to investigate the problem further. However, please reopen it if you can give us the missing information and don't hesitate to submit bug reports in the future.