When using server side PostScript drivers for printers on a samba server and connecting with Windows Server 2008, everytime I get an error message 0x000006d1 at the Windows machine.
With Windows XP it works perfectly.
Please find attached my debug level 10 output from smbd.log.
Created attachment 4436 [details]
log.smbd with debug level 10
Can you share some more info where you got that "edv1" driver from ?
I see that w2k8 is trying some unimplemented GDI specific spoolss calls and I need to be able to reproduce this error locally.
Created attachment 4447 [details]
for Bug6559 used PostScript driver
Used printer drivers are Ricoh Aficio AP2700.
Note to myself: First research indicates that this is related to failing backchannel connections (failing with access denied) for printer change notify when talking to w2k8.
We have this problem also here in a production environment since installing SP2 on our W2K8 terminal server and therefore would be very happy if this could be solved, too. :-)
We can also help to debug this if help is needed.
Kind regards, Axel Beckert and Patrick Frei from the IT Service Group of the Dept. of Physics at ETH Zürich.
Confirmed on CentOS 5.3 x64 up-to-date (Samba 3.0.33, presumably with a bunch of backports), in combination with Win2k8 Enterprise x64's.
Used drivers are a bunch of different latest Ricoh models/PCL5e drivers.
The issue occurs after applying KB958741 (http://support.microsoft.com/kb/958741)
We also get 0x000006d1 when trying to connect to a printer from Win 2k8 R2 64-bit (Samba 3.3.10). We also get a similar (?) error, 0x0000052e, when trying to connect to the same priter/server from Win 7 64-bit.
We get this error from W2k8R2 connecting to a samba server with the latest 3.4 version (3.4.6).
A log with level 10 could be found here:
We use the CUPS Windows Printer driver
Windows Side: Windows Server 2008R2
Samba Side: 3.4.6 (from sernet) on Scientific Linux (aka RHEL) 5.4
(In reply to comment #10)
> A log with level 10 could be found here:
> We use the CUPS Windows Printer driver
> Windows Side: Windows Server 2008R2
> Samba Side: 3.4.6 (from sernet) on Scientific Linux (aka RHEL) 5.4
hm, isn't the CUPS Windows Printer driver 32bit only ?
if so, it will hardly work with 64bit Windows 2008 R2.
There is also a 64 bit Version, though you could not find it so easily on the cups website. We do have both 32bit and 64bit driver installed on the samba server and Windows 2003 64bit works very well.
Ok, took a deeper look here:
The log you uploaded shows that the client starts to call out for non-implemented spoolss calls which are used for GDI printing (server side printing) which we do no support right now. Inside the spoolss server we try very hard to convice the client that we only can accept RAW printjobs (already rendered at the client - which is btw. the new default since I think Vista). Why the client still tries server side rendering is hard to tell. Samba just fails with RPC_S_PROCNUM_OUT_OF_RANGE error (windows displays that as 0x000006d1).
What I did to reproduce your failure is to get a w2k8r2 box, setup one 3.4.6 samba installation, installed (via cupsaddsmb) the cups windows 64bit drivers, double clicked on one of the exported printers and w2k8r2 happily installed the 64bit driver w/o any problem and I could print.
My theory is that your print client (your w2k8r2 box) has one of the printer specific group policies applied, notably: "Always render printjobs on the server". This would explain that behavior. Could you check if that is set in your environment ?
Ok, fully reproduced that failure with the same error code and the same logfile pattern.
It is most probably related to having:
"Computer Configuration/Policies/Administrative Templates/Always render printjobs on the server"
The Policy was not set (unconfigured), but setting it to disabled changed the behavior. Now I get a different error: 0x000003e6
Also a I side note: The printer is in the active directory published with the flag "Render on client side" set.
But as I had to get it working, I reverted now back to samba-3.3.11, this works again very fine.
I will setup somewhere in the next days a test print server and will send you more debug logs.
My client is a x86 W2k8 server with terminal server role installed. With servicepack 1 installed there is no problem, it works fine. If I update it to servicepack 2 it gets the error 0x000006d1.
The group policy setting was set to unconfigured, I changed it to disabled but get the same error as before: 0x000006d1.
I could resolve the problem for me. I configured both GPO settings to "disabled" and then it works fine:
"Computer Configuration/Policies/Administrative Templates/Printers/Always render
print jobs on the server"
"Computer Configuration/Policies/Administrative Templates/Printers/Point and Print Restrictions"
No 0x000006d1 error anymore.
I'm seeing the 0x000003e6 error trying to connect a Windows 7 32-bit machine to samba 3.4.6. Driver is for Ricoh Aficio CL7200 and is installed on server.
Also seeing the 0x000003e6 error, trying to connect Windows 7 64-bit to both sernet samba 3.5.4 and sernet samba 3.4.8 on centos 5.5, using the 64-bit cups driver from SVN. I copied pscript5.dll, ps5ui.dll, pscript.ntf and pscript.hlp from the Windows 7 machine. I also tried setting both local group policies to disabled, but that does not help either. Anything I can provide to try and pinpoint the problem?
The exact same Windows 7 64-bit client (no reinstall) connects fine using the samba3x package from current EPEL repositories, which is based on 3.3.8, both with and without the local group policies explicitly set to 'disabled' instead of 'not configured'. Not sure if this information helps, but it can't hurt either.
Still seeing the 0x000003e6 error with Samba 3.5.6. Anything needed to help trouble shoot. Also, is this now a duplicate of bug 7567?
If anyone is still experiencing this issue - changing the following registry value on the affected clients fixes it:
(Simply deleting the "ForceCSREMFDespooling" value should also work, because AFAIK Windows assumes a value of 0 if it doesn't exist.)
This issue is not a Samba bug, but a faulty configuration on the client. Setting "ForceCSREMFDespooling" to 1 means "force print jobs to be rendered on the server", and Samba simply doesn't support this. As long as this value is either set to 0 or doesn't exist, everything should work fine, but if something sets it to 1, printing on Samba printers will fail with the 0x000006d1 error.
A very big thank you to Commenter 22 as this solved my issue. However, I think he/she is wrong about one thing, and that's that Windows assumes a value of 0 if the registry key is not present. I did not have this registry key and I was experiencing this issue (on both Windows 7 and 8.1 workstations).
Adding the registry key and rebooting solved the issue on both workstations. My printer was able to to be installed via the Point N' Print mechanism.
My printer is a Canan MF-4350d. I wonder if the problem is printer driver specific as I don't see many other people complaining about the issue.
The content of attachment 4447 [details] has been deleted for the following reason:
no need to have this binary driver here
closing as WORKSFORME as the right GPO or registry key setting mentioned here fixes the problem
Alas, I'm again seeing this with Windows 10.
"Computer Configuration/Policies/Administrative Templates/Always render printjobs on the server" is disabled (which sets [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers] "ForceCSREMFDespooling"=dword:00000000) but the goddamn client still calls