GNOME Bugzilla – Bug 332738
sftp to a remote home directory freezes Nautilus
Last modified: 2010-04-27 11:19:40 UTC
Please describe the problem: For a year, I had no problems sftp'ing with Nautilus (run as: nautilus --no-desktop --browser) to my home directories at remote servers. But about 2 months ago, after a standard Debian unstable update/upgrade, I lost this functionality (nautilus would freeze, requiring me to kill it). I did find a work-around: first sftp to the server without reference to any directories, then after successfully logging-in, navigate to my home directory. In other words, if I put something like the following in the location bar, nautilus fails: sftp://gnaural@banjo.bob.net/home01/g1/gnaural But if I put this in, nautilus will indeed log-in: sftp://gnaural@banjo.bob.net , at which point I can navigate manually to my home directory. So my solution for the past two months has been to have two bookmarks -- one to the root of the server, the second to my directory, which I can call in sequential order. Seems like the bug may be either in how Nautilus is accessing my security keyring, or in the security keyring system itself; I don't actually know what that subsystem is, however. It is whatever the default in Gnome on Debian Unstable is. Steps to reproduce: 1. Put an sftp link directly to a remote home directory in location bar, like: sftp://gnaural@banjo.bob.net/home07/g1/gnaural 2. Hit enter. 3. Nautilus should be frozen now Actual results: nautilus stops updating it's windows, and after a few minutes I click in the window manager x box and wait for the "do you want to force nautilus to quit" dialog. Expected results: for the previous year (until two months ago, when a standard Debian apt-get update/upgrade seemed to introduce this problem), I would just land in my remote home directory. Interestingly, an Ubuntu installation I also use hasn't experienced this problem yet. Does this happen every time? If I first log directly in to the server (with no reference to any home directory, or any directory), it won't happen. But yes, it will happen every time otherwise. Other information: This functionality failed at around the same time that I notice right-clicking a folder in Nautilus and selecting "Create Archive..." forced it to bring up the dialog to unlog the keyring; in general, the new strange behaviors seem related to security/keyring accessing bugs.
I don't see this when i try to access a sftp machine on the local network. Do you get this with all ssh servers? Could you try to get a backtrace from gdb when nautilus is hanged? (http://live.gnome.org/GettingTraces has some details on how to do this)
(In reply to comment #1) > Do you get this with all ssh servers? Well, I would have answered yes, since it happens with all remote servers I've tried (basically sourceforge and servers around the university I work at)... But just now I did try sftp'ing with a full-path address to my own machine (both as "localhost" and with the actual IP number) -- which worked fine. > Could you try to get a backtrace from gdb when nautilus is hanged? By launching nautilus then attaching to the sole Nautilus process, here is everything that comes out: gnaural@debia:~$ gdb /usr/bin/nautilus 13073 GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". Attaching to program: /usr/bin/nautilus, process 13073 Reading symbols from /usr/lib/libnautilus-extension.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libnautilus-extension.so.1 Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread -1493899584 (LWP 13073)] [New Thread -1494778960 (LWP 13074)] (NOTE: Rest of "Loaded symbols/Reading symbols" text deleted for brevity) (gdb) continue Continuing. (NOTE: at this point I go the the open Nautilus window and try a bookmark to a remote server) [New Thread -1510999120 (LWP 14316)] [New Thread -1500537936 (LWP 14317)] [Thread -1510999120 (LWP 14316) exited] (NOTE: Nautilus is now frozen. Hitting Ctrl-C in gdb offers this:) Program received signal SIGINT, Interrupt. [Switching to Thread -1493457216 (LWP 14555)] 0xa7f91199 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 (gdb) continue Continuing. (nothing. Hitting Ctrl-C in gdb again:) Program received signal SIGINT, Interrupt. 0xa7f91199 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 (gdb)
alexl, Gnaural, I can confirm this problem too. I can reproduce it on Fedora Core 5 and Ubuntu 6.06.1 all of them with the latest updates as of today. Because of this I am pretty sure the bug is upstream and not distro specific. The way I trigger this bug is very similar as Gnaural said: Create a link to an specific directory inside an ssh server, then logout Gnome (or maybe reboot), then try to access the link... Nautilus hang. There are a couple of details I want to add to the original report: 1. This doesn't happen with some others protocols, for example smb:// 2. If you use the workaround of navigating the root server first then the link it will always work going directly to the link afterwards. Because of point 2 I think alexl wasn't unable to reproduce the bug himself, I am pretty sure the bug is reproducible everywhere, just logout and come back in (I rebooted though). It happens every time you try to access a different directory inside an ssh server instead of the root directory the first time you authenticate with the server. I think we should bump the Gnome version because I can see this with Gnome 2.14 Hope this helps, -William
Gnaural, is this still happening to you? I tested this with Fedora 8 and it doesn't happen anymore. Alex, I think it is safe to close this bug. Cheers.
I also have this bug on Ubuntu 8.04. I find that it randomly freezes when I go to SFTP URL's...I have to force quit on it when this happens.
Becker, if you follow the workaround I posted in comment #3, does it work for you? To be honest I don't see this problem anymore, I am using Fedora 8 btw.
Interesting theory, let me try that.
At first it seemed like it worked, but closing / reopening the folders a couple times reproduced the error....bumber.
What version of nautilus are you using?? I guess it's 2.22. Can you try using a Fedora 9 Live CD?? it ships the same version. Besides, can you give us an example of the SFTP URLs you are using? can you use ssh or scp on the command line without any problem?? Other thing you could try is to use strace on the nautilus process this way: $ strace -p <pid-of-nautilus> Look carefully to the output, it might give you some clues. Cheers.
I tried using the root of a url as suggested earlier, didn't work...same thing after some sporadic openings and closings between two SFTP links, at some point it locks up. SSH works good, so does rsync. The url is like sftp://bbecker@machine/. I usually have 2-4 freezes a day within 10 accesses, usually when i try to open up more than 1 SFTs to 2 different machines. I can try the strace idea...
This is probably fixed with the transition to GIO. Please reopen the bug if you can still reproduce it with a recent (>= 2.28) Nautilus and GNOME, thanks.