Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Samba Traffic #7 For 12 Jan 2000

By Peter Samuelson

Table Of Contents


The mammoth SID/UID thread wrapped up this week, so we cover it in some (perhaps too much) detail before consigning it to the graveyard of dusty e-mail archives. Unfortunately the issues involved were not resolved in full, and this has the feel of a topic which will most likely come up again, like devfs for the Linux kernel. As with all long, healthy discussions, the topics were divided between philosophy, implementation details, and tangents. We could not hope to cover here all that went on in that thread, and you would not want to read it.

The other big news of the week is Luke Leighton's integration work, where HEAD-branch CVS code is now allowed to play with SAMBA_TNG-branch code. The idea is that in a sense you can now have the best of two worlds: the increasing stability of the HEAD (pre-3.0.0) code for your base smbd and nmbd services, along with the feature proliferation of other RPC service code from SAMBA_TNG. This is starting to get a lot of attention: many bug reports are now mentioning the context of a "pure SAMBA_TNG environment" or a "mixed HEAD/TNG environment".

Mailing List Stats For This Week

We looked at 483 posts in 967K.

There were 172 different contributors. 61 posted more than once. 22 posted last week too.

The top posters of the week were:

1. SID to UID/GID Mappings

23 Dec 1999 - 6 Jan 2000 (191 posts) Archive Link: "Security Identifier (SID) to User Identifier (uid) Resolution System"

People: Jeremy AllisonNicholas WilliamsLuke LeightonLeslie BarstowSteve LangasekJohn MalmbergTimothy ColeMichael StockmanLuke HowardNicolas Williams

Luke Leighton started it.

He posted to samba-technical about a new proposal ( involving mapping functions from UIDs to SIDs and back. This is an interesting and potentially complicated issue. In a nutshell: users in Unix are identified only superficially by a username; the username is translated to a userid (UID), a (usually) unique integer, and the UID is really the important part as far as most operating-system functions are concerned. Similarly, Windows NT systems keep track of users by a "DOMAIN\USERNAME" pair, and this is translated internally to a security identifier (SID). But while a UID is a single integer (16- or 32-bit, depending on Unix brand), SID consists of a series of 32-bit integers strung together.

Samba typically runs on a Unix system, so must use the UID framework for keeping track of things like file permissions -- in other words, when an NT user authenticates himself to use Samba services, these services must be performed on behalf of a particular Unix UID. Current versions of Samba accomplish this by making the following assumptions:

If, instead, an automated way were found to map a Unix UID directly to an NT SID (and vice versa), some of these limitations would disappear. Luke was feeling out how to go about providing such an automated mapping function, as well as an extended mapping table format to cover all the corner cases the status quo does not.

There was, shall we say, a lot of discussion.

Nicholas Williams argued for two or three improvements to Luke's scheme, including using a configurable SID prefix for a given Unix username "zone-of-authority" (NIS domain or local machine). Luke liked this idea in particular and they discussed it a bit.

But Jeremy Allison was still back on page 1. "Ok, let me explain why I am fighting tooth and nail to keep Luke's SID mapping table out of Samba." He then went into specifics:

If we step back and look at the actual problem we are trying to solve, then we see that hacking Samba with mapping tables is the wrong approach.

The problem as I see it is that people want to have a common account database between NT and UNIX systems, with only one place to update to add/delete users. People want to have only *one* user or group identifier to uniquely identify a name. NT uses RIDs relative to a domain SID, POSIX uses uid and gid numbers.

If we adopt Luke's mapping table approach then we have not acheived this goal, as creating a table to map particular SID entries to POSIX uid/gids allows an artificial unification between the NT and UNIX databases, but there is no *real* unification. If someone updates the NT account db, or the UNIX one, without editing this mapping file, the admin is hosed.

This is not a scalable or workable solution.

IMHO the correct way to approach this problem is to actually unify the account databases. If we do this then the arguements between SID -> uid/gid mapping just go away, as the accounts *really* only exist in one place (the NT SAM db).

Unfortunately the account db has to be held in the NT format (although not neccessarily on an NT machine) as MS don't release enough information to replace the authentication and authorization code on NT. On UNIX however, we have PAM (for replacable authentication) and nsswitch (for replacable authorization - ie. enumerating user and group lists).

Now imagine that we write the winbind daemon on UNIX systems with nsswitch. Quick update for people who haven't followed samba-technical for a bit - winbind is a nsswitch module for UNIX systems entered into an NT Domain that allows *all* user/group lookups to be remoted to an NT-format PDC or BDC. ie. when getpwnam() is called a lookup is done to a PDC or BDC and a UNIX struct passwd entry is synthesized from the SAM database entry returned. This synthesis includes mapping from the SIDs returned in the SAM db entry to a UNIX uid and gid list for the user. Note that as a UNIX machine can only be in one NT domain then we can take the NT RID directly as a 32 bit value from every SID and use it directly as a UNIX uid_t or gid_t (on 32 bit uid_t and gid_t UNIX systems).

THIS is the correct place to do the SID -> uid/gid mapping, not Samba. And when you look at the problem this way, with the correct abstraction layer, suprise, suprise, it becomes very easy.

Once we have this then it makes perfect sense to have a completely unified SID/uid/gid space, as this is what we actually have.

His parting shot: "I think the moral of this story is : SAMBA IS NOT AN OPERATING SYSTEM. :-) :-)." [Editor's note: PAM and nsswitch are all very well for Unix brands which have them. Last we heard, PAM was only implemented on Linux and Solaris. Variations on nsswitch are a bit more widespread.]

Nicolas Williams agreed with a lot of this, but felt he had to mention another possibility: "Microsoft includes a NIS server with w2k that makes lookups via LDAP into ActiveDirectory. The account/principal/uid/sid/whatever information is all in one place." Using an LDAP-based PAM client on Unix could thus unify the namespace. He mentioned another possibility, as well: XAD, Luke Howard's Active Directory workalike, which is currently in development. Jeremy reiterated that his main issue was that Luke was trying to do all the complexity within Samba rather than in some sort of separate module. Whereupon Nicholas had an idea: "Here's what I suggest: have an API to lookup uid/gid<->SID mappings and let others provide modules to implement the lookups any way that they want. Then you have no code to implement these lookups in Samba; these external modules would just be shared libraries."

Luke hadn't realized that Jeremy felt so strongly about keeping the mapping table out of Samba. Jeremy explained: "Samba is getting unmanagable complex. It's a fileserver dammit, not a complete UID mapping solution. That's a *different* program." Luke then reminded him, "it used to be just a file server. when we decided to do NT domains, it became (becomes) a hell of a lot more than that. this is one of the reasons why i wish to separate the NT domain (MSRPC) stuff into separate programs (daemons). it says, "samba FS stuff has absolutely so little to do with MSRPC that you can subdivide it into a separate program"."

They argued back and forth a bit, and hit on the topic of whether it was desirable that Samba be aware of distinct users from multiple NT domains. Luke thought it was. "ok, it comes down to this. i think it's perfectly acceptable to have Unix servers to be part of arbitrary NT domains. you, however, do not. if you can accept that i can come up with something that fulfils my goal to make Unix fully NT-domain interoperable (by definition making unix part of arbitrary NT domains, under that unix admin's control, of course), then i will go ahead and do it." He continued, "SURS tables are not even needed, under your scheme [with your decision / hypothesis], because there is no _need_ to map between uids and SIDS, because the entire thing is so limited and restricted [to one domain per samba server] that you only really need to use usernames. in other words, SURS tables take samba to the next level. full nt domain interoperability. if you think that's too complex, then please stick to working on the file serving portions of samba, and leave the nt domain interoperability stuff to me."

As posts flew back and forth it became clear that the main argument revolved around whether a single NT domain per Samba server was an unnecessary limitation. (Jeremy's take: "it makes mapping the Domain SID database to a POSIX uid/gid database much easier. To put a UNIX box in more than one domain complicates that mapping immensely. Simple is good." ) Leslie Barstow sided with Luke: "Simple is not realistic in this case, though. The last couple of jobs I've worked at both used multiple domains - people using a server could be from any of them."

At this point there was a refreshing diversion. Leslie wanted to know: " is there an 8-character limitation to the getpwnam() implementation? IIRC, at least the passwd file has this limit (in Linux)." Steve Langasek said it likely depended on an individual implementation of Unix. When pressed, he continued: "I just checked GNU tar, and it handles long names cleanly. Indeed, the only issues I've ever found with using long usernames on a GNU system are cosmetic ones. It's generally not recommended that one use usernames longer than 8 letters, on the grounds that "you can never be too careful". But if there's an overwhelming need to use long usernames on a system, then everything will fall into place quickly enough."

Then it was back to SIDs. At one point Michael Stockman had brought up his company which uses different users from different domains and asked if Samba could cope. Jeremy replied: "I don't see why not. Whenever these users access files on a Samba server they're doing it as a uid the Samba server knows about, so what is the problem ? Yes if they look at the ACLs on a file they will see users local to the Samba server as entries, but that's exactly what the ACLs on the Samba server represent." Samba would primarily identify the users by username, he explained, so the usernames in different domains would have to be unique. Luke, of course, didn't like that limitation: "this is something that really bothers me. i consider it to be unacceptable, especially as there are perfectly good schemes to fix this problem." Jeremy replied, "Why does it bother you. It's the same thing that NT does in this case :-)." Luke went on to say that of course you could duplicate your usernames in multiple NT domains, but later John Malmberg cut in:

Actually, this situation will cause all sorts of interesting problems in a PURE MICROSOFT environment.

Much of Windows NT does not know the difference between the two accounts and will get them confused.

only one "fred" will be recognized in the WINS database, and will receive all messages directed to either "fred" account.

Large NT sites with multiple domains typically have to assign a prefix or a suffix code to the username to indicate the domain just to prevent this type of mess :-)

Luke didn't think it was a pervasive problem: "this affects only the messageing, but i am glad you brought it up. we should not have to deal with the mess created by microsoft, and it's only because of the flat WINS db system: ther are ways round that, such as using scopes."

There was then a bit of discussion about how one would permanently integrate a SID into the standard Unix framework of passwd file entries. Leslie Barstow ventured, "We could put the SID in the GECOS field..." Steve Langasek pointed out: "And then, imagine what happens if an admin forgets to lock down 'chfn', or any of a handful of other utilities that let a user change his/her own GECOS entry. Whoops.." Leslie later admitted: "You take all the fun out of it. What you say is true. I don't think the current framework allows for much better than this, however. It *would* satisfy the request for "appliance-mode" systems."

In another sub-thread, John Malmberg and Steve Langasek discussed some differences in semantics between Unix file permissions and NT access control lists. Those difficulties are well known, and account for many FAQs on these lists (where users get unexpected permisssion semantics in Samba because they are thinking in NT terms).

Eventually Luke and Timothy Cole started discussing implementation. Luke's suggestion of an API was:


	DOM_SID sid;

int surs_posix2nt(CREDS_NT *nt, CREDS_POSIx *posix)
int surs_nt2posix(CREDS_NT *nt, CREDS_POSIx *posix)

He asked if Timothy wanted to implement this. Timothy's response was that he might, but he preferred an API such as:

int surs_sid2posix(surs_posix_id *id, const surs_sid *sid);
int surs_uid2sid(surs_sid *sid, uid_t uid);
int surs_gid2sid(surs_sid *sid, gid_t gid);

After a bit of discussion, Luke agreed.

2. Question about Samba

1 Jan 2000 (5 posts) Archive Link: "Samba as PDC"

People: Keith LynnSeth Vidal

Keith Lynn wondered about multiple domain support. "My question is if it's possible to have one UNIX server respond to different workgroups. I only want certain users to be able to have access to these labs and want to use a different workgroup for each one."

Seth Vidal suggested just using multiple shares on the server, and giving different groups access do them. He also mentioned the possibility of running multiple smbd instances binding to different IP addresses. This turns out not to be very hard:

So if you have a network:

you server has:,,

Each one has a different samba server bound to it using the following directives in the smb.conf(s) you will write. for

  interfaces =
bind interfaces only = yes

etc etc for the other 2.

3. File Locking in The BeOS

2 Jan 2000 - 3 Jan 2000 (5 posts) Archive Link: "Seems BeOS has neither fcntl nor lockf"

People: Richard SharpeJeremy AllisonChris HertelAllen Reese

Richard Sharpe had this to report on samba-technical: "I have investigated further, and the Samba configure script for 2.0.6 is having problems with fcntl under BeOS. It seems to return -1 for everything. It also seems that lockf is not implemented. Is there any other way to work around this with Samba or am I SOL?" Jeremy Allison was matter-of-fact: "SOL I think. Samba needs locking badly to work."

Chris Hertel said, "I know someone who works for Be who does networking stuff. Should I rattle his cage?" Meanwhile, Allen Reese finally remembered where he had seen locking in The BeOS before:

they use, lockf(), or fcntl() then fall back to flock()... It shouldn't be too hard to get lockf() working, Hey I remember where the source to BeOS lockf is. the source to libroot, has the source to lockf() in it. for some reason it isn't compiled on BeOS. anyhow here's the path to libroot source off a R4.5 cd:

/BeOS\ R4.5\ x86/_packages_/extras/optional/develop/libroot/

somewhere in there should be lockf.c which contains it. ;)

4. Alternate Character Sets in Samba Filenames

3 Jan 2000 - 6 Jan 2000 (14 posts) Archive Link: "Character set and client code page in samba 2.0.6."

People: Jeremy AllisonGiulio Orsero

Krzysztof Hrebeniuk was having trouble using multiple character sets. His Windows computers used Code Page 852, and his Unix server used ISO-8859-2. He entered this information into smb.conf, and Samba was making the proper conversions, but smbclient was garbling some of them. He reported to samba-technical.

Giulio Orsero thought it was a known issue to be fixed in Samba 2.0.7. Jeremy Allison thought about it some and said: "Ok, my guess is that there is a double conversion being done somewhere. I'll take a look and try and find it."

Some three hours later, Jeremy produced a patch. "Ok, I have found the bug. It was a double language convert problem. In 2.0.6, libsmb/clientgen.c takes care of all language conversions internally, in that it should only be passed UNIX character set strings and will convert any needed strings to dos codepage format before sending anything to the server. The correct solution was to take out the CNV_LANG and CNV_INPUT from the client/client.c code, as the client should now only deal with UNIX string input/output." Giulio, and later Krzysztof, reported success.

5. CVS Branch Mix & Match Now Possible

3 Jan 2000 - 5 Jan 2000 (15 posts) Archive Link: "Combined use of samba cvs main and SAMBA_TNG"

People: Luke LeightonJeremy AllisonLars KneschkeJens SkripczynskiSander Striker

As discussed in Issue #3, Section #5, Luke Leighton believes Samba should be more modular. He started splitting things up not long after (see Issue #4, Section #1), and at the time, one of his stated reasons was to allow mixing and matching different services from different CVS branches to coexist on one computer. Objections came up at the time about modifying the stable code branch too much for the sake of this goal.

Luke has now done it. He told samba-technical and samba-ntdom:

finally! a way to get the best of samba cvs main (development version 3.0, derived from the 2.0.x tree) and samba, the next generation (nt domains for unix project).

it's really, really simple.

download, compile and run samba cvs main's smbd, nmbd etc.

download, compile and follow instructions in SAMBA_TNG branch's source/README file, *except*, do not run smbd and nmbd from SAMBA_TNG.

the cvs main smbd will automatically check for the msrpc services running [from the SAMBA_TNG branch]. if it doesn't find them, cvs main smbd will fall back to using its own, internal msrpc code.

Unsurprisingly, Jeremy Allison was skeptical. "Unfortunately I'm not amazingly happy with the code changes as they seem to be a bit big and touch a lot of subsystems." He continued:

I note that when you open the pipe in the lock directory you do *no* permissions checking to ensure that this pipe was created by a root level process.

Passing off authentication requests to whichever process created the pipe may be considered, well, suspect.

I'm not sure the code you wrote is a security problem, but I need to think about potential exploits and be concerned here I think.

I'm not going to revert the changes you made, I'm going to let Andrew take a look and decide first, as he is officially in charge of HEAD.

Please don't put these changes into the 2_0_X branches yet.

Luke was obliging, but asked how to do the permission checks Jeremy mentioned. Jeremy pointed him at the stat() function, and continued: "Actually, you really should have read W. Richard Stevens (now sadly deceased) "Advanced Programming in the UNIX Environment" before doing any of this. RUN (don't walk :-) to your nearest technical bookstore and buy this book. Then buy all his other books for good measure :-)." [Jeremy is right. APUE, as it is known, is almost universally acknowledged to be an indispensable reference for anyone doing serious Unix programming. It is very thorough yet very readable.]

Jens Skripczynski couldn't get the mixed environment to work. An NT workstation refused to join the domain. Sander Striker thought it might be related to which order the daemons were started in. Luke had another idea.

you will need to add your own samba server as a trust account:

smbpasswd -a -m ny_sama_server

Lars Kneschke had a bit of discussion with Luke to make sure he was doing everything right. (He was.) Eventually he got it to work. His report:

  1. get samba from cvs (the mainbranch and branch SAMBA_TNG)
  2. "./configure" and "make" both, i did "configure --prefix=/opt/samba-tng" because i liked it more
  3. "make install" in the SAMBA_TNG directory
  4. copy "smbd" and "nmbd" from the bin-directory in the MAIN-sambatree
  5. make install doesn't create the <sambadir>/private directory, create it
  6. create the file smbpasswd in this directory (touch smbpasswd)
  7. start all daemons from the <sambadir>/bin directory (i started first smbd and nmbd, and then the others)
  8. create machine accounts, you need machine accounts for the samba server and all win-nt workstations
    example for my server(the name of the server is weigon)
    	useradd "weigon\$"
    	smbpasswd -a -m weigon
  9. Now you can also add user accounts
    	useradd user
    	smbpasswd -a user

Now you can join the domain. After joining the domain win-nt must reboot! (surprise! :-))

6. Temporary Memory Allocation

3 Jan 2000 - 5 Jan 2000 (11 posts) Archive Link: "talloc()"

People: Andrew TridgellLuke LeightonJerry Carter

Andrew Tridgell found a bug in Samba memory use, where Samba was overflowing a static array. The static array was used to prevent having to use lots of malloc() and free() all over the place, but the problem with static arrays is that they are, well, static. Tridge related this on samba-technical, using it to illustrate a point:

the real problem is the lack of a good temporary memory allocater/free system in Samba. We can't use alloca() as it ain't portable enough.

before i build a new memory allocation (pool) system for Samba, can someone point me at a good one? Note that I'm not interested in just a malloc library, those are trivial to write and don't meet our needs anyway. What we need is something that allows us to allocate temporary memory and free it in one fell swoop in the main event loop. I can probably write one in a day or so, but if there is a good one out there then please point it out so I can save some time.

of course, the simple fix is ot up the number of static strings, but for Samba 3.0 I'm trying to fix the really fundamental design flaws, not exacerbate them :)

Luke Leighton wanted this very badly. He described a scenario in RPC code where this would be helpful, then sketched out an API: "if you can create a talloc(MEMORY_STORE *store, size_t size),and provide MEMORY_STORE *init_talloc(), free_talloc(MEMORY_STORE *store) as base-level functions, then i can use it to trash locally-malloced memory on a per-function call basis, without having to worry about memory leaks and per-msrpc-function-call specific freeing routines."

Tridge responded, "yep, thats basically what I had in mind, exccept that I was going to have a couple of global memory stores for specific purposes, not associated with a particular object. These would get freed up in the main idle loops." Luke then mentioned reference counting, but Tridge was skeptical. He said, "Remember, we don't have a garbage collector and we can't do one in C (no, I don't want to start using C++ in Samba). I don't see how to ref count memory without adding code at all the points you would need a free if you just used malloc/free. Think about the lp_string() case and how it is currently used."

Jerry Carter had a pointer to a temporary allocation library, but it was too late. Tridge had already implemented and committed his own, lib/talloc.c, some 60 lines of code.

7. Samba and LDAP

3 Jan 2000 - 4 Jan 2000 (6 posts) Archive Link: "Who is using Samba with LDAP and how?"

People: Richard SharpeIgnaci CoupeauLuke LeightonIgnacio Coupeau

Richard Sharpe was curious about the Lightweight Directory Access Protocol. "I am interested in knowing who is using Samba with LDAP and how? What schemas etc? How well is it working? Have the recent changes in the source code structure caused you problems etc?" This on samba-technical.

Ignacio Coupeau does, for one. "After a term , with 420 NT ws(4.0 SP5) in 7 domains (classrooms), the experience is amazing and very stable: no breach at all. The system worked 24 h/day without any problem. The first month we found the PDC (linux intel RH kernel 2.2.10) is very sensitive to memory (128 MB runs very fine for 60 simultaneous login). We are using two LDAP servers (linux, openldap 1.2.7), with 2 processors (by the way, very idle); these LDAP serves all LDAP stuff: samba, mail, web access, and so. We manage all accounts with a few perl scripts and some crontabs. In the running system, we use CVS HEAD/15-OCT-99." He even gave a pointer to

Ignacio mentioned in passing that the SAMBA_TNG branch was malfunctioning with regard to user profiles, so Luke and he went on a small bug-hunt. Luke concluded: "in SAMBA_TNG? yes. both schemas are _not_ what was originally planned. jean-francois wrote a very good schema, and i broke it. someone then sent in a patch for 2.0.3-or-so, _just_ around the time when i was writing the "password database api", and no - i didn't want it to go into 2.0.x, we're not ready to finalise the schema. they didn't send a patch in that conformed to the new pwdb api."

Meanwhile, Martin Hofbauer reported also using the RFC2307 LDAP scheme.

8. Domain Login Options in smb.conf

3 Jan 2000 - 6 Jan 2000 (29 posts) Archive Link: "Using Samba -- domain logins"

People: Jerry CarterSteve LangasekLuke LeightonRichard SharpeUsing Samba

Jason Podgorny had a question on samba-docs and samba-technical about the book Using Samba and its treatment of the domain logons option. How did this option interact with the security option?

There were three main points that were subsequently discussed. The first: how the various Samba options map to the NT roles of PDC, BDC, NT Workstation, etc. The second: whether it is useful to distinguish between Windows95 domain services and NT domain services, i.e. to provide one but not the other. The third: in what circumstances encrypt passwords = yes is needed for these roles.

Jerry Carter noted that a non-PDC Samba will cheerfully authenticate login requests. This made it somewhat like a BDC, only different, and he was worried about this: "This should be forbidden in current setups (and in the current code). Reason: Consider what will happen if someone configures a domain member to perform domain logons on the same subnet as the PDC (or using WINS). This discussion has been done before. Haven't actually tested this scenario, but we all have a fairly good idea of what will happen. If this setup is allowed it should be only when Samba is able to correctly function as a BDC. "officially" that is."

Steve Langasek's two cents: "I've had some success using "domain logons = yes" on a machine that was not the PDC for a domain, so the "domain logons" and "domain master" options do appear to be completely orthogonal." To which Luke Leighton replied:

BDC: domain logons = yes, domain master = no, encrypt passwords = yes.
PDC: domain l = y, dm = y, ep = y.

Steve wanted to split out the concept of "being a BDC" from the concept of "accepting Windows95 logins". Jerry did not, and said, "In my opinion (at the moment) the two are inseperable. A Samba server (using accounts from a PDC) validating Win9x logons should also validate NT client logons (and this is a BDC)." Richard sided with Jerry until he realized: "OK, now that I understand that you are talking about "what should be" rather than "what is now", I tend to agree that we need to split these things out."

Somehow the topic of quality-of-documentation came up. Jerry disagreed that this was the problem:

One of the main problems in my opion is that so much of configuring Samba requires and understanding of Windows networking, which you're standard UNIX admin doesn't have. (no flames on this please. I have to administer both). The whole area of knowledge is just so much more than

He took a coffee break, then continued: "Do you think that Paul Vixie has this kind of problem with DNS? I think people assume that DNS, Sendmail, etc... are hard to administer. However, MS has said looks our network is so easy!! And therefore Samba should be easy. If MS networking is so easy, what do I spend 80% of my time administering windows boxes?"

9. Diagnosing One User's Network Problems

4 Jan 2000 - 7 Jan 2000 (12 posts) Archive Link: "Ethernet Errors - One Direction Only"

People: Dan KaminskyElliot MetsgerSimon Murcott

John Jaeger posted to samba-technical, describing in some detail a problem he was having with file transfers in Samba. Downloads to a Windows box were working fine, but uploads from there to the Samba server were running into RX (receive-queue) overruns. He was using a D-Link card (sporting a Realtek 8139) on the server. Dan Kaminsky summed up the problem: "If Linux pulls, the transfers work. If Windows pushes, the Linux box gets DOS'd." He suggested various tests: changing the Ethernet MTU (maximum transmission unit: the maximum size of individual packets of information) values at each end, using FTP either direction, and trying different network cards.

John tried these different things, and pinpointed the D-Link card as one source of problems: a Linksys (LNE100TX, a Digital 2114x clone) card worked better (though still not well). Elliot Metsger was not surprised about D-Link: "I have to tell you that in my experience, D-Link equipment has been the source of many a network problem. It wreaked havoc on my network - ports got partitioned, etc. etc. So now I don't use any D-Link products at all. I wasn't able to pinpoint the problem exactly, but when I removed the D-Link equipment, my problems went away. Now I use Netgear 10/100 cards exclusively, and I have no complaints." Simon Murcott told the same story. "I have seen similar. My network which is mainly a mix of various 3com and SMC cards works very well. One machine withg a dlink card in it was introduced and the collision rates went through the roof. Turned the machine off and things we sweet as again."

10. Various Problems with Samba 2.0.6

4 Jan 2000 - 6 Jan 2000 (3 posts) Archive Link: "cvs SAMBA_2_0: some problems"

People: Jeremy AllisonGiulio Orsero

Giulio Orsero could think of five problems in current Samba stable code. He told samba-technical:

  1. smbclient has some glitches with error reporting in its mput code
  2. smbclient cannot correctly rename directories
  3. the smbclient command ls does not work with Samba servers
  4. the veto files option does not parse all wildcards correctly
  5. Samba does not seem to be closing/reopening log files when it should. This causes problems when logs are split and/or compressed on a regular basis.

Jeremy Allison replied that the first two of these were fixed in latest SAMBA_2_0 CVS code. Giolio Orsero confirmed this.

11. More Unofficial Documentation

7 Jan 2000 (2 posts) Archive Link: "New webpage for Samba TNG"

People: Lars Kneschke

Lars Kneschke posted this announcement:

I have created a webpage, to let you know what i have done to install Samba TNG. Until now i have finnished the "compile"-part only. I hope i can create the "configuration"-part tomorrow. If there are any spelling errors, plese send me message. I'm a german.

Until now, i can join the domain with my Win-NT workstation, profiles work, startscripts are working and if i login as root, i can also work as administrator.

Anyone interested in setting up Samba, The Next Generation may wish to consult

Eight hours later, Lars posted that he had made a few updates, but was still wanting technical review.







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.