Since the upgrade to net-fs/samba-3.0.14a-r2, navigating to a Samba share from a Windows 98 machine shows all of the shares available to browse, but when a share is navigated into, the contents are missing, and no error message is produced. Removing 3.0.14a-r2 and reinstalling 3.0.10 makes the problem go away. No changes are made to the smb.conf file between versions. Reproducible: Always Steps to Reproduce: 1. install/upgrade samba to 3.0.14a 2. restart samba services 3. browse to share with Windows Actual Results: Shares show as empty. I am unable to confirm if the problem persists when connecting from different versions of Windows. A similar issue was reported in the forums: http://forums.gentoo.org/viewtopic-t-367798-highlight-samba+empty.html Expected Results: Shares should display their contents. Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r0, 2.6.12-gentoo-r6 i686) ================================================================= System uname: 2.6.12-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.6.13 ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-Os -march=pentium4 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-Os -march=pentium4 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://open-systems.ufl.edu/mirrors/gentoo" MAKEOPTS="-j6" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.davidandgoliathtees.com/gentoo-portage" USE="x86 X alsa apache2 avi berkdb bitmap-fonts browserplugin cdr chroot crypt cups curl dga divx4linux dv dvd dvdr eds emboss encode faad fam flac foomaticdb gd gdbm gif gimpprint gstreamer gtk gtk2 icq imagemagick imap imlib innodb java jpeg junit kde lcms ldap lesstif libg++ libwww live mad maildir mmx mng mozilla mozsvg mp3 mpeg msn mysql ncurses nptl nptlonly nsplugin odbc ogg oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime radeon readline samba sdl sensord softmmu spell sse ssl svg svga symlink tcltk tcpd tiff truetype truetype-fonts type1-fonts userlocales v4l v4l2 visualization vorbis xml xml2 xmms xscreensaver xv xvid zlib video_cards_radeon userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Created attachment 65457 [details] Samba Log Entries As far as I can tell, these errors also appeared in 3.0.10 as well as 3.0.14a-r2, but are provided here for completeness
Created attachment 65458 [details] Samba Configuration File Nothing was changed between 3.0.10 and 3.0.14a-r2 (and back again)
I can also confirm that this issue persists if I use smbclient from the local machine to view its own shares.
instead of the conf file, could you please attache the output of 'testparm -v -s > ${file} 2>&1' ? Also, you may check the various 'signing' functionalities (particularly 'smb signing'): from the log you attached, it seems like the security level you chose conflicts with it. And Win9x/Me have serious issues on packet signing (that's due to their network level design, by the way, not to samba's one).
Created attachment 65603 [details] Output of testparm command Actually, the SMB signing is something that I have absolutely no experience with. I don't even know what configuration options cover it. However, I do get the signing messages with both 3.0.14a and 3.0.10.
i can confirm all the stuff tim redman said. i have exactly the same problem. there was just one command i did to "enable" the problem: emerge -uD world after the update the shares were empty. then i restarted samba. still nothing. i even rebooted the system. but of course this only helps on windows. ;) one thing i can say is that *i saw an error message in the log.smb* in the time between the emerge and the restart of samba. it said that the recycler module was compiled for vfs 1.0 while samba uses 1.1 (wich is strange... because: why should an update downgrade the version of the vfs-interface?) then of course there wee many error messages from the recycler module. but i guess that this is because i did not restart samba. and after doing so, everythign ran fine. except the shares wich were empty. :( i can say that i certanly changed absolutely nothing else on that machine. so it must come from the updates. another thing to mention is that in the same update, the baselayout got updated too. no idea if it's relevant but it will not be amiss too. ;) i will attach my testparm-output too...
Created attachment 65654 [details] Navid Zamani's output of "testparm -v -s" PDC with roaming profiles, recycler and a mature configuration (i hope ;)
i just synced portage an saw that there's an additional bad problem: you can't downgrade samba anymore. there is only "samba-3.0.14a-r2.ebuild" left in /usr/portage/net-fs/samba/. so there's no working samba ebuild left! *please at least re-add an old ebuild!* this is an emergency case, because we can't work anymore here!! thank you!
I'm 'nearly' really sure this is a conf error, due to change in default configs between versions: infact, smb.conf is only an overlay to the full conf, which can be seen with the testparm command in previous comments. The test for this should be (quickpkg belongs to the portage package): 0) with the version that doesn't have issues installed... 1) testparm -v -s > ${file_ok} 2>&1 2) '/usr/sbin/quickpkg samba' (this will save your current samba package, with _your_ confs, to /usr/portage/packages/...) 3) emerge the other version of samba (and use quickpkg on that also) 4) testparm -v -s > ${file_wrong} 2>&1 5) diff -Nu ${file_ok} ${file_wrong} If there's no difference, you're now sure that samba changed behaviour. We can investigate further from there. PS: to recover the samba version of your choice, 'emerge -k =samba-${your_version}' (the quickpkg tool can be very useful when you upgrade...)
navid: since I'm not a great cvs guru, I don't trust myself to re-put the deleted files in portage tree while conserving all their metadata. Therefore, I put a tarball of the samba dir (version of 5 days ago) on my gentoo space: http://dev.gentoo.org/~satya/packages/samba/samba-overlay-2005-08-06.tar.gz Just unpack it into /usr/local/portage/net-fs/samba/, and put the following line in make.conf. PORTDIR_OVERLAY=/usr/local/portage
The client doesn't matter. Win98, W2K, Linux even from the local machine no files on the share are shown. But I can write a file or create a directory on that share without an error. The file or directory is there on the server, but I can't see it on the client.
So I've tested a little bit. I've downgraded to 3.0.10 and all worked. Then I'm run the testparm command, upgrade to 3.0.14-r2 and run testparm and diff. Now I changed 5 parameters that differs and 3.0.14-r2 don't work. I attached the diff of the last 4 parameters that I think are new in 3.0.14-r2. For the parameter 'enable privileges' I've tested Yes and No but nothing changed.
Created attachment 65672 [details] diff of testparm-3.0.10.log and testparm-3.0.14a-r2-new.log Now here the attachment
I tried changing the values for "allocation roundup size" to 0 and "enable privileges" to yes, but no effect, either individually or in combination. I also tried adding "browseable = yes" to the shares in question, and that didn't help, either. There's not documentation available on "fs token lifetime" or "log nt token command", so I didn't try them yet. The only other thing I can figure is that the behavior of an existing configuration parameter may have changed from one version to another, but as far as that goes, I wouldn't know where to begin. Christian: while I was in there, I disabled server signing. It didn't make anything better, but it should clean up the log a bit.
Okay, here's the skinny: Found out what it was that was doing it, and it looks like there's a chance it might apply to Navid as well. In my share, I had "hide special files = yes" (in Navid's, it's set globally). The kicker is that my share was located at the root of a vfat mount. My guess is that files on a vfat partition look different to Samba than files on an ext3, perhaps because of the difference in types and numbers of file attributes. In any event, setting "hide special files = no" made every file and folder in that share visible again. I'm currently moving all of those files into an ext3 partition so that I can turn back on "hide special files" and see if it treats it any differently.
I've got additional infos: The shares look empty, but creating a new file in them works. You just can't see them. They even go to the right directory. ;) So i guess we can narrow it down to the code that outputs the directory lists to the smb clients. (In reply to comment #10) christian: thank you. your tarball helped me much. :) I've masked 3.0.14a-r2 out for now and will continue using the old version.
Nope, that's not it. Does the same thing on an ext3 partition as well. So, for the time being, the only workaround I've found is to remove "hide special files" from your smb.conf, or set it to "no".
(In reply to comment #16) > I've got additional infos: The shares look empty, but creating a new file in > them works. You just can't see them. They even go to the right directory. ;) > > So i guess we can narrow it down to the code that outputs the directory lists to > the smb clients. > I've actually seen some mention of this behavior in the samba mailing list, but nobody's proferred an explanation as of yet.
(In reply to comment #15) > The kicker is that my share was located at the root of a vfat mount. My guess is that files on a vfat partition look different to Samba than files on an ext3, perhaps because of the difference in types and numbers of file attributes. Hmm... i have 6 normal partitions. Five of them are in a LVM. And all but /boot use reiser3. So it's not only a vfat-problem. (It's new to me that files look different to programs if they are on different filesystems. Don't they all (if you forget the diskeditors) use the normal linux files system abstraction layer? But i'm no fs-guru, so ignore me if i tell crap... ;)
(In reply to comment #17) > the only workaround I've found is to remove "hide special files" > from your smb.conf, or set it to "no". so the question could be: why does samba think that all files are special? (of course they are... those precious files... precious little files... wait... forget about that... ;)
(In reply to comment #19) > (It's new to me that files look different to programs if they are on different > filesystems. Don't they all (if you forget the diskeditors) use the normal linux > files system abstraction layer? But i'm no fs-guru, so ignore me if i tell > crap... ;) No, you're probably right, at least according to what I've seen since I changed the partition to ext3. In any event, there's something about the "hide special files" option that's showing some quirks. I'm sure it's all by design. I just wish somebody would explain the design to me.
I've been gazing blankly at the Samba source code, and I'm a little bit confused at what I'm seeing. Much of the meat of the problem lies in the following function: BOOL is_visible_file(connection_struct *conn, const char *dir_path, const char *name, SMB_STRUCT_STAT *pst, BOOL use_veto) { {...} BOOL hide_special = lp_hide_special_files(SNUM(conn)); {...} if (hide_unreadable || hide_unwriteable || hide_special) { char *entry = NULL; {...} /* Honour _hide_special_ option */ if (hide_special && !file_is_special(conn, entry, pst)) { SAFE_FREE(entry); return False; } SAFE_FREE(entry); } return True; } All {...} are places that have to do with unreadable and unwriteable flags, and don't really have anything to do with this since I don't have those parameters set. It looks like the reasoning here is that if the function falls through without satisfying any of the conditions, we get back True from is_visible_file(), otherwise False. In the last check (/* Honour _hide_special_ option */), is_visible_file returns False if the hide_special flag (hide special files in smb.conf) is set, and if file_is_special() returns False, meaning that the file isn't special? This is where confusion sets in. Just to be sure, I checked file_is_special(): static BOOL file_is_special(connection_struct *conn, char *name, SMB_STRUCT_STAT *pst) { /* * If user is a member of the Admin group * we never hide files from them. */ if (conn->admin_user) return False; /* If we can't stat it does not show it */ if (!VALID_STAT(*pst) && (SMB_VFS_STAT(conn, name, pst) != 0)) return True; if (S_ISREG(pst->st_mode) || S_ISDIR(pst->st_mode) || S_ISLNK(pst->st_mode)) return False; return True; } file_is_special() seems to do exactly as it should, returning False if we're stat'ing a file, directory or link. Am I wrong in thinking that is_visible_file() might be doing things backwards? Somebody please clear me up on this, because as far as I can tell, this incorrect behavior would present exactly the situation I'm seeing. I think we might have a winner here. I just created a FIFO pipe in my share, and it's currently the only file showing up on my Windows client. By definition, "hide special files" should be showing everything else, and excluding the FIFO. Whew.
Created attachment 65782 [details, diff] Fixes "hide special files" behavior I've got this building right now, but wanted to make it available to anyone who wanted to give it a shot.
Created attachment 65784 [details] Updated ebuild for Samba This just has an update in it to implement the patch previously posted.
Works for me. Anybody else give it shot?
Tim: tested, and confimed. A bug was already open on that on [1], and since the patch proposed is the same as yours, I'm including it in portage tree. Only a minor ask :-) : a) when you attach ebuilds, please attach the diff with the official ones: it's easier to parse via web interface b) not all users have the portage tree default location: the '/usr/portage/net-fs/samba/files/${patch}' location should read '${FILESDIR}/${patch}' [1] https://bugzilla.samba.org/show_bug.cgi?id=2514 PS: at times, I'm very proud of the Gentoo Community. ;-)
samba-3.0.14a-r3 and patchset 0.3.4 in portage. Just wait a while for the mirrors to sync. Many thanks to all :-)
(In reply to comment #26) > Only a minor ask :-) : > a) when you attach ebuilds, please attach the diff with the official ones: it's > easier to parse via web interface > b) not all users have the portage tree default location: the > '/usr/portage/net-fs/samba/files/${patch}' location should read > '${FILESDIR}/${patch}' Sorry about that. I have to claim newb ignorance on that one. I've never actually edited an ebuild file before, much less submitted patches, so I was kinda flying seat-of-the-pants, as it were. I was hoping it would be interpreted more as a "proof of concept" than a final solution, but I guess that a lack of full disclosure on my experience level would have caused that. I actually spent some time looking around in the Samba bugzilla, but missed that one. Oh, well, the exercise was educational, to say the least. Thanks for your help, Christian.
