GNOME Bugzilla – Bug 612202
gvfsd-smb-brows uses 100% cpu after selecting Places-->Network
Last modified: 2014-08-13 20:31:43 UTC
When I select Places-Network and then double click the "Windows Network" directory I get a pop-up saying: "Opening Windows Network You can stop this operation by clicking cancel. CPU usage goes up to 100% (gvfsd-smb-brows is causing this). It does not matter how long I wait, nothing changes. When I click cancel on the dialog, the dialog goes away but CPU stays at 100%. After a really long time (20 minutes) I get the following dialog: Unable to mount location DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. If I click on OK on that dialog it goes away but CPU stays at 100%. So I can't enter the windows network and CPU usage is 100%. ProblemType: Bug Architecture: amd64 Date: Thu Mar 4 18:02:42 2010 DistroRelease: Ubuntu 10.04 EcryptfsInUse: Yes InstallationMedia: Error: [Errno 13] Permission denied: '/var/log/installer/media-info' Package: samba (not installed) ProcEnviron: LANG=en_US.utf8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.32-15.22-generic RelatedPackageVersions: nautilus 1:2.29.91-0ubuntu2 gvfs 1.5.4-0ubuntu1 SambaClientRegression: Yes SourcePackage: samba Uname: Linux 2.6.32-15-generic x86_64 Did this use to work properly with a previous release ? This was never tested. dpkg-query -W -f='${Package} ${Version} ${Source} ${Status}\n' | grep samba: libsmbclient 2:3.4.6~dfsg-1ubuntu1 samba install ok installed libsmbclient-dev 2:3.4.6~dfsg-1ubuntu1 samba install ok installed libwbclient0 2:3.4.6~dfsg-1ubuntu1 samba install ok installed samba-common 2:3.4.6~dfsg-1ubuntu1 samba install ok installed samba-common-bin 2:3.4.6~dfsg-1ubuntu1 samba install ok installed smbclient 2:3.4.6~dfsg-1ubuntu1 samba install ok installed How is the remote share accessed from the Ubuntu system? nautilus Connecting with smbclient this works smbclient -L //: Domain=[EBOX] OS=[Unix] Server=[Samba 3.4.0]
Check: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/532024 for more info
*** Bug 612199 has been marked as a duplicate of this bug. ***
I confirm this bug, actually all gvfsd-smb-xxxx modules are affected.
UPDATE: After some further testing I discovered that this problem only occurs when trying to connect to password protected samba shares !!!! On samba shares without password protection everything works fine.
This problem can be easily reproduced. On a NAS or a server create three shared folders, one without password protection and two with password protection. In Seahorse delete all existing keys for those shared folders, if they already exist. 1) Open the share without password protection. Samba will open it without problems; 2) Open one of the password protected shares. Seahorse will ask for a username and password. Enter both and Samba will open the share; 3) Now open the second password protected share. A message will pop up and nvfsd-smb-browse and nvfsd-smb go in an endless loop with a 100% CPU load; 4) Kill the nvfsd-smb processes; 5) Delete the key in Seahorse; 6) Go to step 3 and you'll see that the misery starts again; I can reproduce this behaviour on a Thinkpad R50e, R51 and R52. And on a HP Pavillion and dx2400 miniATX.
For me it even happens when I try to open location: "smb:///"
I can't reproduce the issue on my system, can you please attach a backtrace of the failing process?
I have this in Ubuntu 10.04 with libgnome-keyring 2.30.0 . It seems to work too when connecting to a samba protected share, but is does not when using a save password option. So it seems there is a keyring problem: either nautilus does not save properly to th keyring or fetches it improperly (or both). Hope this helps any1! If you need more info from my part, please let me know.
please note that for me the error shows up in a few seconds, not 20 minutes. I do not know where to check the cpu usage, top shows nothing strange.
Isn't this related to bug 606902 and bug 611584 ?
Yes, this does appear to be a duplicate. *** This bug has been marked as a duplicate of bug 606902 ***