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 ::{2227a280-3aea-1069-a2de-08002b30309d} 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 non-production versions.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.