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. kukks@irc.freenode.net 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! TIA.
Created attachment 8297 [details] PCAP of driver installation succeeding
Created attachment 8298 [details] Current smb.conf from test host
Hi Mike, 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 this section. Providing backtraces ===================== 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 log files. 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 use smbcontrol <damon_name> debug 10 to increase the debug level of the Samba daemon in question to 10 at run time. If winbind is part of the scenario edit /etc/security/pam_winbind.conf and set: 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. Network traces =============== 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 Network topology ================= 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.
Hi Andreas, 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. Cheers.
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. https://git.samba.org/?p=asn/samba.git;a=commitdiff;h=5af857198ba1c32018ce48e84c6654e58405c5b8
(In reply to comment #9) > We need to cleanup more code but probably that patch should do it. > > https://git.samba.org/?p=asn/samba.git;a=commitdiff;h=5af857198ba1c32018ce48e84c6654e58405c5b8 Except that it doesn't compile when applied to 3.6.10: Compiling rpc_server/spoolss/srv_spoolss_nt.c 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. Sincerest thanks!
(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? Thanks.
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: https://gitweb.samba.org/?p=gd/samba/.git;a=commitdiff;h=d4396f1026f8a4390f17a5c7d96852aad61f9355
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: > > https://gitweb.samba.org/?p=gd/samba/.git;a=commitdiff;h=d4396f1026f8a4390f17a5c7d96852aad61f9355 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 Looks fine.
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: https://lists.samba.org/archive/samba/2012-December/170616.html 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
Hi Oliver, 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.) HTH, Mike.
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: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers] "ForceCSREMFDespooling"=dword:00000000 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).
hi all, 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
*** Bug 9536 has been marked as a duplicate of this bug. ***