Having configured samba for serving printer drivers to XP clients, i'm using the
properties dialog from an XP client (as the printer admin user) to install the
needed driver in the samba print$ share.
This doesn't work however;
Windows errors out with :
Unable to install Lexmark Optra R Series PS, Windows 2000 or XP, Intel
driver. Operation could not be completed.
Samba log the following message in the client log :
[2004/10/11 07:46:48, 0] smbd/service.c:make_connection(800)
client_pc (192.168.1.12) couldn't find service
Searching for the problem on google yields quite a few hits but no real solution
(that i have come across). Searching om samba bugzilla yields nothing, so here
we are :-)
I'm running 3.0.8pre1 with the #1519 patch applied
Created attachment 713 [details]
gzipped level 10 log of the problem happening
Created attachment 714 [details]
smb.conf as output from 'testparm -s'
Created attachment 715 [details]
test patch to prove a problem in rpc_server/srv_spoolss_nt.c
The srv_spoolss_nt, getprinterdriverdir_level_1 function adds heading \\'s to
the URI string, resulting in an URL that looks like \\\\server\print$\W32X86
which doesnt work...
The patch simply removes those leading \\'s in order to make the string look
okay and after that, the driver gets uploaded successfully.
While i realize that this is proably not the right way to fix this issue, it
points to the problem we're facing.
i noticed after applying the test patch, when i have the driver successfully
uploaded, the printer object under "Printers and Faxes" on the samba server,
changed it's name to that of the driver! This may or may not be because of the
test patch or perhaps because of a typo in the #1519 patch. I'll create a new
bug for this, but please let me know what you make of it first, okay?
Thomas, can you try the latest SAMBA_3_0 svn tree ? There is
no instance of get_called_name() in the current code. This might
indicate a bug in the original patch.
wrt to changing the printer name when uploading a new driver, this is
default Windows behavior. The Windows client is sending the SetPrinter()
call with the new name. You can simply rename the printer after
uploading the new driver. You will see the same behavior on a local
Windows printer when the original name matches the assigned driver.
new variant of patch based on thmos' original idea checked
into the 3.0 svn tree. Thanks for pointing this out
tested and works, thanks!
this fix has been incorporated into the second draft of the patch
for BUG 1519 (already checked in to the 3.0 source tree).
originally reported against 3.0.8pre1. Cleaning up
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.