Bug 124420

I have updated to kernel-2.6.6-1.391 and the same problem/behaviour is
still apparent.

I can provide the output from dmesg if required.

I had the same problem, upgraded to the latest packages from:
http://us1.samba.org/samba/ftp/Binary_Packages/Fedora/RPMS/i386/core/1/
to solve another problem, and I've not had this problem since.

I have experienced this problem as well but have been recently unable
to reproduce the problem consistently.  I am using Fedora Core 2 final
with the 2.6.6-1.435smp kernel.

I should have also mention that my results from dmesg are nearly
identical with a suspicious:

smb_lookup: find //.Trash-bchrist failed, error=-5
Unable to handle kernel NULL pointer dereference at virtual address 

Same problem here on FC2 x86_64.
when I try the following command:
[greggy@homer greggy]$ smbmount //192.168.3.2/data /home/greggy/data
I get a kernel oops.
After the oops, I usually can't get any prompt anymore and ssh to my
pc is not working anymore, so a reboot is needed.

[root@homer root]# rpm -qa | grep kernel
kernel-utils-2.4-9.1.131
kernel-2.6.6-1.435
Note: the packages are x86_64.

This is from /var/log/messages:

homer kernel: CR2: 0000000000000000
Jun 28 22:43:24 homer kernel: smb_lookup: find //.Trash-greggy failed, 
error=-5
Jun 28 22:43:24 homer kernel: Unable to handle kernel NULL pointer
dereference 
at 0000000000000000 RIP:
Jun 28 22:43:24 homer kernel: [<0000000000000000>]
Jun 28 22:43:24 homer kernel: PML4 f8a7067 PGD f8b9067 PMD 0
Jun 28 22:43:24 homer kernel: Oops: 0010 [1]
Jun 28 22:43:24 homer kernel: CPU 0
Jun 28 22:43:24 homer kernel: Modules linked in: smbfs snd_mixer_oss 
snd_via82xx snd_ac97_codec snd_pcm snd_timer snd_page_alloc gameport 
snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore parport_pc lp 
parport autofs4 sunrpc sk98lin ipv6 joydev uhci_hcd ehci_hcd button
battery 
asus_acpi ac ext3 jbd raid1 dm_mod sata_promise sata_via libata sd_mod 
scsi_mod
Jun 28 22:43:24 homer kernel: Pid: 2151, comm: nautilus Not tainted 
2.6.6-1.435
Jun 28 22:43:24 homer kernel: RIP: 0010:[<0000000000000000>] 
[<0000000000000000>]
Jun 28 22:43:24 homer kernel: RSP: 0018:000001000e2b7e30  EFLAGS: 00010246
Jun 28 22:43:24 homer kernel: RAX: 000001000a132f68 RBX:
0000010009fbbe98 RCX: 
000001000e2b7e68
Jun 28 22:43:24 homer kernel: RDX: ffffffff8016fda6 RSI:
000001000e2b7f38 RDI: 
000001000ae47ac0
Jun 28 22:43:24 homer kernel: RBP: 000001000ae47ac0 R08:
000001000ce13000 R09: 
0000000000000004
Jun 28 22:43:24 homer kernel: R10: 0000000000000e60 R11:
0000000000000000 R12: 
000001000122f120
Jun 28 22:43:24 homer kernel: R13: 000001000ae47ac0 R14:
0000010009fbc000 R15: 
000001000a1a9ba0
Jun 28 22:43:24 homer kernel: FS:  0000000040c3f960(005b)
GS:ffffffff8046bb80
(0000) knlGS:0000000000000000
Jun 28 22:43:24 homer kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 
000000008005003b
Jun 28 22:43:24 homer kernel: CR2: 0000000000000000 CR3:
0000000000101000 CR4: 
00000000000006e0
Jun 28 22:43:24 homer kernel: Process nautilus (pid: 2151, threadinfo 
000001000e2b6000, task 000001000e2fd800)
Jun 28 22:43:24 homer kernel: Stack: ffffffffa01b5e69 0000010009fbbde8 
0000000000018801 000001000ce13000
Jun 28 22:43:24 homer kernel:        0000010009fbbde8 ffffffff8016fda6 
000001000e2b7f38 0000000000000000
Jun 28 22:43:24 homer kernel:        00000000fffd13cf 000001000ae47ac0
Jun 28 22:43:24 homer kernel: Call 
Trace:<ffffffffa01b5e69>{:smbfs:smb_readdir+937} 
<ffffffff8016fda6>{filldir64+0}
Jun 28 22:43:24 homer kernel:        <ffffffff8016fda6>{filldir64+0} 
<ffffffff8016fae9>{vfs_readdir+133}
Jun 28 22:43:24 homer kernel:   <ffffffff8016fed7>{sys_getdents64+118} 
<ffffffff8016f33e>{sys_fcntl+95}
Jun 28 22:43:24 homer kernel:      <ffffffff801110ae>{system_call+126}
Jun 28 22:43:24 homer kernel:
Jun 28 22:43:24 homer kernel: Code:  Bad RIP value.
Jun 28 22:43:24 homer kernel: RIP [<0000000000000000>] RSP
<000001000e2b7e30>
Jun 28 22:43:24 homer kernel: CR2: 0000000000000000

I have the same problem on FC2 i386.  kernel is  2.6.6-1.435.2.3 .  
Any updates?? 

I have the exact same problem with FC2 on i386 and kernel 2.6.6-1.435.2.3.

I noticed no one else has added any more input but I noticed that if I
mount the same smb-share twice to different mount directories, the
first one will always fail and show the symptoms described. The second
mount will work as anticipated - even though it uses exactly the same
parameters.

Hope this gives some clues on why it appears.

Same Problem here. I'm running FC2 with the kernel 2.6.6-1.435.2.3 and
it hangs as described above. I updated samba to 3.0.5-pre1 and the
same problem appear. For this i rebuild the Sernet SRPMS on the system.

To prevent a unclean shutdown you can do the following.
umount -l <mountpoint> Than you can do a clean shutdown or mount the
smb-share again. Than it's possible to access the mountpoint.

I tried cifs, but this does'nt worked for me. I run always in a kernel
panic.

There's a work around for this.  Create an empty directory
.Trash-username in the samba share folder and it should work.

http://lists.samba.org/archive/samba/2004-June/087844.html

~ > uname -srv
Linux 2.6.5-1.358 #1 Sat May 8 09:04:50 EDT 2004
~ > rpm -qa | grep -i samba
system-config-samba-1.2.9-2
samba-3.0.5rc1-2
samba-client-3.0.5rc1-2
samba-swat-3.0.5rc1-2
samba-common-3.0.5rc1-2

Created trash directories as suggested in comment #9. Still hangs on
first attempt to access.

The lazy-unmount approach suggested in comment #8 does work as
described however.

Follow up on previous post (#10): Mounted smb volume, issued a
lazy-unmount, then remounted volume. Access via terminal seems to work
fine. Can also open the mount by using Nautilus by double-clicking the
icon placed on the desktop. However, first attempt to open folder on
an smb mount through Nautilus (v2.6.0) hangs it and the desktop.
Clicking on close button (X) and selecting FORCE KILL from the dialog
restarts Nautilus. No errors reported, at least on screen, and
Nautilus restarts itself with the cwd being my home directory.
Attempting to go back to the mount and accessing folders seems to
work... for a while anyway.

Nothing "unusual" in the system log, exept the same errors described
previously by others. Seemingly relevant lines include:

Jul 19 07:58:17 thurston_w2k kernel: smbfs: Unrecognized mount option
nosuid
Jul 19 07:58:17 thurston_w2k kernel: smb_lookup: find
//.Trash-jthurston failed, error=-5
Jul 19 07:58:17 thurston_w2k kernel: Unable to handle kernel NULL
pointer dereference at virtual address 00000000
Jul 19 07:58:17 thurston_w2k kernel:  printing eip:
Jul 19 07:58:17 thurston_w2k kernel: 00000000
Jul 19 07:58:17 thurston_w2k kernel: *pde = 00000000
Jul 19 07:58:17 thurston_w2k kernel: Oops: 0000 [#1]
Jul 19 07:58:17 thurston_w2k kernel: Modules linked in: smbfs
snd_mixer_oss snd_maestro3 snd_ac97_codec snd_pcm snd_page_alloc
snd_timer snd soundcore parport_pc lp parport autofs4 ds yenta_socket
pcmcia_core sunrpc 3c59x floppy sg scsi_mod microcode dm_mod uhci_hcd
button battery asus_acpi ac ipv6 ext3 jbd
Jul 19 07:58:17 thurston_w2k kernel: CPU:    0
Jul 19 07:58:17 thurston_w2k kernel: EIP:    0060:[<00000000>]    Not
tainted
Jul 19 07:58:17 thurston_w2k kernel: EFLAGS: 00210246   (2.6.6-1.435.2.3)
Jul 19 07:58:17 thurston_w2k kernel: EIP is at 0x0
Jul 19 07:58:17 thurston_w2k kernel: eax: 02865ec0   ebx: 141070d8  
ecx: 0214fbb5   edx: 13521fa0
Jul 19 07:58:17 thurston_w2k kernel: esi: 03e7f078   edi: 0303cfe0  
ebp: 02865ec0   esp: 13521f14
Jul 19 07:58:17 thurston_w2k kernel: ds: 007b   es: 007b   ss: 0068
Jul 19 07:58:17 thurston_w2k mount.smbfs[2997]: [2004/07/19 07:58:17,
0] client/smbmount.c:send_fs_socket(406)
Jul 19 07:58:17 thurston_w2k kernel: Process nautilus (pid: 2433,
threadinfo=13521000 task=12e8a8b0)
Jul 19 07:58:17 thurston_w2k mount.smbfs[2997]:   mount.smbfs:
entering daemon mode for service \\creative\itgroup, pid=2997
Jul 19 07:58:17 thurston_w2k kernel: Stack: 22a26982 13521f38 00000000
03e7f000 21f81278 0285ee18 1d806474 0214fbb5
Jul 19 07:58:17 thurston_w2k kernel:        13521fa0 00000000 00169a14
12f7fce0 00000000 00000000 03e7f000 00000002
Jul 19 07:58:17 thurston_w2k kernel:        00000000 00000000 00000001
00000004 00200246 22a2e0a0 0285ee80 02865ec0
Jul 19 07:58:17 thurston_w2k kernel: Call Trace:
Jul 19 07:58:17 thurston_w2k kernel:  [<22a26982>]
smb_readdir+0x346/0x3f1 [smbfs]
Jul 19 07:58:17 thurston_w2k kernel:  [<0214fbb5>] filldir64+0x0/0x12e
Jul 19 07:58:17 thurston_w2k kernel:  [<0214f8a2>] vfs_readdir+0x7a/0x9b
Jul 19 07:58:17 thurston_w2k kernel:  [<0214fbb5>] filldir64+0x0/0x12e
Jul 19 07:58:17 thurston_w2k kernel:  [<0214fd48>]
sys_getdents64+0x65/0xaa
Jul 19 07:58:17 thurston_w2k kernel:  [<0214f054>]
generic_file_fcntl+0xd7/0x140
Jul 19 07:58:17 thurston_w2k kernel:
Jul 19 07:58:17 thurston_w2k kernel: Code:  Bad EIP value.
Jul 19 07:58:27 thurston_w2k kernel:  smbfs: Unrecognized mount option
nosuid
Jul 19 07:58:27 thurston_w2k mount.smbfs[3007]: [2004/07/19 07:58:27,
0] client/smbmount.c:send_fs_socket(406)
Jul 19 07:58:27 thurston_w2k mount.smbfs[3007]:   mount.smbfs:
entering daemon mode for service \\creative\itgroup, pid=3007

Attempted to backdate samba rpms from FC1 distribution. Packages used
were:

samba-3.0.0-15.i386.rpm
samba-client-3.0.0-15.i386.rpm
samba-common-3.0.0-15.i386.rpm
samba-swat-3.0.0-15.i386.rpm

No change in functionality.

It seems to be a kernel bug and there is already a workaround and a fix:
http://www.redhat.com/archives/fedora-list/2004-June/msg00318.html

I installed kernel 2.6.7 from ATRPMS
(http://atrpms.net/dist/fc2/kernel-testing/), rebuild the ntfs-kernel
modul (http://linux-ntfs.sourceforge.net/rpm/build.html) and all this
works for now. Looking forward for a official FC2-kernel.

I have the same smb kernel oops problem.

  kernel-2.6.6-1.435.2.3 (i686)
  samba-3.0.3-5
  FC2 (fully updated to this date)

  Filesystem is a lvm2 volume on a vg created out of RAID1
  mirrors of IDE partitions .. if this makes a difference.

The workaround mentions trying to access non existent .Trash
directories as do some above. I have scoured my log files, but can
find nothing about .Trash in them.

For me it flips out when a client (XP or smbclient) authenticates
properly to smbd and it tries to access the data on the mount point.
Until today I had neglected to do the samba 3 group mapping thing
properly. Now that smbd has full permission to access the disk, it
flops out every time.

this is fixed in the current erratum