Egor Kobylkin wrote:
Hi All,Just after I click in Nautilus 2.14.1 on a folder, which is an unmounted samba share, the computer locks-up and the only thing I can do is reboot. Can anybody tell which package it might be, so I can file a bug report?Below a snip from /var/log/messages and a dmesg. I have left the computer running over the night in hope that it will recover, this is why restart was done only next morning.
Your problem description is a bit sparse on details. Here are some tips on reporting problems in case you need to follow through with this issue:
http://web.utk.edu/~rmahurin/debian-user-faq/faq.html
Attempting manual resume EXT3-fs: INFO: recovery required on readonly filesystem. EXT3-fs: write access will be enabled during recovery. ieee1394: Host added: ID:BUS[0-00:1023] GUID[0040ca010508a211] kjournald starting. Commit interval 5 seconds EXT3-fs: hda1: orphan cleanup on readonly fs ext3_orphan_cleanup: deleting unreferenced inode 580780 ext3_orphan_cleanup: deleting unreferenced inode 580655 ext3_orphan_cleanup: deleting unreferenced inode 580627 ext3_orphan_cleanup: deleting unreferenced inode 580625 EXT3-fs: hda1: 4 orphan inodes deleted EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode.
This snippet suggests that you didn't do a clean reboot. The last part of my reply is based on that assumption, so that as you work through this issue, you don't endanger any of your data in the process.
I can't address the samba issue specifically but your log messages don't seem to cover the period of the failure. You may need to look at earlier logs, which may be renamed in /var/log, possibly in gzip'd form, and post those. Any log entries covering the SMB access attempt will be time stamped with the time of the failure.
When drive or network access fails, it may appear to be a "lock-up." I don't know if these are buggy drivers or excessive timeouts, but they may cause the app or console to become unresponsive. It can also cause apparently "unkillable" processes. NFS used to be notorious for this, and SMB may have related problems.
In general, when an X terminal or X app becomes unresponsive due to a device or network access failure, you may have to wait a long time for it to timeout. Alternative you could try to start another terminal. If X is completely unresponsive, you can start a session on another VT using xstart, kill X with ctl-alt-backspace, or try to open a virtual terminal by pressing ctl-alt-F<n>, then log in to fix the problem or reboot with shutdown, reboot or ctl-alt-del. If none of these work, or the keyboard is unresponsive then you can try to access the system over the LAN from another system, which requires ssh, vnc or similar programs and specific configurations. All of these are explained in the Howto's.
(There are some more extreme solutions such as using a serial console, alt-sysreq reboot options, and even the the last-ditch joystick button kernel reboot trick. These require special kernel support and I've never had to resort to them with Debian stable, although serial consoles are handy for headless servers. These are also in the Howto's)