Description of problem: Not possible to see samba share in Nautilus. Write smb: into location. Then "Windows Network" appears in header. Wait over 10 seconds and then error window comes. Version-Release number of selected component (if applicable): samba-3.5.1-58.fc13.x86_64 system-config-samba-1.2.86-1.fc13.noarch samba-winbind-clients-3.5.1-58.fc13.x86_64 samba-common-3.5.1-58.fc13.x86_64 selinux-policy-3.7.11-1.fc13.noarch libselinux-2.0.90-5.fc13.x86_64 libselinux-utils-2.0.90-5.fc13.x86_64 selinux-policy-targeted-3.7.11-1.fc13.noarch libselinux-python-2.0.90-5.fc13.x86_64 How reproducible: Always Steps to Reproduce: 1. Open Nautilus and Ctrl+l 2. Write smb: into Lotstion 3. Wait over 10 seconds and error window The folder contents could not be displayed. Actual results: Error window The folder contents could not be displayed. Sorry, could not display all the contents of "Windows Network": 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. Expected results: To see enabeld samba shares There is local sama share Additional info: Just rebooted to reapply selinux policy There is no message in /var/log/messages It is possible to see local samba share form another computer ( F12 )
Created attachment 399847 [details] messages after settin selinux in permissive mode When setting selinux in permissive mode then it possible to see local samba share but not open it.
Can you check your firewall settings are not blocking samba client packetes ?
>Can you check your firewall settings are not blocking samba client packetes ? samba and samba client are marked as trusted. Fierwall disabled The folder contents could not be displayed. Sorry, could not display all the contents of "Windows Network": 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. no message i /var/log/messages -------------------------------- If seleinux in permissive Mar 13 18:15:25 flokic dbus: avc: received setenforce notice (enforcing=0) Mar 13 18:15:25 flokic dbus: avc: received setenforce notice (enforcing=0) Mar 13 18:15:25 flokic dbus: Can't send to audit system: USER_AVC avc: received setenforce notice (enforcing=0)#012: exe="?" sauid=81 hostname=? addr=? terminal=? and error window Unable to mount location Sorry, could not display all the contents of "Windows Network": 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.
Sorry but this looks like a nautilus or gnome-vfs problem to me. Reassigning.
I see in top that gvfsd-smb-brows is with cpu over 90%
Can you please post you gvfs, gnome-keyring and libgnome-keyring package versions? Also, would it be possible to grab a backtrace and post it here? I'm not seeing this on my machine, though other people reported the same issue.
>Also, would it be possible to grab a backtrace and post it here? I am not sure how do do this. I will try [floki@flokic ~]$ rpm -qa | grep gvfs gvfs-fuse-1.5.5-1.fc13.x86_64 gvfs-fuse-1.5.3-2.fc13.x86_64 gvfs-obexftp-1.5.5-1.fc13.x86_64 gvfs-archive-1.5.5-1.fc13.x86_64 gvfs-obexftp-1.5.3-2.fc13.x86_64 gvfs-1.5.5-1.fc13.x86_64 gvfs-afc-1.5.5-1.fc13.x86_64 gvfs-gphoto2-1.5.5-1.fc13.x86_64 gvfs-1.5.3-2.fc13.x86_64 gvfs-smb-1.5.5-1.fc13.x86_64 [floki@flokic ~]$ [floki@flokic ~]$ rpm -qa | grep gnome-keyring libgnome-keyring-2.29.4-4.fc13.x86_64 gnome-keyring-pam-2.29.92-1.fc13.x86_64 gnome-keyring-2.29.92-1.fc13.x86_64 [floki@flokic ~]$
libgnome-keyring-2.29.92-git20100317.1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/libgnome-keyring-2.29.92-git20100317.1.fc13
(In reply to comment #7) > >Also, would it be possible to grab a backtrace and post it here? > I am not sure how do do this. > I will try Please see http://fedoraproject.org/wiki/StackTraces#gdb, this wiki should provide you all information necessary. > [floki@flokic ~]$ rpm -qa | grep gvfs > gvfs-fuse-1.5.5-1.fc13.x86_64 > gvfs-fuse-1.5.3-2.fc13.x86_64 > gvfs-obexftp-1.5.5-1.fc13.x86_64 > gvfs-obexftp-1.5.3-2.fc13.x86_64 > gvfs-1.5.5-1.fc13.x86_64 > gvfs-1.5.3-2.fc13.x86_64 This is quite mess in your system. Be sure to run yum-complete-transaction or manually remove the old packages. It shouldn't make a difference though. Also, I've built new libgnome-keyring snapshot, please test it. I still can't reproduce the problem on my machine.
I reinstalled F13 form live x86_64. updated and updated libgnome-keyring form kojoi. I is possible to see samba share from F12 computer. ( off to shares one wans opend with gedit from nautilus when clicked ). I sama was opend from nautilus using network and select windows share and giving local ipv4 number then samba share was seen and ok. I have not yet given permanent password fore windows share. Usung smb: was not possible. I shaw gvfsd-smb-brows with high cpu. I was statting to bactrace when f13 freaze.
I am afraid that I will not be able to get backtrace. The computer was freezing when I was trying. I have seen that also in chases not related to samba. It might be related to hardware problem.
From upstream bug report it looks like dbus might be guilty for some problems, can you please post versions of your dbus and dbus-glib packages? Also, I've built gnome-keyring-2.29.92-2.fc13 and libgnome-keyring-2.29.92-git20100322.1.fc13, can you give them a shot too?
Created attachment 401882 [details] top rpm -q gdb try Still same problem. This is F13 fully updated. I am not good at backtraces. >versions of your dbus and dbus-glib packages? [floki@flokic ~]$ rpm -qa | grep dbus dbus-x11-1.2.22-1.fc13.x86_64 dbus-libs-1.2.22-1.fc13.x86_64 dbus-1.2.22-1.fc13.x86_64 eggdbus-0.6-2.fc13.x86_64 dbus-python-0.83.0-6.fc12.x86_64 dbus-glib-debuginfo-0.84-3.fc13.x86_64 dbus-c++-0.5.0-0.11.20090203git13281b3.fc13.x86_64 python-slip-dbus-0.2.8-1.fc13.noarch dbus-debuginfo-1.2.22-1.fc13.x86_64 dbus-glib-0.84-3.fc13.x86_64 [floki@flokic ~]$ >Also, I've built gnome-keyring-2.29.92-2.fc13 and >libgnome-keyring-2.29.92-git20100322.1.fc13, can you give them a shot too? [ floki@flokic ~]$ rpm -qa | grep gnome-keyring libgnome-keyring-2.29.92-git20100322.1.fc13.x86_64 libgnome-keyring-debuginfo-2.29.92-git20100317.1.fc13.x86_64 gnome-keyring-pam-2.29.92-2.fc13.x86_64 gnome-keyring-2.29.92-2.fc13.x86_64 floki@flokic ~]$ rpm -q libgnome-keyring libgnome-keyring-2.29.92-git20100322.1.fc13.x86_64
Created attachment 401887 [details] valgrind nautilus smb: valgrind nautilus smb:
Oh, I should've mentioned that gvfsd-smb (or gvfsd-smb-browse) is the right process to debug, nautilus acts here just as a frontend. Sorry for that. Also see your comment 5. If the process is still running, you can attach to it by doing `gdb /usr/libexec/gvfsd-smb-browse <PID>`. Entering "t a a bt" should give you the backtrace I'm looking for. Probably it would look like this: http://bugzilla-attachments.gnome.org/attachment.cgi?id=156584 hopefully with less number of question marks.
This works now.
libgnome-keyring-2.29.92-git20100317.1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 576504 has been marked as a duplicate of this bug. ***
My stack: (gdb) bt #0 0x00007f5b97bfa283 in poll () from /lib64/libc.so.6 #1 0x00007f5b980e68f9 in ?? () from /lib64/libglib-2.0.so.0 #2 0x00007f5b980e70a5 in g_main_loop_run () from /lib64/libglib-2.0.so.0 #3 0x000000000040c0de in dbus_message_append_args () #4 0x000000000040c36c in dbus_message_append_args () #5 0x00007f5b97b3dd2d in __libc_start_main () from /lib64/libc.so.6 #6 0x0000000000407d49 in dbus_message_append_args () #7 0x00007fff58023728 in ?? () #8 0x000000000000001c in ?? () #9 0x0000000000000004 in ?? () #10 0x00007fff58023c0f in ?? () #11 0x00007fff58023c26 in ?? () #12 0x00007fff58023c30 in ?? () #13 0x00007fff58023c35 in ?? () #14 0x0000000000000000 in ?? () (gdb) t [Current thread is 1 (Thread 0x7f5b9a3d77c0 (LWP 5950))] ----------------------------------------------- rpm -q libgnome-keyring libgnome-keyring-2.29.92-git20100322.1.fc13.x86_64 --------------------------------- top info: 5950 iranzo 20 0 273m 4972 3964 S 79.3 0.2 1:18.94 gvfsd-smb
Pablo, can you please install missing debuginfo packages and try catching a better backtrace? Please see http://fedoraproject.org/wiki/StackTraces, either way gdb should give you hint what's needed.
SMB connection is started choosing from Gnome's 'places' a bookmark with remembered password to connect. stack trace doing gdb --pid=$PID, and then: thread apply all bt full --------------------------------------------------------------- Thread 2 (Thread 0x7fb0d0c5f710 (LWP 20557)): #0 dbus_pending_call_block (pending=0x7fb0cc075cd0) at dbus-pending-call.c:703 __FUNCTION__ = "dbus_pending_call_block" #1 0x0000003b65408a03 in gkr_operation_block (op=0x7fb0cc078040) at gkr-operation.c:372 __PRETTY_FUNCTION__ = "gkr_operation_block" #2 0x000000000041b975 in g_vfs_keyring_lookup_password (username=0x1b5fa70 "nmt", host=0x1b5f3f0 "192.168.2.4", domain=0x0, protocol=<value optimized out>, object=0x0, authtype=<value optimized out>, port=0, username_out=0x7fb0d0c5e2e8, domain_out=0x7fb0d0c5e2e0, password_out=0x7fb0d0c5e2f0) at gvfskeyring.c:61 pwd_data = 0x1b5fa70 result = <value optimized out> plist = <value optimized out> #3 0x00000000004098a0 in auth_callback (context=<value optimized out>, server_name=<value optimized out>, share_name=<value optimized out>, domain_out=0x7fb0d0c5e580 "MYGROUP", domainmaxlen=<value optimized out>, username_out=0x7fb0d0c5e480 "nmt", unmaxlen=256, password_out=0x7fb0d0c5e380 "", pwmaxlen=256) at gvfsbackendsmb.c:203 in_keyring = 0 backend = 0x1b5e020 ask_password = <value optimized out> ask_user = <value optimized out> ask_domain = <value optimized out> handled = <value optimized out> abort = <value optimized out> #4 0x00007fb0d755419a in SMBC_call_auth_fn (ctx=0x7fb0cc030ea0, context=<value optimized out>, server=<value optimized out>, share=<value optimized out>, pp_workgroup=0x7fb0d0c5ebe0, pp_username=0x7fb0d0c5ebf0, pp_password=0x7fb0d0c5ebe8) at libsmb/libsmb_server.c:115 workgroup = "MYGROUP\000\200\071@S;\000\000\000\240MPװ\177\000\000`\226\327װ\177\000\000\250\001\000\000\001\000\000\000\377\377\377\377\000\000\000\000\005\000\000\000\000\000\000\000\005\000\000\000\000\000\000\000x`b", '\000' <repeats 13 times>"\360, .\a̰\177\000\000\220\067\a̰\177\000\000\000\000\000\000\000\000\000\000\341\345\200P;\000\000\000\005", '\000' <repeats 15 times>, "\005\000\000\000\260\177\000\000\240MPװ\177\000\000\030\350\305а\177\000\000\360.\a̰\177\000\000`/\a̰\177\000\000PG\a̰\177\000\000`/\a̰\177\000\000\245R\201P;\000\000\000p\224@\000\000\000\000\000PG\a̰\177\000\000`/\a̰\177\000\000\360.\a̰\177\000\000`[\a̰\177\000\000\220\067\a̰\177\000\000\360\353\305а\177\000\000\350 \242P;"... username = "nmt", '\000' <repeats 252 times> password = '\000' <repeats 255 times> auth_with_context_fn = <value optimized out> #5 0x00007fb0d7554400 in SMBC_find_server (ctx=0x7fb0cc030ea0, context=0x7fb0cc075b60, server=0x7fb0cc072ef0 "192.168.2.4", share=0x7fb0cc072f60 "share", pp_workgroup=0x7fb0d0c5ebe0, pp_username=0x7fb0d0c5ebf0, pp_password=0x7fb0d0c5ebe8) at libsmb/libsmb_server.c:175 srv = <value optimized out> auth_called = <value optimized out> #6 0x00007fb0d75544ed in SMBC_server_internal (ctx=<value optimized out>, context=0x7fb0cc075b60, connect_if_not_found=true, server=0x7fb0cc072ef0 "192.168.2.4", share=<value optimized out>, pp_workgroup=0x7fb0d0c5ebe0, pp_username=0x7fb0d0c5ebf0, pp_password=0x7fb0d0c5ebe8, in_cache=0x7fb0d0c5eb1f) at libsmb/libsmb_server.c:267 srv = 0x0 workgroup = 0x0 c = 0x0 called = {name = "\300/\a̰\177\000\000\300/\a̰\177\000", scope = "`[\a̰\177", '\000' <repeats 34 times>, "\001\000\000\000\000\000\000\000\200\000\000\000\000\000\000\000\006\000\000\000|\000\000", name_type = 119} calling = {name = "\340\023\004̰\177\000\000;s\223װ\177\000", scope = "\200\023\004̰\177\000\000R\313\307P;\000\000\000(\000\000\000\000\000\000\000p\f\025\350\000\000\000\000P6\a̰\177\000\000\340\023\004̰\177\000\000\000\000\000\000\000\000\000\000\300/\a̰\177\000", name_type = 8} ss = {ss_family = 2, __ss_align = 0, __ss_padding = '\000' <repeats 111 times>} tried_reverse = 0 port_try_first = <value optimized out> port_try_next = <value optimized out> is_ipc = <value optimized out> fs_attrs = 0 username_used = <value optimized out> status = <value optimized out> newserver = <value optimized out> newshare = <value optimized out> __FUNCTION__ = "SMBC_server_internal" #7 0x00007fb0d75551de in SMBC_server (ctx=<value optimized out>, context=0x7fb0cc075b60, connect_if_not_found=<value optimized out>, server=0x7fb0cc072ef0 "192.168.2.4", share=0x7fb0cc072f60 "share", pp_workgroup=0x7fb0d0c5ebe0, pp_username=0x7fb0d0c5ebf0, pp_password=0x7fb0d0c5ebe8) at libsmb/libsmb_server.c:670 srv = 0x0 in_cache = false __FUNCTION__ = "SMBC_server" #8 0x00007fb0d75561e4 in SMBC_stat_ctx (context=0x7fb0cc075b60, fname=0x7fb0cc062370 "smb://192.168.2.4/share", st=0x7fb0d0c5ec80) at libsmb/libsmb_stat.c:168 srv = 0x0 server = 0x7fb0cc072ef0 "192.168.2.4" share = 0x7fb0cc072f60 "share" user = 0x7fb0cc073790 "iranzo" password = 0x7fb0cc0413e0 "" workgroup = 0x7fb0cc074750 "MYGROUP" path = 0x7fb0cc072e90 "" write_time_ts = {tv_sec = 5, tv_nsec = 0} access_time_ts = {tv_sec = 0, tv_nsec = 254753695201} change_time_ts = {tv_sec = 140397393603712, tv_nsec = 140397313621664} size = 0 mode = 0 ino = 0 frame = <value optimized out> __FUNCTION__ = "SMBC_stat_ctx" #9 0x000000000040b633 in do_mount (backend=<value optimized out>, job=0x1b5d030, mount_spec=<value optimized out>, mount_source=<value optimized out>, is_automount=<value optimized out>) at gvfsbackendsmb.c:575 op_backend = 0x1b5e020 smb_context = 0x7fb0cc075b60 st = {st_dev = 254761504384, st_ino = 254758341034, st_nlink = 140397393603864, st_mode = 0, st_uid = 1, st_gid = 0, __pad0 = 0, st_rdev = 254766231095, st_size = 0, st_blksize = 2032, st_blocks = 0, st_atim = {tv_sec = 254790318144, tv_nsec = 32}, st_mtim = { tv_sec = 28597152, tv_nsec = 140397313525952}, st_ctim = {tv_sec = 254790318144, tv_nsec = 32}, __unused = {28692528, 28702464, 28692528}} uri = 0x7fb0cc062370 "smb://192.168.2.4/share" res = <value optimized out> display_name = <value optimized out> debug = <value optimized out> debug_val = <value optimized out> smb_mount_spec = 0x7fb0cc017ea0 smbc_stat = <value optimized out> #10 0x0000000000410ec2 in g_vfs_job_run (job=0x1b5d030) at gvfsjob.c:198 class = 0x1b5f700 #11 0x0000003b5286702b in g_thread_pool_thread_proxy (data=<value optimized out>) at gthreadpool.c:315 task = 0x1b5d030 pool = 0x1b53390 #12 0x0000003b52865164 in g_thread_create_proxy (data=0x1b5cdf0) at gthread.c:1893 thread = 0x1b5cdf0 __PRETTY_FUNCTION__ = "g_thread_create_proxy" #13 0x0000003b51406e11 in start_thread (arg=0x7fb0d0c5f710) at pthread_create.c:301 __res = <value optimized out> pd = 0x7fb0d0c5f710 now = <value optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140397393606416, 6505944271681342490, 140733309885504, 140397393606416, 0, 3, -6545876146535412710, 6503025618731256858}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <value optimized out> sp = <value optimized out> freesize = <value optimized out> __PRETTY_FUNCTION__ = "start_thread" #14 0x0000003b50ce4a0d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 No locals. Thread 1 (Thread 0x7fb0d6bfa7c0 (LWP 20556)): #0 0x0000003b50cdb283 in __poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 __arg2 = 7 _a3 = -1 _a1 = 28694848 resultvar = <value optimized out> __arg3 = -1 __arg1 = 28694848 _a2 = 7 resultvar = <value optimized out> oldtype = 0 result = <value optimized out> #1 0x0000003b5283f8f9 in g_main_context_poll (context=0x1b52be0, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>) at gmain.c:2904 poll_func = 0x3b5284ca20 <IA__g_poll> #2 g_main_context_iterate (context=0x1b52be0, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>) at gmain.c:2586 max_priority = 2147483647 timeout = -1 some_ready = <value optimized out> nfds = 7 allocated_nfds = <value optimized out> fds = 0x1b5d940 __PRETTY_FUNCTION__ = "g_main_context_iterate" #3 0x0000003b528400a5 in IA__g_main_loop_run (loop=0x1b53210) at gmain.c:2799 self = 0x1b44520 __PRETTY_FUNCTION__ = "IA__g_main_loop_run" #4 0x000000000040c0de in daemon_main (argc=<value optimized out>, argv=<value optimized out>, max_job_threads=<value optimized out>, default_type=0x41d883 "smb-share", mountable_name=<value optimized out>, first_type_name=0x41d883 "smb-share") at daemon-main.c:294 var_args = {{gp_offset = 48, fp_offset = 0, overflow_arg_area = 0x7fff06f1a240, reg_save_area = 0x7fff06f1a1c0}} connection = <value optimized out> loop = <value optimized out> daemon = 0x1b53400 derror = {name = 0x0, message = 0x0, dummy1 = 1, dummy2 = 0, dummy3 = 0, dummy4 = 0, dummy5 = 0, padding1 = 0x3b5285aca1} mount_spec = 0x0 mount_source = <value optimized out> error = 0x0 res = <value optimized out> type = <value optimized out> #5 0x000000000040c36c in main (argc=4, argv=0x7fff06f1a338) at daemon-main-generic.c:39 No locals. ---------------------------------------------------------------
Great, thanks. While you are in the debugger, can you please add breakpoint on auth_callback and see how many times does it break? Use "c" to continue the running process after you set up the breakpoint by "break auth_callback".
The lock happens even with the target machine not responding to ping.... attempting connection with target IP powered off, gvfs started eating all cpu as usual. gdb --pid=$PID break auth_callback c just keep 'quiet' for a long period, after killing $PID it displays: (gdb) break auth_callback Breakpoint 1 at 0x409600: file gvfsbackendsmb.c, line 155. (gdb) c Continuing. Program received signal SIGTERM, Terminated. 0x0000003b50cdb283 in __poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 87 int result = INLINE_SYSCALL (poll, 3, CHECK_N (fds, nfds), nfds, timeout);
Thanks, so it's stuck in there. Any chance you can try the libgnome-keyring patch posted at https://bugzilla.gnome.org/show_bug.cgi?id=613399#c2 ?
There's any RPM package to install that patch? Thanks Pablo
(In reply to comment #25) > There's any RPM package to install that patch? I've made testing scratch build, please grab the packages directly from koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=2082001
Hi "libgnome-keyring-2.29.92-git20100322.2.fc13.i686" still presents the problem on x86, will test at home with x86_64 Regards Pablo
With x86_64, problem persists too
smbclient can connect and works ok while gvfsd-smb keeps using 100% of CPU until killed or a long timeout
libgnome-keyring-2.30.0-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/libgnome-keyring-2.30.0-2.fc13
libgnome-keyring-2.30.0-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update libgnome-keyring'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/libgnome-keyring-2.30.0-2.fc13
libgnome-keyring-2.30.0-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.