Samba 3.5 Upgrade and File Systems Other than UFS

[CsHoSI]

I had Samba 3.0.28 working great on FreeBSD 7.0-RELEASE with EXT2 and ZFS file systems. I did a portsnap update and had to rebuild Samba, I tried both 3.4 and 3.5 versions. I tried with portmanager -f to build port and all dependencies too.

Now with the newer Samba, I can start it, I can log-in to the previous shares, but can only browse certain directories. Directories with a number of files/directories--more than a dozen or two, fail to load with both Windows and [cmd=]mount -t smbfs ...[/cmd] on a Linux machine. The network resource becomes unavailable on Windows and get an I/O error on Linux doing an 'ls'. With smbclient, listing the directories that don't respond return,

Receiving SMB: Server stopped responding... Call returned zero bytes...

I see in the logs smbd causes a panic. Smaller directories load fine and can transfer files like normal.

I had set on the previous version,

directory name cache size=0

so that for very large directories all sub-directories would show. Before that option was set it would only display around 150. I tested without that option with no change to previously stated problem.

I made a new share to test with its path to a UFS file system. On the UFS share, I can browse large directories just fine, with several thousand sub-directories and files.

After upgrading, I deleted /var/db/samb and /usr/local/etc/samba that the ports install told me about. I re-created my Samba accounts. Am I missing some kind of cache directory? Is there some other options pertaining to display of large directories I can add?

I am led to believe that my problem lies with my EXT2 and ZFS shares, or previously cached shares. I can browse small directories on EXT2 and ZFS paths. The new share I created with a path to UFS allows me to browse large directories.

In /var/log/messages, I get

...kernel: pid 29455 (smbd), uid 0: exited on signal 6

every time it fails to load a directory. I do not get any errors in /var/log/log.smbd.

For the log of the client machine, I see the smb_panic:

[2010/12/12 09:18:30.057192,  0] lib/util.c:1465(smb_panic)
  PANIC (pid 29948): internal error
[2010/12/12 09:18:30.059374,  0] lib/util.c:1569(log_stack_trace)
  BACKTRACE: 28 stack frames:
   #0 0x330c7d <smb_panic+93> at /usr/local/sbin/smbd
   #1 0x31eb4f <dump_core_setup+2511> at /usr/local/sbin/smbd
   #2 0x7fbfffb4
   #3 0x20acbb8a <abort+106> at /lib/libc.so.7
   #4 0x303110 <opendir+0> at /usr/local/sbin/smbd
   #5 0x321c0d <sys_telldir+29> at /usr/local/sbin/smbd
   #6 0x134b1d <vfs_default_init+10189> at /usr/local/sbin/smbd
   #7 0x10411b <smb_vfs_call_telldir+43> at /usr/local/sbin/smbd
   #8 0xae41d <ReadDirName+317> at /usr/local/sbin/smbd
   #9 0xaf656 <can_delete_directory+630> at /usr/local/sbin/smbd
   #10 0xaf916 <dptr_ReadDirName+86> at /usr/local/sbin/smbd
   #11 0xafc4b <smbd_dirptr_get_entry+203> at /usr/local/sbin/smbd
   #12 0xe94ff <smbd_dirptr_lanman2_entry+303> at /usr/local/sbin/smbd
   #13 0xead04 <smbd_dirptr_lanman2_entry+6452> at /usr/local/sbin/smbd
   #14 0xebff4 <smbd_dirptr_lanman2_entry+11300> at /usr/local/sbin/smbd
   #15 0xefb27 <smbd_do_setfilepathinfo+10343> at /usr/local/sbin/smbd
   #16 0xf16e6 <reply_trans2+1654> at /usr/local/sbin/smbd
   #17 0x115a20 <remove_deferred_open_smb_message+2048> at /usr/local/sbin/smbd
   #18 0x11898a <chain_reply+1674> at /usr/local/sbin/smbd
   #19 0x118d72 <chain_reply+2674> at /usr/local/sbin/smbd
   #20 0x3407bf <run_events+511> at /usr/local/sbin/smbd
   #21 0x11812b <smbd_process+2107> at /usr/local/sbin/smbd
   #22 0x65e82a <main+5146> at /usr/local/sbin/smbd
   #23 0x3407bf <run_events+511> at /usr/local/sbin/smbd
   #24 0x340a1e <event_add_to_select_args+558> at /usr/local/sbin/smbd
   #25 0x341035 <_tevent_loop_once+149> at /usr/local/sbin/smbd
   #26 0x65e60a <main+4602> at /usr/local/sbin/smbd
   #27 0x97ef9 <_start+137> at /usr/local/sbin/smbd

Can anyone help me interpret that backtrace for further troubleshooting, please? Or hopefully something simple I am overlooking?

 

[CsHoSI]

Well, I installed 8.1-RELEASE on a VM and enabled ZFS and Samba 3.4.

I configured Samba to share a path on the ZFS file system. There I made a shell script create hundreds of directories with each hundreds of files. The files are empty but Samba doesn't crash and the directories are displayed fine.

I may have to copy over real data and test again, but I'm thinking this is in upgrade issue. Upgraded ports tree on 7.0-RELEASE with rebuilt Samba 3.4/3.5 is not working with non-native file systems, while it seems to work with UFS. Fresh install of 8.1-RELEASE and Samba 3.4 does seem to work with ZFS as well as UFS.

 

[CsHoSI]

Sorry I did not format my post correctly and you had to. It looks much better and I will try following the proper formatting from now on.

On the 8.1-Release test-VM, I did a portsnap, removed samba34 and built samba35. It still works fine with large directories on UFS and ZFS. I also a moved couple GBs of real data to the ZFS share without error.

I'm at a standstill on troubleshooting the 7.1-RELEASE portsnap update and newer Samba-build issue. If someone can read into that backtrace and get me going in the right direction I will pursue it more.

Otherwise, I'm going to wait until the end of January for 8.2-RELEASE and try to do a binary upgrade. I'm kicking myself for not taking a clone image of the working system before messing with it. I only did the portsnap so I wouldn't have to keep manually downloading these source files to build some Perl modules I needed. Lesson learned!

In the meantime, I'm going to experiment with exporting an NFS share to another system which Samba is working, and use that server as an intermediary to manipulate files on the 7.1-RELEASE system from Windows.