The Samba-Bugzilla – Bug 9474
Windows 8 clients fail to locate print drivers.
Last modified: 2014-10-20 14:01:04 UTC
Created attachment 8296 [details]
PCAP of driver installation failing
We have a samba system under NetBSD which acts as a print gateway for Windows clients to our CUPS server. Our environment is very open, so there's no authentication or anything like that... everything is open and anyone on the LAN can print to any of the given printers.
We've used this system for near on a year now with Windows XP and Windows 7 guests having no issues installing the printers and associated drivers automagically by browsing the device and using the auto-locate-driver mojo on both x86 and x64 clients.
When Windows 8 appeared, for some reason the devices (both x86 or x64) are unable to locate said drivers and that's kind of a downer.
I spent a great deal of time trying to debug the CUPS driver itself, to no real avail, but also wonder if it's something in the RPC magic which is breaking; since Windows 8 claims glorious compatibility with "legacy" print drivers.
firstname.lastname@example.org worked me through some configuration oddities I'd developed along the way, without a change in the behavior. The current test host smb.conf is attached, along with two pcap's... one of a driver installation working with a Windows 2k8R2 server, the other of it falling to bits against our current print host.
I do appreciate that this may turn out to be an issue back in the CUPS realm, but the more detail I have to substantiate that the better!
Created attachment 8297 [details]
PCAP of driver installation succeeding
Created attachment 8298 [details]
Current smb.conf from test host
thanks for your report. It helps if you tell us much as possible and maybe add a link to the drivers you try to install and use. However we need log files.
SAMBA BUG REPORTING
This is a small howto to help you to provide all information which are needed
to find out what's going on your machine. This is a general howto so maybe it
will cover more things you don't use.
Please also read http://www.chiark.greenend.org.uk/~sgtatham/bugs
Providing instructions how the reproduce the error
The first aim of a bug report is to let the developer see the failure with
their own eyes. If you can't be with them to make it fail in front of them,
give them detailed instructions how to reproduce the problem so that they can
reproduce the error on their development environment.
If this doesn't work, describe everything in detail! The more information you
provide the easier we can see what's going on.
Providing Samba log files
Post the output of 'rpm -qi samba' or 'rpm -qi samba-<subpackage>' if you're on
a RPM based system. It gives detailed information about the installed packages.
We need that information to reconstruct what happened and possibly to reproduce
the bug on our machines.
Always provide all log files from the '/var/log/samba/' directory and the
configuration file '/etc/samba/smb.conf'! If you see errors in tdb files make
sure you add the related tdb files from '/var/lib/samba'.
If winbind for logging in is part of the problem please provide
'/etc/security/pam_winbind.conf' and if you have enabled debug in
'pam_winbind.conf' '/var/log/messages' or '/var/log/secure' is required too.
More detailed description about different Samba components can be found below
If you discover a crash in one of the Samba components, please make sure that
you have installed debuginfo packages. Often the backtrace can be found in the
log files. If you have installed debuginfo packages, you can find a short
backtrace in the log files and a few lines later the full backtrace. Make sure
you provide the full backtrace.
Testing daemons (winbind, smb, nmb)
1. Stop all running Samba processes (winbind, smb, nmb)
2. Remove all log files from /var/log/samba/
With this approach we ensure to have the start date of the testing in the
3. Edit /etc/samba/smb.conf and set the following variables in the in the
[general] section of the config:
debug level = 10
debug pid = true
max log size = 0
Instead of setting a global debug level in smb.conf it's also visible to
smbcontrol <damon_name> debug 10
to increase the debug level of the Samba daemon in question to 10 at run
If winbind is part of the scenario edit /etc/security/pam_winbind.conf
debug = yes
4. Start the processes again (winbind, smb, nmb)
5. Reproduce the error and note the time when you start any test. If a problem
occurs while testing note the time (use date on the system you perform the
tests on to get a time fitting to the log files).
Attach the log files from '/var/log/samba/' and the tdb files from
'/var/lib/samba/' to the bug. If possible, remove the tdb files and provide clean
files. Therefore it's best to bond them to one compressed tar archive. The
relevant parts of '/var/log/messages' could be interesting too.
If possible create network traces with tcpdump or wireshark from the problem and
attach them too. Always make sure to capture only one problem per network trace
file. This makes it easier to understand the problem.
tcpdump -n -i eth0 -s 0 -w samba-problem-description.pcap
If you have a special network setup especially with Active Domain controllers
please describe how you're network looks like and what the domain names are.
Tell us which version of Windows you're using, the functional level of AD and
which trust relationships exist.
The drivers in question are those provided by the CUPS project at: http://svn.easysw.com/public/windows/trunk/ and added using cupsaddsmb. (Without error.)
Will post logs in few minutes.
Created attachment 8340 [details]
tar of all /var/log/log.* files during the behavior
Any news on this bug? Has it been fixed in a subsequent 3.6 release?
We're also using the CUPS printer drivers and users are bringing in Windows 8 and they cannot locate the print drivers.
looking into this...
Any news? Is more information needed? Thanks.
We need to cleanup more code but probably that patch should do it.
(In reply to comment #9)
> We need to cleanup more code but probably that patch should do it.
Except that it doesn't compile when applied to 3.6.10:
rpc_server/spoolss/srv_spoolss_nt.c: In function ‘_spoolss_GetPrinterDriver2’:
rpc_server/spoolss/srv_spoolss_nt.c:5637:37: error: ‘SPOOLSS_DRIVER_VERSION_2012’ undeclared (first use in this function)
rpc_server/spoolss/srv_spoolss_nt.c:5637:37: note: each undeclared identifier is reported only once for each function it appears in
Thanks for the patch... will give it a try later today and see how things look.
I believe this commit will also be required: https://git.samba.org/?p=samba.git;a=commitdiff;h=638ed90620e3c6a35ef56a11c612c13d6b7d6ff5
Test case with both patches applied to 3.6.10 works here.
Production test pending.
Removed the x64 requirement from the patch and tested installs with x86 and x64 Windows 8 clients successfully.
Will push the package to production later today and verify with some end users.
(In reply to comment #13)
> Removed the x64 requirement from the patch and tested installs with x86 and x64
> Windows 8 clients successfully.
The patches, as is, only work for 64 bit clients?
I tested with a 64 bit client as I do not have a 32 bit client.
What needs to change so that it is successful for x86 as well?
Created attachment 8449 [details]
Patch without limiting change to x64 platform
Not sure if there may be other consequences to removing the x64 check, but this patch is working in tests at our location.
Yep, I didnt have a 32bit win8 version at hand yet, but I think this will be the final change for now:
Superb... we have that in production now with users and lab reporting success. (Patched again 3.6.3, because of buildhost limitations.)
Will update if we see any issues, but for now this looks good. Again, sincerest thanks! :-D
(In reply to comment #16)
> Yep, I didnt have a 32bit win8 version at hand yet, but I think this will be
> the final change for now:
This is odd - but I should mention I'm testing with the 64 bit Consumer Preview:
When I use this patch (along with the one in comment #11) the systems finds the driver and installs the printer yet it doesn't show up when viewing the Devices and Printers, _but_ when you go to print something the printer is available.
This could be confusing to some users (however, it may be a Consumer Preview glitch).
When I used the previous patch that was x64 specific the printer installed and _was visible_ in the Devices and Printer pane.
Given the nature of the patch and the behavior your describing, I find it difficult to conceive that the behavior is a result of the change in the patch.
I'd suggest performing additional tests to reproduce the case in each configuration to ensure that the behavior is consistent on the client device based on which patch you're using.
Created attachment 8465 [details]
patch for 4.0.x
Created attachment 8466 [details]
patch for 3.6.x
Comment on attachment 8465 [details]
patch for 4.0.x
Comment on attachment 8466 [details]
patch for 3.6.x
Looks also fine.
Karolin please add the patches to the corresponding branches. Thanks!
Although the patch worked for my test case I just ran into a problem in production that's described in this post:
where the 0x000006d1 error occurs on the client.
I'm not sure what the common denominator is, but of probably two dozen devices which have Just Worked(tm) with this patch, we've now got one which is exhibiting the same behavior you report there with error 0x000006d1. Will see if the suggested fix works, but in a 100% BYOD environment like ours, that might be taxing in the long run. (Still... pretty thrilled to have a working patch! ;-) )
(In reply to comment #24)
> Karolin please add the patches to the corresponding branches. Thanks!
Pushed to autobuild-v4-0-test and v3-6-test.
Ok. I am looking further into the gdi handle calls and how we could deal with the PrinterIC functions.
(In reply to comment #27)
> (In reply to comment #24)
> > Karolin please add the patches to the corresponding branches. Thanks!
> Pushed to autobuild-v4-0-test and v3-6-test.
Pushed to v4-0-test.
(In reply to comment #28)
> Ok. I am looking further into the gdi handle calls and how we could deal with
> the PrinterIC functions.
Re-assigning to Günther for further investigation.
*** Bug 9940 has been marked as a duplicate of this bug. ***
This bug is mentioned in the 4.0.3 changelog http://www.samba.org/samba/history/samba-4.0.3.html maybe it can be closed?
Well, I think we should leave it open to track the followup issues and the pointers to these.
Is this bug supposed to be fixed in samba-3.6.24?
I've got exactly the same problem as described by the committer,
some (not all) windows 8 machines in our samba-3.6 domain
cannot use the point and click printer drivers on the samba server.
It all works well with Windows XP and Windows 7, also with 64-bit machines.
I have log files in log level 10 and a tcpdump, so that might be helpful, in case it is a samba bug and not a misconfiguration on my side...
Created attachment 10123 [details]
tcpdump for failing attempt to doubleclick on a shared samba printer
Client is Windows 8.1 Pro 64-bit
double-clicking on printer gives error 0x000006d1
Created attachment 10124 [details]
logfiles for failing attempt to doubleclick on a shared samba printer
I took a look at the 3.6.24 source and this patch is in there.
I also downloaded an MSDN copy of Windows 8.1 N Pro this morning and installed it on a VM to see if I have an issue here and it worked as expected. (We're not on 3.6.24, but we are using this patch.) Looking at your PCAP, the client version is being sent as 4 (SPOOLSS_DRIVER_VERSION_2012) which is what this patch resolves. (Packet 249 shows the GetPrinterDriver2 call, with what looks like a successful response in packet 254.)
It seems to me that you're not seeing the initial issue for this bug, but rather the issue described here: https://lists.samba.org/archive/samba/2012-December/170616.html (Which includes a solution.)
Thank you for the quick reply!
The group policy "Computer
Configuration/Policies/Administrative Templates/Printers/Always render
print jobs on the server" was unconfigured, setting it to "disabled" did the trick!
point-and-click printing also works when I set this registry key only:
In bug 6559 this key is mentioned,
but it says the default would be "off" not "on", so it seems that at least on some windows 8.1 machines to default is on and it must be disabled to make it work (On this machine the key is not present when the group policy is left unconfigured).
I have this problem. A cups printer server with samba that works with windows 7 but windows 8 clients can't find the driver printer. Can you help me on how to solve it? Samba version is 3.6.6
this was fixed since 3.6.13. You should update your Samba installation to 4.1.x. I see no reason why this but report should not be closed fixed. Günther?
(In reply to Björn Jacke from comment #40)
Can you help me on upgrade to 4.1.X? I'm on a raspberry pi. Should I download the source and compile it? there is a binary that I can install?
(In reply to Jose Xavier from comment #41)
or a repo with a recent version.
Bugzilla is for bug reporting only. For dicussion you can use the samba mailing list. For commercial support you can find some options here: http://www.samba.org/samba/support/globalsupport.html