Hello All,
I have an eCS test PC that I have used for simple testing with SAMBA over the last several years. I am now ready to try the current releases of SERVER and CLIENT. I would like to have a completely clean slate before I start. What is my path forward for ensuring that I have a totally clean eCS PC before I try SAMBA again?
TIA,
Todd
If you uninstall the WPI packages, a utility is executed that prompts you, whether you want to do exactly that.
Quote from: herwigb on 2012.05.04, 16:02:43
If you uninstall the WPI packages, a utility is executed that prompts you, whether you want to do exactly that.
Todd,
If the WarpIn database is intact and up to date, you can do so by simply launching WarpIn itself, and looking for the particular package you wish to uninstall. From there, you can simply execute the uninstall option. If the WarpIn database is not up to date or is damaged, you can either (a) look for the particular install/uninstall component of the package or (b) re-install the exact same package, then uninstall it using the first method.
Best,
Rob
Thank you Robert and Herwig for your responses. I have been very shy about using SAMBA server. I had problems way back when with original configuration scripts. I have a different directory tree structure that I always had adhered to that may have been some of my difficulty. I also had problems with the daemons staying up and operational. I had to implement MS based servers and not eCS.
I know that SAMBA is well recognized today in the computing world. I had followed religously the SAMBA/Microsoft development forums and watched the Microsoft participation. I need an eCS alternative to small Microsoft based file sharing servers. Many of my small business clients have vertically integrated application suites that use file / record locking with ISAM & dBase database technologies and others. I am not talking about an occasional record lookup. I am talking about steady record lookup and record locking by up to 12 connected computers continuously.
I want to use our implementation of SAMBA. Can I get some real world implementation scenarios that work and work well? is there a recommended stress test toolset that we can certify a SAMBA installation with?
Thank you,
-Todd
I feel compelled to discuss SAMBA for eCS. The latest server implementations seem to work pretty good, but trying to use it with EVFS as the client is very flaky. I can use WinXP, or Win7, as the client (I can't get Win98 to work with it), for hours, and with larger file transfers, with little trouble. When I try to use it with EVFS, I am lucky if I can get to the point where I can transfer a file, before it hangs, or has some other weird problem. One of the main problems seems to be that transferring the directory information is extremely slow (5 to 10 KB/S, according to the IP Monitor widget), and it tends to just stop for minutes at a time (often, never starting again). The system also locks out everything else while it attempts to get a file directory, and if you do try to do something else, the system almost always locks up, requiring a reboot. Once the actual file transfer starts, it seems to go at a reasonable speed, but it almost stops between files. This is very frustrating when trying to transfer a lot of small files. It is often faster to copy the files to a USB stick, and copy them to the client that way.
I have got to the point where I am planning to quit using SAMBA, and replace it with RSync. It does make it a little more difficult to manage the data, but it works a LOT better.
The bottom line is, that the SAMBA server works fine. The eCS client (EVFS) doesn't work very well. I am not sure how that compares to the product from BSW, and I am not likely to spend any money to find out.
there must be something really broken on your EFVS installation. I use the sambaclient daily and it transfers some GB every week on my backup. i never saw what you describe. and i'm sure we don't have a ticket for that.
Quotethere must be something really broken on your EFVS installation.
I would say that there is something very broken, but I am seeing exactly the same thing on 4 eCS 2.1 installs, and 4 eCS 2.0 installs. It is worse with older versions of the EVFS stuff. The really odd thing is, that every once in a long while, I do get a good session, with few problems, but most of the time, I have trouble. I may never have opened a ticket, but I thought I did, a few years ago. I keep trying the updates, but nothing ever changes.
If you have any suggestions, I would like to hear about them.
Doug,
if reading the directory is slow, you likely have a version of the plugin that does not have caching built in (earlier than plugin version 2.x).
Please also note that the latest EVFS (coming with eCS 2.1) has important fixes not found in prior EVFS versions (like the one in eCS 2.0).
It looks like you seem to have a "habit" when setting up Samba Client that introduces the problems you see - we are very interested to find out what und why, because as you are easily able to reproduce this on several machines, quite likely others will also be able to to so. Either you are "falling into" a bug we are not aware of or our documentation is bad or whatever, either way it should be resolved.
As Silvan indicated, we do not see this problem, and like Silvan I am transfering gigbytes of data every data over Samba Client and Server.
Please open a ticket and help us work it out - you got both our attention (diver and me) - let's get this fixed.
Quoteif reading the directory is slow, you likely have a version of the plugin that does not have caching built in (earlier than plugin version 2.x).
This is what I am using now, on all systems. AFAIK, it is all pretty current, and the combination seems to work best.
Samba Client Versions:
File system EVFS Version 1.002
Plugin file M:\ecs\dll\ndpsmb.dll
Plugin Vendor Netlabs.org
Plugin Revision 2.01.1.1
Plugin Date/Time 24 Jan 2012 15:52:45
Plugin Build Machine HerwigB
Plugin Language Code en
Plugin File Version 2.1
Plugin Description NDPSMB - SMBFS NetDrive External Plugin Build GA
Commandline utilities Version 3.3.16-eCS 1.1.1-675
EVFSGUIVersion 2.1.3 [2011-09-13]
I have tried almost everything that has been released for the client.
I **think** that the main problem is that I share whole drives. Small drives seem to work a LOT better than large drives. I have played with just sharing individual directories, but that does not really do what I want to be able to do.
QuoteIt looks like you seem to have a "habit" when setting up Samba Client that introduces the problems you see
I have exactly the same problems immediately after a new eCS 2.1 install, without changing anything. I find that it works better if I change the "cache timeout" to 420 seconds, and the "listings to cache" to "80" (max - it looks like 2000 might be better). Under Global settings, I use "Refresh network neighbourhood immediately", and "Use broadcasts instead of local master browser". Changing those doesn't seem to make any difference.
QuotePlease open a ticket and help us work it out - you got both our attention (diver and me) - let's get this fixed.
I will see if I can find some time to put it all together, later today. I am not at home, so it is more difficult to find the time, and the resources to get it done.
These software components are ok. Just make sure there not a second ndpsmb.dll lurking somewhere. The algorithm to find the plugin is not water prove in EVFSGUI 2.1.x (it might show one plugin, while EVFS.IFS is using a different one (resolved in upcoming 2.5).
QuoteUnder Global settings, I use "Refresh network neighbourhood immediately", and "Use broadcasts instead of local master browser".
These only influece the network neighbourhood browser of EVFSGUI, nothing else.
QuoteI find that it works better if I change the "cache timeout" to 420 seconds, and the "listings to cache" to "80" (max - it looks like 2000 might be better)
That makes me think in a specific direction (without being sure yet), see link to ticket below.
QuoteI **think** that the main problem is that I share whole drives.
I do the same, without seeing your problem, if there is a correlation, it is likely not a direct one.
Please read http://svn.netlabs.org/samba/ticket/178 (http://svn.netlabs.org/samba/ticket/178) - might name resolution be an issue in your network? If so, we should be able to see this in the logfiles and trying a current testbuild of EVFSGUI 2.5 with a proper setup should show a dramatic improvement...
However, this is just a guess, as you are using the same components as I am using, so I tend to think the problem is quite likely no direct Samba problem, but a side effect of some sort, name resolution only being one possible cause...
QuoteJust make sure there not a second ndpsmb.dll lurking somewhere.
The only other one is in the other boot system, that hasn't been updated yet. It should not be accessible in any way.
QuotePlease read http://svn.netlabs.org/samba/ticket/178 - might name resolution be an issue in your network?
Now that is interesting. I added a line
name resolve order = bcast host lmhosts wins
to the smb.conf files, and the whole thing seems to be much better. I will need to do more testing with that. My setup should be using broadcast, and the order may explain why I have few problems when using windows, which probably adds lmhosts support. I put "host" second but none of my HOSTS files is set to do anything (other than localhost) because of the logistics of keeping them up to date.
Okay, so i tried windows XP as a client. It seems to be hung, then it had an error. The eCS SAMBA server had 5 SMBD instances running. After restarting the server, WinXP now "sees" it, but the logon doesn't work (that might have something to do with changes I made to allow Win98 to log on). Using the eCS client to log onto winXP works better than it did before too.
I will do more testing, when I have the opportunity. Thanks...
Just a maybe stupid question. Which smb.conf file did you put that line in? I find my only smb.conf file in mptn\etc\samba and that file seems entirely related to Samba server. Do they use the same file? Should there be some part in that file dedicated to samba client or how does it work?
QuoteWhich smb.conf file did you put that line in?
\mptn\etc\samba\smb.conf
Apparently both the server, and the client, use the same file (possibly not a good thing). I did make a typo the first time I added the line, and the client complained about it, so it does use it.
FWIW, the performance is many times better than before. I still get some 5 to 10 second pauses when trying to populate the drive tree of a large drive, for the first time but, so far, no hangs.
Quotehow does it work?
If I knew that, I probably would have fixed the problem long ago. Perhaps herwigb can enlighten us.
Both the server and client use the same smb.conf - until I found out about the name resolution issues, this was no problem at all. In the future this might change, however that has not been decided yet. Server and client use different directories for their .tdb files - that turned out to be a problem.
Doug, may I ask, why are you using broadcasts?
This is really a slow method (and not well tested by me, because technically it is a bad method and stone age old). Using WINS is much more effective and the Samba Server for eCS works very well in this respect. A short explanation: WINS = Specific DNS for SMB networks.
The upcoming EVFSGUI 2.5 will support setting up WINS also for our Samba Client http://msplins06.bon.at/~admin139/files/evfsgui_wins.jpg (http://msplins06.bon.at/~admin139/files/evfsgui_wins.jpg)
In addition I added a reasonably good method to provide a dynamic LMHOSTS file for the client, that even outperforms a properly setup WINS server in the most relevant cases (but is slower in less relevant situations).
I will set up a complete test package later today.
QuoteDoug, may I ask, why are you using broadcasts?
Some years ago, when I first tried SAMBA, I was having trouble, and somebody suggested using that, and it worked. I never tried changing it again.
QuoteA short explanation: WINS = Specific DNS for SMB networks.
I have never heard any mention of WINS, other than in a windows context. Since i rarely have a windows machine attached, and there was nothing to suggest that SAMBA supported it, I never even thought about it.
Okay, How does SAMBA handle being a WINS server? If I have machine A on, and running SAMBA server, then turn on machine B, I assume that machine A is still the WINS server machine. Now, what happens when I turn off machine A, turn on machine C, and attach to machine B?
The same question for LMHOSTS, and I suppose I also need to ask about HOST in the name resolve order line.
I think that some, or all, of this should be in the Wiki.
Well, I have tried some other combinations, and the only one that works anywhere near acceptably, with eCS, is to use broadcasts, and have "bcast" as the first option in the name resolve order. Putting "wins" second helps windows to work better. Having "wins" first really messes up eCS, for some reason.
Looking forward to your updates.
First of all, in order to have WINS working, you need exactly one WINS-Server in a subnet. Samba acts as a WINS server if you add to the smb.conf of the server:
Quote
wins support = Yes
On eCS Samba Clients you have to add to smb.conf:
Quote
wins server = xxx.xxx.xxx.xxx
name resolve order = wins lmhosts host bcast
xxx.xxx.xxx.xxx = IP of WINS server
EVFSGUI 2.5 http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120414.zip (http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120414.zip) has new config options to to all that from the GUI.
Please note, that EVFSGUI 2.5 is still incomplete - the browsing code has been enhanced and works better than ever, however there are at least 2 known bugs in it. The new layout and functions are by and large missing in the helpfile, printer support is incomplete, the option to store credentials in RAM across sessions works nicely.
On Windows you will have to add the IP of the WINS server to the appropriate fields in TCP/IP notebook.
Additional note: EVFSGUI 2.5 has an option to create and manage a LMHOSTS file like a cache (this file works much like the %ETC%\HOSTS file, but for SMB networks). This will usually give you the best performance in name resolution, especially if your WINS server is slow (for instance if it is located behind a WLAN bridge or similar).
So the recommended name resolve order with a running WINS server and EVFGUI 2.5 would be:
Quote
name resolve order = lmhosts wins host bcast
For you Doug, as long you don't have a WINS server, I'd recommend:
Quote
name resolve order = lmhosts bcast host wins
EVFSGUI 2.5 creates and manages the LMHOSTS file from the network neighbourhood
In case a DHCP server is used in a network, the WINS server is normally advertised by that (Windows clients make use of that), however most eCS DHCP clients are older than Samba and as there is no standardized place to set a WINS server in OS/2 TCP/IP (until our current Samba Client there was no software to make use of it). In short: Currently the WINS server IP address has to be specified manually or via EVFSGUI 2.5. There is no way to obtain it on eCS from a DHCP server.
Quote from: herwigb on 2012.05.20, 11:45:36
In case a DHCP server is used in a network, the WINS server is normally advertised by that (Windows clients make use of that), however most eCS DHCP clients are older than Samba and as there is no standardized place to set a WINS server in OS/2 TCP/IP (until our current Samba Client there was no software to make use of it). In short: Currently the WINS server IP address has to be specified manually or via EVFSGUI 2.5. There is no way to obtain it on eCS from a DHCP server.
Actually, there is.
Basically, you need to add these lines to \mptn\etc\dhcpcd.cfg:
option 44 exec "setnbns.cmd 44 %s"option 45 exec "setnbns.cmd 45 %s"option 46 exec "setnbns.cmd 46 %s"And then provide a REXX script called SETNBNS.CMD which updates the Samba configuration as needed. The sample script IBM provides is for updating the IBMLAN configuration file -- this is nasty and requires a reboot every time the address changes. I've pasted it here anyway to show how it works. For Samba it should be much simpler, since Samba doesn't need to read its configuration file during CONFIG.SYS processing.
/****************************************************************************
* SETNBNS.CMD
* by Peter Degotardi
* Revised April 21, 1998
* SETNBNS
* Return values: 0=successful, 1=unsuccessfull
* Accept DHCP options 44, 45 and 46 and put them in a queue where
* GETNBNS.CMD can read them.
****************************************************************************/
return_code = 1
/* Assume everything will fail */
/*** add RexxUtil functions ***/
call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
call SysLoadFuncs
/* get option number and data from the command line */
parse arg option_tag option_data
if ((option_tag = '') | (option_data = '')) then
do
return_code = 1
/* wrong number of arguments */
exit return_code
end
/*** strip leading and trailing spaces ***/
option_tag = strip(option_tag)
option_data = strip(option_data)
Select
when (option_tag = 44) then /* NBNS address */
do
if (check_IPaddr(option_data)) then
return_code = queue_it(option_tag||','||option_data)
end
when (option_tag = 45) then
do
if (check_IPaddr(option_data)) then /* NBDD address */
return_code = queue_it(option_tag||','||option_data)
end
when (option_tag = 46) then
do
call lineout '\setnbns.log', 'option_data="'option_data'"'
select
when option_data = 8 then data = 'H-Node'
when option_data = 4 then data = 'M-Node'
when option_data = 2 then data = 'P-Node'
otherwise data = 'B-Node'
end
return_code = queue_it(option_tag||','||data)
end
otherwise nop /* unsupported_option */
end
exit return_code
/****************************************************************************
* check_IPaddr
* Check a dotted decimal IP address for valid format.
*
* Return 0 if there are not 4 octets or the data is out of range or
* there are embedded blanks in the address, else return 1.
****************************************************************************/
check_IPaddr: Procedure
parse arg addr
addr = strip(addr)
parse var addr octet.1 '.' octet.2 '.' octet.3 '.' octet.4
do pos = 1 to 4
if (verify(octet.pos, '0123456789', N) \= 0) then
return 0
/* not an unsigned number */
if ((octet.pos < 0) | (octet.pos > 255)) then
return 0
end
return 1
/****************************************************************************
* hex2ascii_string (option_data)
*
* Take a hex string in the form 'hex"nn nn nn ... ", verify it's a valid
* hex string, and convert it to an ASCII character string.
*
* Returns the string if the data is valid, a null string if not.
****************************************************************************/
hex2ascii_string: Procedure
parse arg 'hex' '"' data '"'
if (\ DATATYPE(data, X)) then return ""
data = strip(data, 'B', '09'x)
return X2C(data)
/****************************************************************************
* queue_it
* Put the data in a queue where it can be read by GETNBNS.
* Tries to create the queue. If a different name is returned, the queue
* must already exist, so delete the 'wrong' queue, set the queue to the
* 'correct' one, and put the data there.
****************************************************************************/
queue_it: Procedure
parse arg data
qname = 'NBNSINFO'
/* The queue we're using */
new_queue = rxqueue("create", qname)
if new_queue \= qname then
rc = rxqueue("delete", new_queue)
rc = rxqueue("set", qname)
queue data
return 0
WINS server would not seem to be suitable for my mode of operation, simply because I never know which machines might be turned on at any given time.
QuoteEVFSGUI 2.5 creates and manages the LMHOSTS file from the network neighbourhood
So it does, but trying to use EVFSGUI 2.5 seems to introduce a few problems. Never ending hangs, while trying to populate a drive directory, is one of them. Another is that there is an error popup when I attempt to mount a new share:
QuoteLine 40 of CB_MOUNT_Change in evfsgui.VRM:
There is a button (END?) that closes the program.
File-> Load seems to work, as long as the mount was saved earlier.
I don't have the time to try to sort it out now, so I have gone back to EVFSGUI 2.13, which works good, after adding the "magic line" to smb.conf.
ALT seems to have an interesting approach, that I will have to try out when I find more time, but it would seem to require a WINS server. I think that my own router might have WINS support, but I don't think my brother's router has it.
So many possibilities, and so little time.
Doug,
QuoteWINS server would not seem to be suitable for my mode of operation, simply because I never know which machines might be turned on at any given time.
That's the purpose of a WINS server: Using broadcasts is like somebody entering a populated room shouting "I'm here" - everybody
might hear that (or not), therefore it might take some time until everybody noticed someone new is here. Same for leaving. With a WINS server, somebody who enters registers at the WINS server and anybody who wants to know who is around, asks the WINS server and obtains a list.
QuoteLine 40 of CB_MOUNT_Change in evfsgui.VRM:
Please send me the evfsgui.err file found in the directory of evfsgui.exe
Alex,
good to know. I did some investigations on that and ended up in dhcpcd.cfg, but got distracted. So many things to implement, so little time.
QuotePlease send me the evfsgui.err file found in the directory of evfsgui.exe
I added it to the netlabs TRAC for SAMBA, in incident #194.
QuoteThat's the purpose of a WINS server: Using broadcasts is like somebody entering a populated room shouting "I'm here" -
If I put "wins" first in the list, I get hangs, and very slow network neighbourhood population. Using "bcast" first gives me pretty good response, but not what should be possible.
At the moment, I don't have the time, or the resources, to do any comprehensive testing.
Doug,
also send us the smb.conf of your server and the .evp file that you are using to connect.
After investigating these, I will ask you for some logs from client and server. Details what to do will follow.
Quotealso send us the smb.conf of your server and the .evp file that you are using to connect.
I updated incident 194 in TRAC. The Mount problem occurs on every attempt to mount a share, no matter what OS, or server, I use. The updated files at TRAC are an attempt to Mount a share on a Win98 machine. There is no .evp file, and there is no smb.conf involved. Just select a share to mount, and click the Mount button, and the popup shows the error. If I do load a *.evp file, it will mount the drive, but that does me no good when i don't have a saved *.evp file to use.
Try this one (updated evfsgui.exe only), it has the crash with saving fixed, nothing else changed (I think)
http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120529-update.zip (http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120529-update.zip)
Quoteit has the crash with saving fixed
I got the update. I never get far enough to try saving anything. The crash occurs when I try to mount a share. I can't save the information until I get the share mounted.
Doug,
did you try the update? When mounting, the save routine is used internally, the call to this routine was broken and I fixed that.
You tell me it still crashes? In that case I need the new evfsgui.err file
Quotedid you try the update?
The evfsgui.EXE file is dated May 28 2012.
QuoteYou tell me it still crashes? In that case I need the new evfsgui.err file
Yes, it still crashes. The evfsgui.err file looks the same to me (without verifying that). I will update the incident.
Sorry, I overlooked the second .err file, only the first one was fixed in the 20120529 .exe.
The second (and third) one is strange and should not happen at all - try this one http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120603-update.zip
The error is not fixed, however it should not crash, but display an error message box, which should give us a hint, what's exactly happening. It might crash after the message box....
Anyway, I need to know what the message box says, and, in case it crashes afterwards, the new .err file.
QuoteThe error is not fixed, however it should not crash, but display an error message box, which should give us a hint, what's exactly happening
I think I may need to be very specific about how to make it fail. Yes, the crash is fixed. Now, I get a popup saying that whatever type of share I am trying to mount, is an "unknown mount type". I reply to that popup, and it proceeds to, happily, mount what I requested. There is no evfsgui.err file now. If I try the mount from the New resource tab, I don't get the popup.
To make it fail:
Open EVFSGUI.
Select the Network neighbourhood tab.
Wait for that to populate (often it takes more than one Refresh to get it to populate).
Select a share.
Click Mount. You will get the error message.
Other things that I have found, is that NMDB.EXE doesn't always stay running when it starts after a boot. I will need to capture a log file (they need to be rolled over, rather than just replaced), which shows that it is not happy with address 0.0.0.0. It seem that NMBD.EXE is starting before the DHCP stuff gets set up. I find that rather surprising since I start the samba server in the STARTUP folder, using REXX Autostart, and the SAMBA startup is close to last in the series (of about 20 items), so it takes more than 10 seconds to get to it.
I have also been playing with the sequence of the name resolve order. I changed my router (my own router, not my brother's which we started this thread with) to use "point to point, then bcast", rather than just bcast. I also turned off the Global settings "Use broadcasts instead of local master browser". Now, it seems that setting the order to "lmosts wins bcast host" is working more reliably, but I haven't tried adding more clients to the mix, and I haven't tried turning off the one that seems to think that it is the master. I also need to reset the default cache timeout, and the listings to cache, to the defaults. BIG numbers (600 and 80) seem to work much better.
This whole thing is way too complicated for the average user, and it seems that other things (like router settings) can affect the results. I still have many hours of testing, to see what does, and doesn't, work.
I have been doing more testing. I updated TRAC with the information, but it seems that SAMBA only works properly, when the machine that gets designated as the DMB (Domain Master Browser???) never gets turned off. It also seems that the machine that gets designated as DMB is a random thing, and a second machine can also get that designation, somehow.
It seems to me, that the user should not need to even think about such things, never mind have to go through the settings to see if they can find a combination that might work, only to find that it quits working just because they powered off the machine that happened to become the DMB. I never even heard about such problems with the old PEER networking. Of course, PEER has major problems with later versions of windows, and with files larger than 2 GB, so SAMBA is our only option. Also, I have not seen similar problems when using Windows as a client to the SAMBA server (I may not have run into the proper combination of circumstances, since I don't use windows much).
QuoteYes, the crash is fixed. Now, I get a popup saying that whatever type of share I am trying to mount, is an "unknown mount type". I reply to that popup, and it proceeds to, happily, mount what I requested. There is no evfsgui.err file now. If I try the mount from the New resource tab, I don't get the popup.
Ok, I see what happens, not sure why, but I will fix that, can't be too hard.
QuoteIt seem that NMBD.EXE is starting before the DHCP stuff gets set up
Ok, I never tried that, however I this likely to fail. Eventually code could be added to smb.cmd to wait until DHCP has completed - however, don't expect to see that soon.
QuoteDMB
All you describe here is normal Samba behaviour. The DMB should always be present, in case it vanishes, it might take several minutes for another machine to take over, meanwhile requests will go to limbo - expect loooooong delays in such a situation. There are ways to make sure only a certein machine becomes DMB, this is a matter of RTFM ;-) (look for "os level" setting).
However while I thought over that all, it came to my mind that there's chance to see 2 DMB in the network neighbourhood with current EVFSGUI 2.5 - which is wrong, there is always only one DMB for one domain at a given time - if that changes while EVFSGUI still builds the network neighbourhood, and EVFSGUI already processed the earlier one and later on the new one 2 DMBs will be displayed - I need to think over how to fix that (which wont be trivial).
Just as a side note: Network neighbourhood (called ressource browser) in IBM Peer always was flaky and could easily block the WPS forever....
QuoteOk, I see what happens, not sure why, but I will fix that, can't be too hard.
Hehe. Famous last words... :) At least it doesn't crash any more.
QuoteOk, I never tried that, however I this likely to fail.
It depends on how long it takes to get the DHCP information. I see this regularly on my T43 laptop which tries the wired interface first. If that works, it usually doesn't have a problem. However, if it needs to wait for XWLAN to do it's thing, and connect the wireless, it is usually too late. This problem also happens on my machine that only has a wired interface, so it isn't unique to a multi interface machine. There is also a problem convincing EVFSGUI that the interface has changed, when I disconnect the wired, and switch to the wireless. I suspect that this is further complicated if the wired interface was the DMB.
Quotein case it vanishes, it might take several minutes for another machine to take over
It seems to be more like several hours. Even rebooting didn't seem to convince another machine to take over.
Quotemeanwhile requests will go to limbo - expect loooooong delays in such a situation
I think this might be the basic problem that I started with.
QuoteThere are ways to make sure only a certein machine becomes DMB
Since I never know, from one minute to the next, which machine(s) will be on, I don't see how that will help. I do have one machine that is on most of the time, so I will see if I can convince it to be the DMB. I expect that that will help, until I need to shut it down, for one reason or another. I have also been considering making an OS/2 (eCS) based NAS box, with extras. It should be on all of the time, so that may be an answer, but I consider that to be a "work around", not a fix.
QuoteJust as a side note: Network neighbourhood (called ressource browser) in IBM Peer always was flaky and could easily block the WPS forever....
Personally, I have never seen such problems with IBM PEER (but it has been a few years since I tried using it). I also haven't seen a problem where the EVFSGUI Network neighbourhood caused a problem (other than it often refuses to populate, possibly caused by the DMB problem). The hangs that I see are when I try to display the pseudo drive that EVFSGUI creates. I find that the desktop becomes unresponsive, and if I do forget, and do try to do anything else while it is populating the tree (sometimes takes several minutes), the desktop usually stays locked until I force a reboot. It gets better, after the first time it gets populated, but I still have trouble with it sometimes. The really odd thing is that my slow machines have less trouble than my fast machines. I also use RAMFS, which seems to be the basis of the EVFSGUI pseudo drive, and I don't see those problems with it. Of course the RAMFS drive has very little data on it, so it populates quickly, and may hide some of those problems.
FWIW, my brother's setup is only two machines, with a 100 Mbs connection. One is a triple core AMD Phenom on an Asus M3A78-EM motherboard (Realtek 8168 NIC, using the r8169 Multimac driver). The other is an old 450 mhz IBM box, with a Realtek 8139 NIC. His router is a Linksys WRT54G. I got that setup working pretty good.
My own setup is somewhat more complicated, with a Quad core AMD Phenom processor on an Asus M3A78-EM motherboard (using a Realtek 8169 PCI NIC that replaced a defective 8168 on the mb, and using the r8169 Multimac driver). I also have a Lenovo ThinkPad T510, an IBM ThinkPad T43, an antique IBM ThinkPad A22e, and an old Gigabyte 7IXE motherboard, with AMD Athlon processor, using a Realtek 8139 NIC (this one may get retired soon). The machine that I intend to turn into a NAS, is an Asus A8N-SLI motherboard, with AMD Athlon, and NVIDIA NIC. My router is a D-Link DIR-655, which has 1 Gbs wired interfaces. I notice that transferring data over the gigabit interface is rarely any faster than transferring data over a 100 Mbs interface, when using SAMBA (it is very much data dependent). RSYNC, and FTP, work a LOT faster with a 1 Gbs interface.
Quotelook for "os level" setting
I can find no such thing. Care to give me a hint as to where to find the reference?
http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html
Quote from: DaveS on 2012.06.04, 22:16:11
http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html
Thanks. That reads like the fine print in a crooked contract, but it got me to the FAQ (which has a link in the SAMBA server folder). Again. it reads a lot like the fine print in a crooked contract, but suggested using "os level = 40" on the server that I want to be the DMB machine. I tried that, and now it seems that all of the machines think they are DMB (DUMB??). In the following section, it is suggested to also use "domain master = yes". Well, that changed the machine that I want to be DMB to LMB. The other two (that I happen to have turned on), both claim to be DMB. Trying to use the pseudo drive hung the client. It looks like a forced reboot is required. 20 minutes later, it has only a small part of the directory tree displayed, and the only thing that seems to work is Ctrl-Alt-Del, which brings up CADH. All I can do with that is do another Ctrl-Alt-Del, to get it to reboot. At the moment, nothing is updating on the desktop (the clock is frozen, along with everything else).
I also tried to get back to using bcast, but that no longer seems to be working, probably because I have things so messed up that it is confused (I know that I am). I think I will uninstall the whole thing, and start over.
I feel sorry for any non technical person who attempts to get SAMBA to work with eCS. My guess would be that less than 10% of them will be successful, and that would be only because they are lucky enough that the default settings actually work. Even a reasonably technical person (like myself) hasn't got a hope of making it work in most cases. I must admit, that I am not inclined to spend many hours trying to decode the, so called, documentation. It is another example of the *NIX way of having too many options, with most of them having no use, and/or little meaning to the average user.
I am open to suggestions about how to get this mess working. It will be a few days before I get the time to reinstall everything, and then I expect that I will need to start over to find a combination that will actually work reliably. No, I won't leave a windows machine running, just to serve as a WINS server.
Quote from: DougB on 2012.06.05, 00:53:49
Quote from: DaveS on 2012.06.04, 22:16:11
http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html
Thanks. That reads like the fine print in a crooked contract, but it got me to the FAQ (which has a link in the SAMBA server folder). Again. it reads a lot like the fine print in a crooked contract, but suggested using "os level = 40" on the server that I want to be the DMB machine. I tried that, and now it seems that all of the machines think they are DMB (DUMB??).
LoL... Domain Master Browser and Local Master Browser. The DMB should be properly storing the collection of all names from all LMBs for lookup and reference, including WINS stuff (which are pretty much simply NetBEUI to TCP/IP resolves which aren't supported by DNS of course). It *should* also be keeping all the LMBs updated with the information it has gathered from all of them.
Quote
In the following section, it is suggested to also use "domain master = yes". Well, that changed the machine that I want to be DMB to LMB.
And thus, that seems very weird. :-\
QuoteDomain Master Browser and Local Master Browser. The DMB should be properly storing the collection of all names from all LMBs for lookup and reference, including WINS stuff (which are pretty much simply NetBEUI to TCP/IP resolves which aren't supported by DNS of course). It *should* also be keeping all the LMBs updated with the information it has gathered from all of them.
I have a basic idea of what it SHOULD be doing. What it IS doing seems to be something else. After a couple of reboots, the machine that I want to be the DMB suddenly decided that it is both DMB and LMB. Still doesn't work very well though, and the other machines still seem to want to be DMB machines.
QuoteAnd thus, that seems very weird.
The whole thing is pretty weird. About the only thing that I haven't tried is to add a WINS configured windows setup. Even if that works, it isn't going to do me much good, because I hardly ever run windows. I suppose that I could run windows in a Virtual PC, but that is flaky enough that I wouldn't feel comfortable using it. I have VBox, but haven't got around to installing windows (or anything else) in it. Of course, I still have the same problem, if I decide to use the physical machine for something else. There is also the load factor, which would probably be unacceptable.
I have an uneasy feeling, that my router is messing around too, but there is nothing obvious in the settings, other than what I mentioned earlier.
I don't want to mess things up, but stress that you are not alone to have problems. I have in particular problems with the "network neighbourhood" function. For about a year ago it worked fine, every computer, every workgroup was found (then we had (in the family) a mix of w2k, vista and eCS computers). Now, no computer, no workgroup is found (now the mix is win2k, w7 and eCS). I can connect using the "new resource" page, i.e. by specifying server, workgroup etc. I don't know if the problem is related to the updates of samba client or to the use of w7 instead of vista. The "network neighbourhood" function is important, especially when you're not at home. Also I have used broadcast as computers are not always on. I now have tried different settings, following this thread. I note that I now have a lmhosts file in my mptn\etc\samba directory. It lists in fact active computers and their ip numbers, but doesn't seem to make use of that knowledge as the "neighbourhood" is not populated. Ok, I don't need any answers on this, better stick to one case, just adding and pointing to some problems I see.
Doug,
try this one http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120605-debug.zip
The only way I found to trigger your error was to remove the language file, in that case the mount type was not properly initialized, which lead to the behaviour you see.
This EVFSGUI now complains if it does not find a language file and the mount type is initialized with the built in string list from the guy (square brackets around the text in this case).
This is a debug version, please enable debug also in the global settings and paste the complete content of the VX console window to a file and attach that to the ticket.
Mikael,
QuoteI note that I now have a lmhosts file in my mptn\etc\samba directory. It lists in fact active computers and their ip numbers, but doesn't seem to make use of that knowledge as the "neighbourhood" is not populated.
The network neighbourhood creates and populates the lmhosts file, which is used by the plugin. The network neighbourhood is not populated by the lmhosts file.
The network neighbourhood is basically a GUI wrapper for the smbtree.exe command. if smbtree.exe does not produce reasonable output, the network neighbourhood will stay empty, too.
Thanks for clarification. Running smbtree.exe shows nothing either in fact. But, when using the -N option ("to find out whether [some] table files are actually found or not".) my other computer is actually found.
Mikael,
The -N switch is used in many Samba commandline utilities (most notably smbtree.exe and smbclient.exe) to make the command run with guest privilegues only.
smbtree.exe, smbclient.exe and nmblookup.exe are used to gather all the information required in the network neighbourhood.
In case there is a user/pw on the "new connection"-dialog page entered, the commands are run using these, otherwise the commands are run using the -N switch. If you want to make sure the commands are run using -N switch remove user/pw from the "new connection"-dialog page. I know, it's a bit odd this way....
Quotetry this one http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120605-debug.zip
It still fails, but the message is a little different (and no crash). I updated the incident with what I have had time to do, so far. I also opened an incident for the problem where NMDB.EXE fails to run after a boot. This does not seem to be time related, and I know that the DHCP stuff has been finished long before the problem arises.
Quoteif smbtree.exe does not produce reasonable output, the network neighbourhood will stay empty, too.
It seems that smbtree.exe might need some work. Sometimes, it works okay, but if anything changes (like turning off one of the machines), it seems to go off into it's own little world for a while. Today, while testing, I had three machines running the SAMBA server (IREBBS7, ROAMIN2, and ROAMIN3). When I opened EVFSGUI on ROAMIN2, I saw IREBBS7 and ROAMIN2. When I opened EVFSGUI on ROAMIN3, I saw IREBBS7 and ROAMIN3. No amount of refreshing, or restarting EVFSGUI, changes that. The really odd thing is, that if I restart the server on IREBBS7, all of the machines can see all of the machines. There was nothing, obviously, wrong with the server on IREBBS7.
Far too often, I see that there are more than two SMDB.EXE instances running, for no apparent reason (nothing attached), and when that happens, I generally have difficulty trying to attach one of the other machines. Restarting the server seems to fix that, until it happens again.
I need to mention again, that I see none of these type of problems (including problems when there are more than two SMDB.EXE instances running) when I use windows (XP or 7) as the client, so I am inclined to believe that it is EVFSGUI (possibly just some of the support programs) that is causing the problems.
Doug,
try this one http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120606-debug.zip
I fixed 2 bugs, one in the RPC library (saw that in your log, line 438 etc.) and the second is the sharetype error - this one should be really gone now.
QuoteIt seems that smbtree.exe might need some work. Sometimes, it works okay, but if anything changes (like turning off one of the machines), it seems to go off into it's own little world for a while.
I am not convinced of that (several reasons requiring very lengthy explanations) - I would only do that if a Linux smbtree would perform differently than an eCS smbtree.exe in a given situation. The way the SMB browsing stuff works makes it easy to see breaks like this, especially in case with no permanently present WINS server.
BTW I'd setup os level on your server to 70 or the like. With 40 Samba will loose browser elections against any WinXP machine AFAIR...
Quote from: herwigb on 2012.06.05, 20:42:11
//--
In case there is a user/pw on the "new connection"-dialog page entered, the commands are run using these, otherwise the commands are run using the -N switch. If you want to make sure the commands are run using -N switch remove user/pw from the "new connection"-dialog page. I know, it's a bit odd this way....
I can see that (checking the debug square) parameters -S -N i used by the GUI, but nothing in the neighborhood view. However, if I use the commandline, smbtree -N the computer in my network is found.
Mikael,
what you see on the commandline is part of the debug log.
smbtree -S -N -d=0
I guess this will be empty, too.
You should see something like the attached image...
Could you eventually send me the complete output of the VX console window? I might have spotted something, but need to take a closer look.
AN UPDATE: It seems like my problem is totally unrelated to Samba and rather dependent on the network settings in the other machine (a w2k machine). Thanks Herwig for the help with this.
Quotetry this one http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120606-debug.zip
I fixed 2 bugs, one in the RPC library (saw that in your log, line 438 etc.) and the second is the sharetype error - this one should be really gone now.
I am not sure what the RPC library is. The sharetype error is gone now.
I now have another bug for you: I tried using the "Store credentials until next boot" setting. That caused trouble when I switched from windows to eCS on another machine, so I turned it off, closed the program, and opened it again. That setting was back on. I can find no way to turn it off, and keep it off (it shows as off, until I close, then open, the program). I suppose that I need to give windows a different share name, but that gets more complicated, and EVFSGUI really should be able to handle having the same name for windows and eCS.
And still another bug: I have two interfaces on my T43 (ROAMIN2). One wired, and the other wireless. When the wired interface is connected, it gets IP address 192.168.0.102. XWLAN then assigns 169.254.<random number>.<random number> to the second (wireless) interface. If I reset the LMHOSTs file, then try a refresh, the LMHOSTS file lists ROAMIN2 as being 169.254.<random number>.<random number>. Of course, that is a dead link, so it doesn't work.
This is getting worse. I need to uninstall, and reinstall the whole thing, to see if I can get back to a known condition.
Doug,
The daily update ;) http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120607-debug.zip (http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120607-debug.zip)
QuoteI tried using the "Store credentials until next boot" setting
Fixed.
QuoteEVFSGUI really should be able to handle having the same name for windows and eCS.
That works, just tried. Wild guess: Credentials are not really the same (username+passwort+privilegues).
QuoteI have two interfaces
This is a known problem (and a design flaw in EVFSGUI). I built in a workaround (as this will be tricky to really fix properly): A machine that appears to have a local link (169.254..) IP (this is always wrong) is never added to LMHosts... Not really smart, but better than before.
In addition a "Clear" button was added on the dialog page to remove credentials from memory. The network neighbourhood now displays the user context that is used during browsing - that should help finding out why a specific machine cannot be browsed (or is not shown).
QuoteQuote
I tried using the "Store credentials until next boot" setting
Fixed.
Well, not quite. I now get an error popup when I turn it off, and click Apply. I will update the incident.
QuoteThat works, just tried. Wild guess: Credentials are not really the same (username+passwort+privilegues).
I suspected something like that, which is why I tried to turn off the "Store credentials until next boot" setting.
QuoteThis is a known problem (and a design flaw in EVFSGUI). I built in a workaround (as this will be tricky to really fix properly):
I will have to try that later.
QuoteThis is a known problem (and a design flaw in EVFSGUI). I built in a workaround (as this will be tricky to really fix properly): A machine that appears to have a local link (169.254..) IP (this is always wrong) is never added to LMHosts... Not really smart, but better than before.
I see no change. It still tries to use the 168.254... address. It appears that it does that because it gets a positive response from the local server on that address. IMO, this is a fault in XWLAN. Rather than assigning a dead address, it should turn off the access by using the
IFCONFIG LANx delete
command on the interface that should be disabled. If I do that, manually, and restart the server, it works properly. I have not considered the consequences of having two, or more NICS that might be on separate networks.
I also discovered that there is an EVFSGUI.INI file, which is hidden in x:\OS2. I never thought to look there. Why is that not in x:\eCS with the rest of it? After editing that with an INI editor, to turn off the "Store credentials until next reboot" setting, it seems to be working better. Win7 seems happy too.
QuoteWell, not quite. I now get an error popup when I turn it off, and click Apply. I will update the incident.
So sorry. Little last minute change that was not supposed to break anything...... :-[
It is fixed in [url]http://msplins06.bon.at/~admin139/files/evfsgui-25beta-20120607b-debug.zip[url] (no other changes since yesterday).
QuoteI see no change. It still tries to use the 168.254... address.
This is no surprise. Samba will try to use any interface with an associated IP. It is not the the job of Samba to test whether an interface works or not.
My workaround just ensures that in case there is also another valid IP address the local link address is not enforced by putting it into LMHosts...
One should reset LMHosts however to make sure any old invalid entry is gone...
QuoteI also discovered that there is an EVFSGUI.INI file, which is hidden in x:\OS2.
Well, it was already that way, when I took over development. For compatibility reasons I did not change this, although I am doing it differently in the other Samba GUI tools...
QuoteAfter editing that with an INI editor, to turn off the "Store credentials until next reboot" setting, it seems to be working better. Win7 seems happy too.
This is highly improbable, because having stored the user/password in memory has only the advantage of not having to retype it every time. Everything else is just exactly the same. You need to be more specific, if I should take a closer look, although I don't have the faintest idea...
QuoteSo sorry. Little last minute change that was not supposed to break anything......
Murphey's law.
It is fixed now.
QuoteMy workaround just ensures that in case there is also another valid IP address the local link address is not enforced by putting it into LMHosts...
One should reset LMHosts however to make sure any old invalid entry is gone...
Hmmm. I deselected to use LMHOSTS, and it is still trying to use the bad address. I think the proper fix will be to get XWLAN to disable the whole interface, rather than trying to emulate windows and give the unused interface a phony address.
QuoteWell, it was already that way, when I took over development.
I think it may be wise to change it, if it is a trivial change, just to avoid confusion.
QuoteQuote
After editing that with an INI editor, to turn off the "Store credentials until next reboot" setting, it seems to be working better. Win7 seems happy too.
This is highly improbable, because having stored the user/password in memory has only the advantage of not having to retype it every time. Everything else is just exactly the same. You need to be more specific, if I should take a closer look, although I don't have the faintest idea...
I need to do more experimenting with this. Since I normally use the saved *.EVP file to do the connection (after initially doing it the hard way, and saving it), using that option is not going to buy me anything. The biggest "problem" is trying to convince EVFSGUI to use the proper credentials for windows, when there are different credentials for eCS on the same machine. I need to think about that for a while.
The rest of the problems (that I know about) exist in the pseudo drive that EVFSGUI creates. Using small shares seems to work okay. Using large shares (whole drives, with many thousands of files) is still very flaky. I will need to find some time to document the problems, and how to reproduce them.
I will post a notice that the SAMBA TRAC is awaiting feedback, from a number of users, Apparently, it does not notify a user when an update has been made, so it is up to the user to monitor for updates, and make the appropriate response.
It appears that the owners are starting to close incidents when there is no feedback, so if you can't find your incident, it may have been closed.