Samba Traffic #15 For 8 Mar 2000

By Peter Samuelson

Table Of Contents


At least one reader thought that our little editorial/explanation last week (sm20000302_14.html#3) on Luke Leighton's release management abilities was a bit unfair, reading somewhat like a one-sided argument. That was certainly not the intent! It was supposed to have been more or less a retraction of our original remarks (sm20000210_11.html#general) , and an acknowledgement that Luke has indeed proven his ability to settle down and adopt a release-cycle mindset. Anyway, this is what Luke actually wrote ( :

> Are we in feature freeze yet? :-)

well, we don't have complete features yet, so no, not really.

for example, connections are made (SMB) over which DCE/RPC function calls are sent, but either the client or the server can drop the connection.

now, do you want me to add a "feature" which allows connections to be automatically reestablished, or do you want me to freeze functionality now, with the consequences that your system may be unreliable?

ok, i'm being silly. i'm a little over-sensitive about the comments i saw on linuxcare's website saying i don't know how to work in a production environment (hi guys! saw your running commentary on the lists, i absolutely loved it, it's a scream. i am a little miffed about the code-freeze comments though).

Another correction: Hetz Ben Hamo sent in this note regarding last week's VMware update (sm20000302_14.html#1) : "The VMWare fix credit is actually mine. I took this straight up their highest management, and after few emails exchanges, they recognized the problem, applogized and fixed it." Well done!

Mailing List Stats For This Week

We looked at 457 posts in 954K.

There were 210 different contributors. 70 posted more than once. 42 posted last week too.

The top posters of the week were:

1. No Microsoft Conspiracy After All

23 Feb 2000 - 29 Feb 2000 (14 posts) Archive Link: "Windows 2000 breaks the samba client"

People: Tom ZeruchaJeremy Allison

Jason Perlow reported on samba (reposted from the defunct samba-bugs) that Linux smbfs does not work with Windows 2000. (smbmount, which is part of the Linux-specific smbfs, is distributed in the Samba source code tarball, but is not considered part of Samba.) Subsequent posts revealed that the problem was in browsing shares, meaning that it is in smbclient (which is part of Samba) rather than in smbfs.

Tom Zerucha had already reported this bug twice, going back to last December. He sounded a touch impatient:

They've must of known about it for a long time, but no one who appears to develop for samba has even acknowledged any of the messages or asked for more information or simply said we don't give a rat's rear about W2K compatability, which would be more courteous.

It is at least partially W2Ks problem - I used TCPdump and apparently they are negotiating a very old variant of the SMB protocol, so tcpdump can't decode the packets. Or they may have added something too new. In any case W2K isn't handshaking with smbclient the way it does with NT or 98.

This is suspicious because Microsoft had to know that samba was out there when it created the W2K stack, so probably intentionally mutated it in some way to make it not work right. But they did the same with windows when DRDOS threatened them.

Jeremy Allison explained, "Yes we do care. I'm working on it for 2.0.7. More when I know more. It does appear to be broken for 2.0.6, but then again 2.0.6 shipped way before Win2k, so I'm not accepting responsibility :-)." As to the Microsoft conspiracy theory, he said, "Nah - never assign to malice what can be adaquately explained by incompetence :-)."

Not long after, he got a lead. "I'm going to work on fixing the smbclient thing today. I got a message from someone at Corel that helps in tracking down the problem (I love this Open Source stuff :-) :-)."

The e-mail timestamps are hard to believe, but ninety seconds later Jeremy was back:

Ok I've fixed it. Turns out it was a weird little bug in Win2k... well, maybe :-).

It seems that the RAP functions in Win2k can't cope with a max buffer reply size of 64K (0xFFFF) - it returns "No server memory" instead of the requested reply. So I fixed the problem by dropping the buffer size reply from 0xFFFF to 0xFFE0 in the Samba client code - an empirical number determined by trial and error (as are so many things in Microsoft's protocol :-).

The old buffer value of 0xFFFF works correctly with all previous versions of Windows (and should be the correct value to use, as you really do want to have the maximum permitted share list size returned), but Win2K seems to be "different". Hmmmm :-).

He continued, "So, no malevolent Microsoft plots :-), just a plain old bug (sorry to dissapoint "X-Files" fans :-) :-). Whether this is a bug in Samba or in Win2k I'll leave the reader to decide...... (fade out with Twilight Zone music :-). What is clear is that Microsoft didn't regression test with the Samba client code (although I know they did with the server code)." He appended a short patch against 2.0.6 that he had already applied to the upcoming 2.0.7. [Debian Linux users: see also Debian Bug #59411 ( .]

2. Linux Using Domain Authentication

18 Feb 2000 - 1 Mar 2000 (17 posts) Archive Link: "Linux as an NT CLIENT"

People: Jonathan HutchinsLuke LeightonPhil Mayers

Jonathan Hutchins wanted to know about using Linux with NT domain authentication. He posted to samba-ntdom: "Since most of the documentation assumes that the Samba box will be a server, it's not explicitly clear how one would get a Samba/Linux CLIENT to join an NT domain and rely on NT authentication for log-ins. Can this actually be done?" Luke Leighton was brief: "pam_ntdom."

Phil Mayers wondered exactly what Jonathan meant. He noted that "being a client on an NT domain" could have various shades of meaning. "But you need to be clear exactly what you mean, and how you're making Linux an NT client. smbmount will allow you to mount smb shares, but there's a program with Samba called smbsh, which uses a shell wrapper DSO to intercept filesystem calls, and create the equivalent of a network neighbourhood. Again, I don't know the state of integration between smb-agent, pam_ntdom and smbsh. Luke?" Answer: "all untested."

Jonathan was still confused. "I still have no clue what "pam_ntdom" is, or how I would "use" it. It's not documented in anything I've found on samba yet. What is it? Is it a compile-time option? Is it a keyword in recent versions of smb.conf that's not documented?" As for exactly what he wanted out of the Linux box, he had thought it would be self-evident. "I want my Linux workstation to use the NT PDC to authenticate users, so any user with a domain account can log in to the Linux box, preferably without me having to first create an account on the Linux box first."

Phil continued, about pam_ntdom: "Yes, still need a passwd/NIS entry. IIRC there was something under development called winbind, which is the equivalent for ypbind for an NT domain, rather than NIS. Very nice. But it was dependent on SURS, and hence probably TNG. Again, I don't know the progress." That got Luke started on an old favorite topic (see Issue #7, Section #1 (sm20000113_7.html#1) ). "yeah, tim's working on it. actually, absolutely Everything is dependent on a decent SURS implementation, and we don't have one. and no, dammit, the current one isn't good enough. however, as i was explaining to tim (it took a couple of days, and his code got a lot simpler when he got it), it's not the responsibility of samba, pam_ntdom, pam_smb, winbind, pam_smbpass, or anything BUT surs itself to solve the problem of mapping uids/gids and sids."

Phil, at this point, expressed the desire to code SURS lookups from an LDAP database. Luke replied, "luke howard has already written a sursldap, it's incredibly simple: it's a switch statement around two function calls. so it's been done."

3. NT Usernames Not Being Mapped

26 Feb 2000 - 29 Feb 2000 (8 posts) Archive Link: "amazing tng-0.6"

People: Vladimir StavrinovLuke LeightonPat LoPrestiTim Nijenbrink

Vladimir Stavrinov jubilantly (well, in jest anyway) reported a new bug in Samba-TNG, where his profiles were suddenly not being downloaded by the NT clients. He concluded, "What to do? Wait for tng-0.7?" Markus Stephany confirmed the problem. Luke replied, "gimme chance to try it out, meself. this one's quite tricky. we done a patch to "fake" this stuf as best as poss, it should actualy work fine."

Pat LoPresti tracked it down. "OK, the problem is that the "nt_name" field is never being filled in at all in the sam_passwd structure used by getsamfile21pwent(). This structure is created by sampassdb.c:pwdb_smb_to_sam(), which inherits the nt_name value from the same field in the smb_passwd structure returned by smbpass.c:getsmbfilepwent(). Since "nt_name" is never explicitly assigned in any of these places, it is not available for the %U substitution, so the empty string gets substituted instead." He posted a patch which worked around this by just using the Unix username in place of the missing NT username -- not the correct fix, but it worked at his end.

Luke had had it with the function in question.

lookupsmbpwnam() or lookupsmbpwuid() etc, in lib/domain_namemap.c, should be filling ALL the parameters, uid, gid, unix_name, nt_name, in correctly.

that's their xxxxing job!!! that's their sole, stupid, expensive task in life, and i'm fed up with that damn code. it's responsible for order-n-cubed traversion of user lists, recursive black holes and infinite loops.

i hate it.

and i don't really yet have a good enough handle on what to do to be confident about replacing it.

Tim Nijenbrink, meanwhile, came up with a very clever workaround, using a Windows NT environment variable to get the username: "I have been experiencing this problem to, and I substituted the NT username string %username% for %U. It seems to work for me."

4. HP and Samba

26 Feb 2000 - 3 Mar 2000 (14 posts) Archive Link: "HP supporting samba"

People: Francesc GuaschUlairiRoberto MelloJeremy AllisonDave Collier-BrownJohn HolmesPeter Bye

Francesc Guasch had a question for the samba list: "In the web it states HP does support samba and there is a link. Following this link I read nothing about samba, it may be wrong." Ulairi had some experience with HP, it seems: "HP, in their own inimitable way, will release the product as "CIFS/9000". More then likely, it will be a replacement (or a more advanced version) of their ASU/9000 LanMan product (Advanced Server for Unix). Having had to play with ASU/9000 and HP's all-time favorite game of "oh, you need a patch, but for that patch, you need these reboot-the-system-after-install patches, too. Oh, and if the system breaks after those patches, well, then you shouldn't have installed them", I'd not touch CIFS for a while. Get the LanMan product, it's stable and fairly nice." Others also confirmed that CIFS/9000 was indeed HP's version of Samba.

This prompted Roberto Mello to say: "I wish HP would more widely recognize that their "CIFS/9000" product is based on free software, Samba. I could only find the word "Samba" mentioned twice and in the Q&A. Not once in the fancy description of all the "features" of "CIFS/9000"." Jeremy Allison agreed, but explained: "HP told me they have customers who are frightened of "free software", so their marketing dept. don't want to tell them :-). HP are working very actively on Samba however, and have already submitted changes back to the main tree and are a very welcome addition to the Samba community along with SGI, Veritas, and other vendors." Ken Hall asked if, because of the GNU GPL, HP was required to give credit to the authors and provide source code. Jeremy Allison answered, "No, no need to give credit, but source code must be provided. HP are complying completely with this (I checked)."

Dave Collier-Brown also replied to Ulairi: "I'll bet you have an H-P 800 series system (;-)) The 700 folks are civil and helpful: if you have the choice, run your services on 700s."

John Holmes put in, "For what it's worth, I downloaded the HP version of CIFS/9000 and have installed it on a couple of machines. The installation went very well and I haven't had any problems so far, there was no need to reboot the system. It's been up for about a week. I think it does require HP-UX 11.00."

Peter Bye posted a nice long rant about various things HP, basically calling them johnny-come-latelies to the free software bandwagon. "In regard to HP supporting SAMBA, they seem to be going full bore on it as they are losing their customer base at a frightening rate. Unfortunately, HP is one of those companies that has most of their customers by the short hairs and treats them that way. It was not more than a year ago and HP was blaming all of our Server and Network problems on SAMBA, then it was SGI, then it was NT. The most incredible statment made by one of their Sr. Technical people on site was the HP's don't work well in "Mixed" Environments because they are the only one's that have a compliant O/S and software packages, NFS, AS/U, etc. As in SGI and SUN's NFS PV3 won't work with HP's NFS PV2 becuse it is non compliant. How about "Outdated" and a bad port to begin with." [...] "After all, they have a less experience than most of us when it comes to Samba would be my guess, although they claim to be up to snuff and have "Been on board all along", again, LOL. We'll see." [Much of this section may seem unfair to HP -- comments/rebuttals from HP are welcome.]

5. TNG File Locking Bug

28 Feb 2000 - 29 Feb 2000 (11 posts) Archive Link: "anybody else having trouble with tng cvs, configure, and locking?"

People: Greg LeblancLars Kneschke

Lots of people had questions about this one. Greg Leblanc got "first post" status:

I did a checkout of samba tng this morning, and when I run configure --prefix=/opt/samba, it zips (well, ponders) through a zillion checks, but pukes on the check for locking. To be more specific

'checking configure summary
ERROR: No locking available. Running Samba would be unsafe
configure: error: summary failure. Aborting config'

Seems to me that I'm probably broken, but how?

Several people posted nearly identical reports.

Lars Kneschke got on it right away. "currently i checkout old samba tng versions, to see where the error was first seen. It was between 25. and 27 february. I think i'll found the bug soon." Sure enough, he soon found a bug in the configure script: "ac_try is "$CPP $CPPFLAGS conftest.c >/dev/null 2>conftest.out". But CPP and CPPFLAGS is empty ..." Problem solved.

6. TNG `become_root()' Bug

28 Feb 2000 - 2 Mar 2000 (17 posts) Archive Link: "TNG 0.7 - can't join domain"

People: Luke LeightonMichael BreuerTim ColeSander StrikerPat LoPresti

Michael Breuer had the not uncommon complaint that he was having some trouble with Samba-TNG. He posted to samba-ntdom, giving some sparse details on his unsuccessful attempt to join an NT workstation to a Samba-controlled domain.

Luke Leighton was a little frustrated about the lack of detail in the report.

please, people, be more specific. time and time and time and time again, i have to repeat and repeat and repeat this: if your report doesn't contain specific instructions and information, it's completely useless.

"i can't join the domain".

well, which domain?

how does it not join?

how are you attempting to join?

did you type the username / password in the network control panel dialog?

did you know that you should do this?

does the trust account already exist?

does the unix account (myworkstation$) exist?

are you using ldap, smbpasswd or samtdb or mysql or nt5ldap as the password back-end?

these are just a few of the issues i can think of when someone says, "i can't join the domain", and i'm really sorry, michael, it's nothing personal, but it's really exasperating to be repeating this quite so many times [a day]. after three years, i'd have thought people would get it by now.

never mind, please don't take this personally: i'm a little bit... hmmm... stressed isn't quite the word. transitional phase coming up, reduced tolerance levels.

sorry ppl.

(The "transitional phase" turned out, we learn from a separate post, to be a move and a job change; Luke ended up off the net for the better part of a week. This singular fact greatly affected list traffic patterns and CVS commit rates....)

A very contrite Michael duly posted the details of his setup: Windows 2000 trying to join, using the "create machine account" dialog from the client, etc. Luke replied, "hmm.... ok, 'cos i'm doing exactly that, and it works. hmm: can you take a look in the logs, at level 100, for "status: C000" or maybe "status:c0000"? this last error code will say what's failing. then let me know what you think it might be, from the info proceeding the error-status-code." Michael found the error code: "Looks like 0018 status : c0000017 (both smb and netlogon). The smb log also contains ERROR: unbecome root depth is 0 (from lib/set_uid.c:354)."

That was enough to go on. Luke replied: "damn, damn - ok, i bet the two are related. ok.
unbecome_root() - really does unbecome root
samr_drect_query_userinfo() - fails because it's not root
unbecome_root() - fails because we're already non-root.
dammit. i'm not certain as to how to eliminate this, because according to some people we should only be running as root, which is a security risk if we do it at the moment because there is no checking otheerwise on file access inside the msrpc code. i could "fix" this by doing an increment on become_root() instead of root_depth = 1 do root_depth++..."

Tim Cole warned: "You'll have to be real careful doing that, though -- it's entirely possible that some code, somewhere, expects that it can always safely do non-rooty things after it's called unbecome_root()... if that's been getting called from code that itself becomes root..."

Sander Striker suggested: "I guess people are suggesting running as root and when doing file access checking something like:

  become_user(); check_access(file); unbecome_user();
" To which Tim replied, "*cough* race conditions *cough*" For his part, Pat LoPresti suggested a pair of macros to wrap the become_root() calls in, such that forgetting to pair them properly would yield an obvious compile-time error.

7. Duplication of Effort, and More Talk of Branch-Merging

28 Feb 2000 - 1 Mar 2000 (10 posts) Archive Link: "Win2K problem looking up SIDs to names."

People: Jeremy AllisonLuke LeightonPhil Mayers

Jeremy Allison came across a new MS RPC call that he didn't know about, and asked samba-technical if anyone else knew anything: "I'm doing a security -> view on Win2k and its giving me a open"\lsarpc" pipe call, followed by an OPEN_POLICY2, followed by this rpc call (which we don't decode). BTW: I checked in TNG and we don't decode it there either." He posted a structure dump of the unknown call. "Any idea what this one is ? Without it Win2k won't go onto do the lookup sids call. Under NT4.x, after the OPEN_POLICY2 it goes straight into the

api_rpcTNP: api_ntlsa_rpc op 0xf - api_rpc_command: LSA_LOOKUPSIDS
call and all is well (correct unix names shown in dialog box)."

Luke, predictably, knew all about it:

the 0x39 lsarpc opcode you are supposed to return a fault pdu to -- just like nt 4.0 does.

as a result of returning the fault pdu, nt5 will carry on by using different msrpc functions.

if you were running tng you'd find that it worked fine.

see the cvs message i sent about bind nack and fault pdu (i added nack support to tng yesterday) i wrote some specific comments for you in it.

btw we HAVE to do this merge, it's not ok to be constantly rediscovering everything and duplicating / wasting effort on all these things. especially as this has been going on for far too long, already.

i count, from a quick recall, about four, maybe five, areas where you have spent time reinventing what i already have in tng, and sometimes (which is REALLY bad) adding things to cvs main or 2.0 but NOT adding them to tng.

this cannto continue for much longer

Jeremy agreed. "Actually, sniffing a Win2K to NT4.x was going to be my next step. But I thought you might already have addressed this, so thanks :-). This is why your tng branch is extremely valuable. It's just not production code (yet :-)." Elsewhere: "Luke, HEAD is slowly becoming TNG, it just takes a while as the code is moving across as it gets reviewed. This takes a lot of effort, don't get disheatened."

Phil Mayers wanted a clarification on that last bit: "Can we take it from that remark that code is currently being ported from the TNG to the HEAD branch?" Yes, said Jeremy:

Yes, I am actively filtching working code from tng and putting it into HEAD and 2.0.x :-).

However, the more radical stuff (the split daemon architecture) is exactly what I can't move over right now, as it is (as described) a radical change. I think it's the right thing to do long term as the code in tng looks very clean here, but it needs careful consideration before putting into production.

The split daemons will never go into 2.0.x, as I'm trying to make 2.0.x bugfix and patch updates only but may make it into HEAD (aka 3.0.x).

8. Dead Processes

28 Feb 2000 - 1 Mar 2000 (7 posts) Archive Link: "Multiple smbd processes generated"

People: Dave Collier-BrownFrank VarnavasJeremy AllisonAndrew BoswellBill JojoUsing Samba

Andrew Boswell, running Tru64 Unix, was having occasional problems with scores of defunct smbd processes hanging around, none of which could be killed. In extreme cases this was filling up the process table, forcing a reboot of the Samba server. In less-extreme cases, it was causing denial-of-service to whatever user it happened to. The processes were idle -- not chewing up CPU time. Bill Jojo claimed to have seen a similar manifestation on AIX 4.3.2, but it had only happened twice, some time ago.

Dave Collier-Brown suggested: "A quick avoidance: try setting

keepalive = 30
in the globals section of your smb.conf. This will trigger a check for a live connection after every 30 seconds of inactivity. (For systems which aren't suffering from the problem you have, something like every 10 minutes is perfectly sufficient)."

Frank Varnavas had a different theory: "I've seen this happen when one or more NFS mounts hang. The processes in question hang on the NFS access and cant be killed. The NT redirector times the session out, closes the connection, and opens a new one. This will happen every 45 seconds (the default redirector timeout). Limiting your samba exports to local filesystems should prevent this, as well as improve response time." Jeremy Allison said similar: "If the process cannot be killed with -9, then it isn't a Samba problem. Some kernel resource the processes are waiting on is not responding (usually nfs). Are you re-exporting NFS drives ?" Andrew answered: "There were NFS failures in /var/adm/messages corresponding to the times on, some but not all, of the hung smbd processes. We'll implement the "keepalives" parameter suggested by David. NFS hopping is pretty crucial to our current Samba architecture. Its one of the features which we really like about Samba and usually works fine over our network. So we can't get rid of the problem by only Samba serving local filestore."

Dave had an idea for eliminating NFS from the picture: "If you're using automounter and NIS to serve home directories via NFS, you can use a Samba option to auto-redirect the SMB connections to the actual fileserver with the home directories. This basically allows samba to say says "redirect your mount request to <server x>", where server x has the actual disks in question and is also running Samba." He gave a link to Chapter 6 ( of his book Using Samba ( . Also, he said, "I think one could fake a homedir map without using nis: It's a "mere matetr of programming" (;-)) Personally, I try to centralize home directories onto a fairly large server, and use the budgetary savings to fund RAIDing it and ordering some fast-repair options..."

9. More Shared Library Woes

29 Feb 2000 - 1 Mar 2000 (8 posts) Archive Link: "tng and shared libs"

People: Jean-François MicouleauPeter SamuelsonElrond

Jean-François Micouleau was getting crashes in the Samba-TNG tools if he tried to run them in-place rather than installing them into the system hierarchy. He posed the following to samba-technical: "I'm required to run make install and use /usr/local/samba/bin/rpcclient instead. why ? I want to compile and run the binaries in the build directory."

I asked him, "What OS are you running? Sounds like a libtool bug. The shell scripts are supposed to work the way you tried." Elrond, the man behind the Samba-TNG libtool support, agreed, and added:

Could you send me the following things?

He also suggested "./configure.developer --disable-shared" to disable building the shared libraries.

Other ideas flew about, mostly concerning out-of-date libraries in the system paths, and LD_LIBRARY_PATH. The care and feeding of shared libraries really can get complex at times. Then Elrond posted an update: "This time it looks like it wasn't libtool. It looks like an old version of bash (1.14) did have some problems with those shell-scripts, upgrading bash seemed to have helped."







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.