• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

SAMBA for eCS... Need method for complete removal from eCS PC.

Started by NNYITGuy, 2012.01.20, 14:18:03

Previous topic - Next topic

herwigb

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.
Kind regards,
HerwigB.

DougB

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.

herwigb

Doug,

The daily update  ;) 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).

Kind regards,
HerwigB.

DougB

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.

DougB

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.

herwigb

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...

Kind regards,
HerwigB.

DougB

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.

DougB

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.