Two machines fight over being DMB

[Doug Bissett]

I have two machines (IREBBS7 and SLY) that seem to want to be the DMB. I am pretty sure that I have the config set properly to make SLY always win, but it seems that the other, somehow, thinks it has won, until the other decides that it should be the DMB, and forces it back again. This often results in having two DMB machines, and the others can't seem to make up their minds which one to follow.

Server SLY should always win, and it should always remain as the DMB machine,

Server IREBBS7 should only win when SLY is offline for some reason (basically never happens). However, it seems to think that SLY went away, and it just takes over. None of the other machines have this problem, but they are all lower on the ladder, so they should never even consider trying, but they do comment, in the log, about getting two responses when they look for the DMB.

[Doug Bissett]

logs etc.

[Herwig Bauernfeind]

Your WINS setup is borked.

​http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#WINSSERVER
​http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#WINSSUPPORT

wins support = yes

is only allowed on exactly ONE machine. You have it enabled on both. Decide which one should be the WINS server and disable wins support on the other one.

wins server = xxx.xxx.xxx.xxx

should only be necessary with more than one subnet, but it should not hurt to put the address of the machine with wins support = yes in smb.conf into the smb.conf of the machine with wins server = xxx.xxx.xxx.xxx.

[Doug Bissett]

Hmmm. Well, it seems that "wins support = yes" might be ONE of the problems. I set ALL of my machines to "wins support = No", and most of them cooperate. I don't need, or want, a wins server. Remember that I am using this as a PEER network replacement. There is no actual main server. There is one machine that is always on, and it should take the DMB role, unless it gets turned off, for some reason (never happens).

Other things that I have found:

The initial configuration, when I install a new SAMBA config, automatically adds "wins support = yes", every time. I don't ever remember changing that before.

You also need to define "os level = xx" or the server seems to assume that it should be the DMB, every time. This is NOT part of initial setup.

On a machine with a WiFi, and wired NIC, it seems that SAMBA gets the wrong IP address, and tries to use it. This also causes the server to insist that it is the DMB. I reported this a long time ago, but I can't seem to find the report any more, which is really odd, because I was looking at it a couple of days ago.

[Herwig Bauernfeind]

A few thoughts of mine:

There is no actual main server. There is one machine that is always on, and it should take the DMB role, unless it gets turned off, for some reason (never happens).

You should configure this machine as a WINS server. Believe me, you want that :-) It is by far the best method of name resolution in a simple SMB network. Works much faster and better than LMHosts and broadcasts (which are both, believe me, rather odd methods). Otherwise you need a full blown DNS in your network.

The machine with the highest os level wins the browser election.

For the machine with WiFi and wired NIC: Obviously this machine wins the browser election in one subnet and looses it in the other - that's why you see this changing the DMB.

[Doug Bissett]

Okay, I will configure a WINS server as being the machine that is always on.

There is something very strange about the way that SAMBA configures itself in the dual NIC machine. I need to spend some time to try to figure out what it is doing. My initial take is that it wins the election on the "dead" IP address (169.254.xxx.yyy), then simply assumes that it is a DMB on the active interface, until something else forces an election, and it loses. Meanwhile, other machines (especially the desired DMB) can't figure out if it is a DMB, or not. Eventually, it seems to sort itself out, but that can take 20 minutes, or more. This does not happen, if I disable use of the LLAeCS program to change the "dead" address to the 169.254.xxx.yyy IP address range. The address stays at 0.0.0.0 which causes other problems, but SAMBA doesn't attempt to win elections on that address. It should not attempt to win elections on the 169.254.xxx.yyy addresses either. In fact, it should completely ignore that address range.

I will upload SAMBA_T43.zip containing logs for the dual NIC machine.

[Doug Bissett]

Logs from IBM ThinkPad T43

[Herwig Bauernfeind]

Please, configure the interfaces properly to exclude the offending address range.
​http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#INTERFACES
This is definitely no Samba for eCS bug, but an inappropriate setup. (At best that would be a cross platform bug, but that's debatable - and I wont file that).

Please, send me the content of your environment - you seem to have a habit, that Samba does not like - it still tries to login as machine names (which are obviously non existent users) and that fails ...

Please, also send me the output of

pdbedit -L

[Doug Bissett]

I tried every combination that I could think of with INTERFACES. The result was always that the GUI client could "see" the share, but not the contents of the share. Any suggestions?

I am not sure what you want for the "environment".

When I install SAMBA, using the samba-1-1-2.wpi installer, I always create all new config, lmhosts, and whatever else it says. Then, I configure the password, and the domain name, and let everything else default. It creates the ROOT, and GUEST accounts. Then, I add ONE user, which I use everywhere. I always use ROOT when editing the user database, and I do not mess with anything else. I am a great believer that a default configuration should always work. Perhaps not ideally, but it should work.

PDBEDIT.TXT uploaded.

[Doug Bissett]

PDBEDIT -L output

[Herwig Bauernfeind]

For the environment:

1.) Open a command line session
2.) Enter

set >myenv

3.) Send me the content of "myenv".

My suspicion is that, as I said, you have a "habit" to setup your machines (pre-Samba-installation), that Samba does not like, but the installer does not detect that and therefore cannot deal with appropriately...

On the T43, add

  interfaces = lan0 192.168.0.102/24

to smb.conf. Samba wont touch the (wireless) lan1 now.

[Herwig Bauernfeind]

The result was always that the GUI client could "see" the share, but not the contents of the share. Any suggestions?

This has NOTHING to do with the interfaces line, but the fact that client tries to identify as a non-existent user... It would help if you provided loglevel 10 (or at least loglevel 5) logs, instead of loglevel 2 logs...

[Doug Bissett]

Replying to herwigb:

For the environment:

1.) Open a command line session
2.) Enter

set >myenv

3.) Send me the content of "myenv".

Uploaded in T43_SAMBA.zip as myenv.txt

My suspicion is that, as I said, you have a "habit" to setup your machines (pre-Samba-installation), that Samba does not like, but the installer does not detect that and therefore cannot deal with appropriately...

On the T43, add

  interfaces = lan0 192.168.0.102/24

to smb.conf. Samba wont touch the (wireless) lan1 now.

True, but the client can "see" ROMAMIN2, but it cannot use it. See the JPG in T43_SAMBA.zip.

I also question what happens when I switch to using the wireless? Do I have to change the interfaces line, every time I do that?

[Doug Bissett]

Replying to herwigb:

The result was always that the GUI client could "see" the share, but not the contents of the share. Any suggestions?

This has NOTHING to do with the interfaces line, but the fact that client tries to identify as a non-existent user...

[2013/04/21 11:41:18,  2] auth/auth.c:check_ntlm_password(318)
  check_ntlm_password:  Authentication for user [GiGi] -> [GiGi] FAILED with error NT_STATUS_NO_SUCH_USER

[2013/04/21 11:43:08,  2] auth/auth.c:check_ntlm_password(318)
  check_ntlm_password:  Authentication for user [ROAMIN2] -> [ROAMIN2] FAILED with error NT_STATUS_NO_SUCH_USER

It would help if you provided loglevel 10 (or at least loglevel 5) logs, instead of loglevel 2 logs...

See the logs in T43_SAMBA.zip.

This really doesn't make any sense. Of course there is no user called GiGi, or ROAMIN2. They are machines, not users. I have never seen any indication that the client is trying to use those names as users. I have only seen "GUEST" and "IREBBSUSER7", which , along with ROOT, are the only users defined. I will admit that the installer "suggests" adding the machine name as users, but why would I even consider doing that?

AH!, USER=ROAMIN2 is set in CONFIG.SYS, but no such user exists in the SAMBA user database. Why would anything try to use that?

I did try adding that as a user ID, with no password (what would I use for a password?), but nothing changed, except now I cannot access the share, even when i remove the interfaces line from samba.conf.

I can see that this is a typical *NIX program, with 800 parameters, 4 of which might be useful, and none of them make any sense when used with OS/2. I think that somebody who knows something about this, needs to sit down, and make some very detailed setup instructions. As it is now, SAMBA is pretty well unusable by 98% of potential users.

I think I will also go back to using LMHOSTS, since it seems to work better than WINS.

I would go back to NETBIOS over TCPIP, except it can't handle files larger than 2 GB.

I can see that I will need to spend a couple of hours, that I don't have, to trace both the DMB/WINS machine, and the dual NIC machine, to see if I can get something useful. The logs in T43_SAMBA.zip show one end, but not the other.

I will post more, if I can find the time. Meanwhile, if you have any more suggestions, I will give them a try.

Thanks...

[Doug Bissett]

logs etc.

[Herwig Bauernfeind]

AH!, USER=ROAMIN2 is set in CONFIG.SYS, but no such user exists in the SAMBA user database. Why would anything try to use that?

I told you that this was a problem... you chose not to listen.

%USER% and %HOSTNAME% are not the same thing... why on earth would anybody give them the same value, I added a warning to SSCC in that condition now. Don't do that, even on Windows you are adviced not to do that.

You were adviced by the Samba installer to create a Samba user for %USER% ... you chose to ignore that.

I told you broadcast is a bad choice (crappy protocol, ever was and always will be... you more or less insist on it (without providing a good reason, other than "I do not want WINS" - without knowing why).

The logs you provide never give me a complete picture of your situation and what actually happened - I cannot debug, I can only guess this way .

Having interfaces without proper IP addresses is a bad idea for any server software (wonder how Apache deals with such a situation...).

The Samba installer creates an environment almost perfectly suitable for you purpose out of the box (requiring you to enable wins support on one machine, disabling it on all others) - however you chose to do things your own way, but refusing to do some RTFM for that case (Samba docs are rather easy to understand and 99% also applies to OS/2).

I introduced 2 changes based on your reports (don't add local connect IPs to LMHosts and warn if USER and HOSTNAME have the same value) - there is not much point in continuing from here.

My last advice: It might help in your situation to run nmbd.exe only on the "main" machine, but not at all on the others. This matches my approach to add sharing capabilities to the Samba Client (and basically works) but is not well supported by the GUI Tools right now (WIP).

[Doug Bissett]

Okay. I have tried 4 more ways to make this work. It absolutely refuses to work "out of the box" or otherwise.

How am I going to run NMBD on only one machine, when I can never be sure that it will always be available?

All of the interfaces do have proper IP addresses. One of them happens to be a "dead" address, not connected to anything. That should work anyway.

Why would having USER and HOSTNAME the same be a problem? Again, that doesn't make any more sense than trying to use a USER ID and password, that isn't in the user database.

You are right, there isn't much point in continuing from here. I am sick of trying to work around *NIX incompatibilities. I am going to go back to NETBIOS over TCPIP, and I can use either RSync, or FTP, for files over 2 GB, and file transfer to windows. I would use NETBIOS, but I have one WiFi device that cannot handle that.

IMO, SAMBA is a wonderful idea, poorly designed, and completely unusable with OS/2. Perhaps it works with *NIX, I will probably never know. FWIW, CUPS is even worse.

Thanks anyway...