With native drivers, after installing drivers (files are copied on on the printer/W32X86/3 folder).
The driver says that: "unexpected error occured in the print driver".
With a capture runing with tcpdump we can see that the client is trying to use SetPrinterEx on PrinterPrivateData methods.
Those methods fail with an access denied error code (access is done with a domain adminitrator).
More information on the problem, it turns out that this driver is heavily using the registry of the server.
The capture http://www.matws.net/vrac/3004_applynoright.pcap.bz2 show the dialog between the server (192.168.99.9) and the client (10.6.0.62).
During this exchange we have errors message around packets 2851, 2889, 2892 and 5907.
The last message indicate that the driver has a problem and that the current windows (the properties of the driver) should be closed.
Right click + properties still raise an error message, the file http://www.matws.net/vrac/properties.pcap.bz2 show the dialog between the server and the client.
According to this capture I have the impression that the driver is needing entries in registry.
It turns out that my domain administrator:
SAMBA4\Administrator, is not able to write to the registry of the server (write access limited to bultin\administrators).
So I created the builtin group and added SAMBA4\domain admin, then SAMBA4\administrator. But tries failed to give the rights to write in the registry
(this might be due to the fact that winbind is not completely configured with nsswitch or due to samba4 do not unroll groups)
So I created a local account : SMBFSVZ01\root and added it to the group.
After this I was able to create some keys in the registry.
The capture http://www.matws.net/vrac/3004_applyright.pcap.bz2
show the exchange when clicking apply button after setting the driver, with a user that has proven rights to modify the server registry.
It's similar to the capture done without rights and still produce error message and of course printing is not working.
I tried to put keys and values directly into the registry, first with this file:
Then with this one
Because I had errors while creating the following keys:
After loading this "patch" into the server registry, the property pannel for this printer stops emitting error message, and I was able to
print test pages.
So due to this I think that the driver is trying to set values in registry through RPC calls, and it seems that samba is not implementing this calls.
Which leads to not being able to install printers like Xerox 7232 Workcenter on a samba server.
For further information the capture at
Indicate exchange between two XP workstation when trying to install drivers on 10.6.1.62 from 10.6.1.60 (capture start after driver upload).
Do you have any chance to test this with Samba 3.4.0pre1 ?
Not exactly I tried with GIT on changeset 8f3f7cd.
But I haven't been in such deep analysis with this version (just tested without creating bultin groups and so on ...).
Is this with the X-GPDWinXP03V_PS_English.exe driver ?
No I used for my last tests :PCL Driver - Xerox User Interface - Microsoft Certified
It's available here
Previous tests didn't show any difference between the drivers (PCL, PCL6, and PS).
This driver doesn't necessarily the printer (at least to test the installation it can be done even if you do not have the printer).
On Samba 3.0.33-3.7.el5, I'm getting what it sounds like the same issue.
I'm trying to serve the "Xerox global driver (c) " via samba, according to samba3 howto webpage, for a Xerox Phaser 3300MFP, but I believe the printer is not the point.
This principle is working quite fine with some Canon printers, even behind Dlink printer server boxes.
With the Xerox driver, I get the exact same symptoms as Matthieu, ie. I see the driver files getting copied to the client W32X86/3 directory.
But when trying to show the printer properties on the client side, I get the same error : "unexpected error occured in the print driver".
I'm not skilled enough to read the wireshark flows, but increasing the log level of the samba server shows many issues that confirm the driver tries to write (somewhere) as root.
As I said, I'm using Samba 3.0.33 and the man page says the registry is not yet implemented in this version ("Starting with Samba version 3.2.0, the capability to store Samba configuration in the registry is available.")
So if any driver is using the registry to work, I guess my samba 3.0.33 won't ever be able to share such printer drivers.
Anyway, may Matthieu describe more precisely how he did that :
> So I created the builtin group and added SAMBA4\domain admin, then
> SAMBA4\administrator. But tries failed to give the rights to write in the
> (this might be due to the fact that winbind is not completely configured with
> nsswitch or due to samba4 do not unroll groups)
> So I created a local account : SMBFSVZ01\root and added it to the group.
Thank you very much.
changed according to our irc talk
Just to make it clear, due to resource problems we can only fix this for 3.4 for now.
Ok, took a deep investigation on this but apparently the driver install process does not try to create the winreg keys itself at any time. Seems like they need to be created by us during the spoolss_AddPrinterDriverEx call. I'll setup a xp->w2k3 install of that driver to have a trace that I can learn from.
If you need trace I can provide them. I guess that XP->XP is also OK to get them.
Yes, please Matthieu, that would be helpful.
Have a look at http://www.matws.net/mat/misc/xerox_xp_to_xp.bz2
Thanks Matthieu, but that trace did not contain a fresh install of the driver on the remote spoolss server.
I remade a trace that you can find at http://www.matws.net/mat/misc/xerox_7232.bz2
The trace contains the driver installation.
There is also starting from packet 38030 calls from a windows when clicking on
properties of the printer.
So according to our talk 1/2 months ago I retried with samba 3.5.
It gaves almost the sames error. And now I'm not anymore able to trick samba to add the keys by myself.
So I made more investigations about this bug.
So in s3.5rc1 the same workaround as I described before is working now (it was broken in the s3.4 series).
I remade a fresh capture of the driver installation behavior with a s3.5git server it's at:
As you might see in the trace we are facing 3 big problems:
* driver tries to access \\server\,Xcv Samba Printer Port
* driver tries to access registry keys \HKLM\SYSTEM\CurrentControlSet\Control\Print\Monitors\Standard TCP-IP Port\Ports\Samba Printer Port (and other Monitor also as the TCP-IP is failling)
* driver tries to write to PnPData and DsDriver, they are not created in the current code
I also have a xp client trying to set the driver on a w2k3 server at http://www.matws.net/misc/w2k3_xp.pcap.gz
It's worth noting that both capture are very different.
good address for the captures are:
Matthiew, thanks for filing this. We're experiencing the exact same problem with samba v3.3.9 and Xerox 7346 drivers.
Created attachment 6848 [details]
git-am jumbo patch against master
I have created a set of patches to create printer ports based on printer URIs from CUPS and to store the port information in the registry, they should help the first two issues identified by Matthieu in comment 16. Patch is against master and is attached. Individual patches have been sent to samba-technical as well.
Comment on attachment 6848 [details]
git-am jumbo patch against master
very interesting patchset indeed, need to take a closer look though.
gd, what about these patches?
Sorry, I'm the one that dropped the ball on this one. David Disseldorp gave me some feedback on these patches and I never managed to get back around to cleaning them up and resubmitting. I'm hoping to get his suggestions integrated soon and then I'll resubmit.
Thanks, we're looking forward for your updated patchset Justin.
Which is the status of this bug?
I have no answer to whether this bug is still alive yet.
But as an additional useful comment, I can say that in the month to come, we will start again an extensive work of installation (tests and deploy) of such a setup (samba + drivers deployment to windows hosts).
We already began some tests, and they were bad, so - though this time they're not Xerox drivers - I guess I will add more comment to this bug.
Last time I coped with this bug, I stopped around some "registry" related driver issues...
Depending on the size of your company it would be interesting to get details from the manufacturer. Some drivers are made so that they are executed on the print server.
Obviously this can't fly with Samba as the host is not able to run Windows Code.
Also Gunter & Andreas can you work with Justin to get his patch into shape for our master git tree ?
closing, the jumbo patch is upstream since years