Connection already exists?

[Jeff Williams]

I'm using Wpkg-GP 0.17 in a computer lab, and several of the computers will not run Wpkg successfully on startup.  It tries to run, but this appears in the log:

2014-12-19 13:16:32,365 - WpkgService - DEBUG - Trying to connect to share. 1 of 7

2014-12-19 13:16:49,003 - WpkgService - INFO - Tried to connect to share '\\server\wpkg', but a connection already exists. Will disconnect, and retry.

2014-12-19 13:16:49,003 - WpkgService - INFO - Trying to disconnect from the network share \\server\wpkg

2014-12-19 13:16:49,098 - WpkgService - ERROR - Error when processing Named Pipe Client:

Traceback (most recent call last):

  File "WpkgServer.pyc", line 195, in DoProcessClient

  File "WpkgExecuter.pyc", line 96, in Execute

  File "WpkgNetworkHandler.pyc", line 101, in connect_to_network_share

  File "WpkgNetworkHandler.pyc", line 116, in disconnect_from_network_share

error: (2404, 'WNetCancelConnection2', 'The device is in use by an active process and cannot be disconnected.')

So then Wpkg gives up.  Since this is done during the boot process, I don't know what other process would already be accessing that share.  Any thoughts?  On some computers it works fine, on others I get this result.  They are all Windows 7 64-bit systems...

[Marco Gaiarin]

Mandi! Jeff Williams
In chel di` si favelave...

> 2014-12-19 13:16:49,003 - WpkgService - INFO - Tried to connect to share '\\server\wpkg', but a connection already exists. Will disconnect, and retry.

Windows client (it is not a CIFS protocol restriction, it is an
implementation error) cannot connect to the same server, to the same
share, using two different users.

So, if you start WPKG by hand in a machine where the current logged
user have the \\server\wpkg connected, wpkg will fail to connect it
(guest or auth mode, does not change).


If your server is a samba one, you can define as you want 'netbios
aliases', for example:

netbios aliases = WPKGSERVER

and then use in wpkg:

\\WPKGSERVER\wpkg

effectively ''fooling'' the client.

--
dott. Marco Gaiarin GNUPG Key ID: 240A3D66
Associazione ``La Nostra Famiglia'' http://www.sv.lnf.it/
Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN)
marco.gaiarin(at)lanostrafamiglia.it t +39-0434-842711 f +39-0434-842797

Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
http://www.lanostrafamiglia.it/25/index.php/component/k2/item/123
(cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)

[Jeff Williams]

Thank you!  However, I'm not running it by hand; this is what happens when Wpkg-GP runs at startup even before anyone has logged into the computer.  And it happens on some computers, but not on others...

[Marco Gaiarin]

Mandi! Jeff Williams
In chel di` si favelave...

Happy new year, list! ;)

> Thank you! However, I'm not running it by hand; this is what happens when
> Wpkg-GP runs at startup even before anyone has logged into the computer. And
> it happens on some computers, but not on others...

Another source of trouble could be 'domain login with machine account
credentials': AFAI've understood, if the client is joined to the domain
and an access to a network folder with SYSTEM users (of course without
specifying explicitly credentials) is tried, a logon with the machine
account is tried first, and i've never get it to work with Samba.

It is still strange, because the client have to fallback to guest user
access if fail, but... could be a hint... i hope...

[Jeff Williams]

That's a good thought. But I've used specific credentials since the start.  The workstations are members of a domain...

[Jeff Williams]

Just tried configuring Wpkg-GP with no specified credentials, so that it uses SYSTEM -- same result in the log file.

[Marco Gaiarin]

Mandi! Jeff Williams
In chel di` si favelave...

> Just tried configuring Wpkg-GP with no specified credentials, so that it uses
> SYSTEM -- same result in the log file.

Sorry, i don't know what can be... i've exausted by hypotesis. ;(((

[Jeff Williams]

I may have found the issue.  Seems obvious now, but at the time...  In any case, I had configured Wpkg to log to a shared folder, so I can see centrally how installations are going.  I changed it to log to a folder outside the shared Wpkg folder, and then this issue *seems* to have disappeared.  I haven't tested extensively yet, but it might be worth noting in the documentation that when logging to a shared resource, it should not be the Wpkg "home" folder.