Samba: 3.5.4 Windows: 7 Enterprise, x64 I have several printers that are failing to install via Samba. The driver download to the client is successful, at which point the Add Printer fails with "Windows cannot connect to the printer. Operation failed with error 0x000003e6." Searching this error brought a few suggestions, but none so far have panned out. Have tried different ps5ui/script5 dlls without success. A packet capture on the client did not yield any obvious errors in the transmission. Running with loglevel 10 provides a seemingly successful transaction. The only occurance of WERR is the following... [2010/07/13 19:45:09.493469, 3] rpc_server/srv_pipe_hnd.c:344(free_pipe_context) free_pipe_context: destroying talloc pool of size 0 [2010/07/13 19:45:09.493509, 5] rpc_server/srv_pipe.c:2366(api_pipe_request) Requested \PIPE\\spoolss [2010/07/13 19:45:09.493549, 4] rpc_server/srv_pipe.c:2403(api_rpcTNP) api_rpcTNP: \spoolss op 0x4e - api_rpcTNP: rpc command: SPOOLSS_GETPRINTERDATAEX [2010/07/13 19:45:09.493591, 6] rpc_server/srv_pipe.c:2433(api_rpcTNP) api_rpc_cmds[78].fn == 0x7fb88db56c10 [2010/07/13 19:45:09.493639, 1] ../librpc/ndr/ndr.c:251(ndr_print_function_debug) spoolss_GetPrinterDataEx: struct spoolss_GetPrinterDataEx in: struct spoolss_GetPrinterDataEx handle : * handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000007-0000-0000-3c4c-06b60d3e0000 key_name : '' value_name : 'PrintDriverIsolationExecutionPolicy' offered : 0x00000004 (4) [2010/07/13 19:45:09.493821, 4] rpc_server/srv_lsa_hnd.c:219(find_policy_by_hnd_internal) Found policy hnd[3] [0000] 00 00 00 00 07 00 00 00 00 00 00 00 3C 4C 06 B6 ........ ....<L.. [0010] 0D 3E 00 00 .>.. [2010/07/13 19:45:09.493896, 4] rpc_server/srv_spoolss_nt.c:8577(_spoolss_GetPrinterDataEx) _spoolss_GetPrinterDataEx [2010/07/13 19:45:09.493934, 10] rpc_server/srv_spoolss_nt.c:8580(_spoolss_GetPrinterDataEx) _spoolss_GetPrinterDataEx: key => [], value => [PrintDriverIsolationExecutionPolicy] [2010/07/13 19:45:09.493972, 8] rpc_server/srv_spoolss_nt.c:2182(getprinterdata_printer_server) getprinterdata_printer_server:PrintDriverIsolationExecutionPolicy [2010/07/13 19:45:09.494011, 1] ../librpc/ndr/ndr.c:251(ndr_print_function_debug) spoolss_GetPrinterDataEx: struct spoolss_GetPrinterDataEx out: struct spoolss_GetPrinterDataEx type : * type : REG_NONE (0) data : * data: ARRAY(4) [0] : 0x00 (0) [1] : 0x00 (0) [2] : 0x00 (0) [3] : 0x00 (0) needed : * needed : 0x00000000 (0) result : WERR_INVALID_PARAM Let me know what additional debugging info is needed and I will provide it.
Is this a standalone win7 box or are you member of a domain ?
Domain joined.
(In reply to comment #2) > Domain joined. :) joined to what ? AD ? if so, w2k8 ? w2k8r2 ? I guess group policies on your site enforce specific client behavior which avoids proper communication with samba's spoolss server.
That would be 2008R2. I'm only *aware* of one policy we have in place affecting printing right now, disabling Point and Print Restrictions. Looking at Computer Configuration/Administrative Templates/Printers, nothing else appears to be configured. I'm no expert in spoolss communication, so I guess I'm not sure what behaviors in particular are being restricted. Some operations are obviously working fine since I can browse, and have even been able to install one or two printers. How would you recommend getting to the bottom of which communications are being blocked?
I should also add that this appears to be a regression since 3.3.10.
Can you try setting "Always render print jobs on the server" explicitly to "disable" ?
I think I may have sorted it. If netbios name changes in smb.conf, something stored in ntprinters.tdb or ntdrivers.tdb does not cope well. The result is a printer that partially installs the driver, but at least in some cases fails to fully connect.
Can you give me more information on how you tracked this one down ? I'd like to be able to emit sensible error messages when this occurs to prevent others running into the same problem. Jeremy.
Long story short, I was working on some scripts to back up the tdb files (using tdbbackup). In the arrangement that spawned this bug, I had two domain joined hosts (say samba1 and samba2). I backed up tdbs from samba1, then used samba2 to restore ntdrivers, ntprinters, & ntforms. The goal was to be able to bring up a secondary server with the exact config of a primary server for failover. This was OK in theory, as off the top of my head I wouldn't expect a driver file to be tied to the host, just maybe relationally tied to the printer. As reported, this backup and restore model did not work entirely as expected. On a hunch, I tested the same backup/restore again, this time using the same host. Backed up, reimaged with same hostname, restored. This time, the same printers that failed previously worked as expected. To further my evidence that it was name related, I ran a quick pass of strings over the tdb files, and did detect that the netbios names were present. On samba2, strings found instances of samba1 in the restored tdb. I don't know how or why they're used, but it seems to support my suspicion that the databases are storing this info and then not entirely behaving if the naming changes. It kind of makes sense given that Windows was saying it "could not connect" to the server... if it was being passed the old server name. I would suggest as a test to: - Domain join two samba servers. - Configure some drivers on server1. - Backup the TDBs - Attempt to restore the TDBs to server2 - Attempt to install said drivers on Windows.
Ok, ignore all the parts of this bug where I said I knew what the problem was. Also ignore anything I talked about that involved shuffling around the driver databases. Those may still be problems, but it turns out they aren't *the* problem. I'm running into cases where the same error code/condition is cropping up after nothing but a simple cups driver export. The group policy on the clients is not enforcing anything print related other than disabling point and print restrictions. I did change the policy to disable "Always render print jobs on the server." as one Google result suggested for this error, but it did not help. I have debug 10 logs as well as packet dumps from the clients, but still nothing stands out at my as to why Windows claims the connection failed.
Maybe related to bug 6559, where I posted comments #19 and #20 as well. Also seeing this now on 32-bit clients against Fedora 12 samba 3.4.9. I am not sure what OS our university domain controllers run on but it's at least w2k3. Can I igure this out from a remote client or do I need to ask central IT services?
We are experiencing the same issue with Samba 3.5.6 and Windows 7 Enterprise x64. Three of our thirty-two printers fail to install with error 0x000003e6. All three are Xerox printers, although there are other Xerox printers that work - not the same models however. I'd be glad to provide logs and information to help troubleshoot this problem. Has anyone found a solution other than downgrading to samba 3.3.x?
I did some further testing. If I: 1. delete ntdrivers.tdb and ntprinters.tdb 2. rerun cupsaddsmb -a 3. restart samba Then the problem goes away at least temporarily. This seems similar to what Matt L posted above.
Matt's fix above (#13) has worked for us, at least for the last month.
I've been having this same problem - Samba 3.5.6 (Debian), Windows 2008 R2 DCs and Window 7 32-bit client. The solution from Matt's comment #13 works to get the driver installed on a Windows 7 client, however if the printer's "printing defaults" are modified then the driver install will start failing again. I'm guessing looking at the differences between the tdb files between modifications would be helpful? hermes:~# /etc/init.d/samba stop Stopping Samba daemons: nmbd smbd. hermes:~# rm /var/lib/samba/ntprinters.tdb /var/lib/samba/ntdrivers.tdb hermes:~# /etc/init.d/samba start Starting Samba daemons: nmbd smbd. hermes:~# cupsaddsmb -H hermes -h localhost -U WUM3\\kmshanah -a Password for WUM3\kmshanah required to access hermes via SAMBA: hermes:~# echo $? 0 hermes:~# tdbbackup /var/lib/samba/ntprinters.tdb /var/lib/samba/ntdrivers.tdb hermes:~# cp /var/lib/samba/ntprinters.tdb.bak /var/lib/samba/ntprinters.tdb.clean hermes:~# cp /var/lib/samba/ntdrivers.tdb.bak /var/lib/samba/ntdrivers.tdb.clean Here, the driver installation works fine. Once installed I modified the default paper size from Letter to A4 (from either the Windows 7 client or an existing XP client - both break the windows 7 driver install again) Printer properties -> Advanced tab -> Printing Defaults -> Layout tab -> Advanced -> Paper Size => Change from Letter to A4 Now I remove the printer for the windows 7 client and try to reinstall - it fails again with the 0x000003e6 error. hermes:~# tdbbackup /var/lib/samba/ntprinters.tdb /var/lib/samba/ntdrivers.tdb hermes:~# cp /var/lib/samba/ntprinters.tdb.bak /var/lib/samba/ntprinters.tdb.A4 hermes:~# cp /var/lib/samba/ntdrivers.tdb.bak /var/lib/samba/ntdrivers.tdb.A4 md5sum showed that ntdrivers.tdb didn't change between updating the driver settings, so the problem seems to be with ntprinters.tdb.
Created attachment 6229 [details] ntdrivers.tdb after removal and cupsaddsmb -a
Created attachment 6230 [details] ntprinters.tdb after removal and cupsaddsmb -a
Created attachment 6231 [details] ntprinters.tdb after modifying defaul paper size
Hmmm, this problem starts occuring as soon as someone with printer admin privileges looks at the printer properties dialog, even if you change nothing just clicking okay modifies the 'PRINTERS/printername\0' record in ntprinters.tdb. Once that happens, driver installation starts failing. I can fix individual printers without having to restart Samba using: # tdbtool /var/lib/samba/ntprinters.tdb delete 'PRINTERS\printername\0' # tdbtool /var/lib/samba/ntprinters.tdb delete 'SECDESC\printername\0' # cupsaddsmb -U blah -v printername Would really appreciate if a developer could confirm this problem. I can see this causing headaches for us as more of our users are upgraded to Win 7.
New test with captures and possibly located the problem: I set up a system with Debian Lenny (Samba 3.2.5) to do a comparison against Debian Squeeze (Samba 3.5.6). The 3.2.5 system is named "scruffy", the 3.5.6 system is named "hermes". I installed a HP Laserjet 4000 series CUPS printer (hp4000_test) on both servers, using the same PPD and then added the windows drivers ("CUPS for Windows") using cupsaddsmb. I then installed both printers on a Windows 7 (32-bit) client. To trigger the bug, I then opened the printer properties dialog, changed nothing and clicked ok. This is enough to modify the 'PRINTERS/hp4000_test\0' value in the ntprinters.tdb file and make the next installation fail from the Samba 3.5.6 server. Next I removed both printers from the Windows 7 client and installed them again while capturing from the server (e.g. "tshark -w s325.pcap host 192.168.0.114"). I'll attach the two capture files in a moment. Now, I think I see what may be causing Windows 7 to bug out as it installs the printer driver. Compare the EnumPrinterDataEx calls in s325.pcap at packets 413-416 with the calls in s356.pcap at packets 604-607. Specifically look at the responses in packets 416 and 607 respectively. The name/value pairs all look good in both packets up until the "printSpooling" key. Here Samba 3.5.6 has an odd number for the name offset and value offset. This confuses the wireshark disector so the name and value strings show up as '......'. I'm guessing Windows 7 doesn't like the odd offset for these unicode strings either. What do you think?
Created attachment 6250 [details] Wireshark capture of driver install to Win 7 from Samba 3.2.5 server Note that the driver installation succeeded in this case
Created attachment 6251 [details] Wireshark capture of driver install to Win 7 from Samba 3.5.6 server Driver installation fails with error 0x0000003e6
Fantastic work. We'll look at this. Thanks a *lot* for your perseverance on this. Jeremy.
Created attachment 6258 [details] Possible patch for 3.5.x. Can you apply the following and completely remake the 3.5.x Samba ? You'll need to start with a completely clean tree as it needs to regenerate all the auto-written IDL parsing files. Jeremy.
Created attachment 6259 [details] Slightly better 3.5.x patch.. This only adds the align calls in the spoolss buffer case, not in all cases.
Great, it works! Tested patch 6259 with Samba 3.5.6. Applied the patch and added "make -C source3 samba3-idl" to the debian/rules file before rebuilding the packages. Was able to add the printer to my Windows 7 client no problems, even after modifying the printer properties. Captured the process and confirmed that all the fields in the EnumPrinterDataEx response are now aligned (looks like to 4-byte boundaries). No other side effects as far as I can tell. Thanks Jeremy!
Comment on attachment 6259 [details] Slightly better 3.5.x patch.. Guenther, Metze - please review for 3.5.next.
Comment on attachment 6259 [details] Slightly better 3.5.x patch.. I'm not sure this is the correct fix, I'll have a look it in the next days.
Just a "me too" to say that the patch seems to fix things. Only a slightly related note - is it possible to upload win 7 drivers to the samba server? I'm not having any luck.
Comment on attachment 6259 [details] Slightly better 3.5.x patch.. I think this is the wrong fix
Ok, I'm fine with it being the wrong fix - but due to reporters commenting it fixes the issue I'd like you to come up with the correct fix and have it tested by reporters before the next 3.5.x ships (March 7th 2011). Otherwise I think we should ship with this fix for that release. Jeremy.
Created attachment 6263 [details] Draft patches for master (need a lot of review) Can you test if this patches also fix the problem (in master)
Comment on attachment 6263 [details] Draft patches for master (need a lot of review) For me I can run ndrdump --validate and produce 100% the same blob as windows.
Hi, I've tried Stefan's patch (backported to 3.5.6) and it didn't work for me. Not sure if that makes any difference, but I don't use W2k8 server but W2K3R2. Thanks, Rob
Created attachment 6267 [details] Rebased patch for 3.5.6 This is the patch I installed on 3.5.6. It appears to allow my win7 computers to access printers on my samba domain controller. I also removed the "make samba3-idl" step from my build. So it seems fine to me.
"make samba3-idl" is very important!
Created attachment 6271 [details] 3.5.6 Patches with generated ndr code (just for testing!) With this patch "make samba3-idl" can be skipped.
(In reply to comment #34) > Hi, > > I've tried Stefan's patch (backported to 3.5.6) and it didn't work for me. Not > sure if that makes any difference, but I don't use W2k8 server but W2K3R2. Are you sure you tested correctly and regenerated the librpc/gen_ndr code? Please retest with the backport test patch I've uploaded and please provide a capture if it doesn't work. Thanks! metze
Initial results with this seem encouraging. I'm going to give it a bit wider deployment and see what comes up.
Metze, the only way your patch will get widespread testing is if it gets pushed to master / v3-6-test. So I've done that :-). Jeremy.
Thanks Metze, all good here. Tested attachment 6271 [details] against 3.5.6~dfsg-3squeeze2 (I still included the make -C source3 samba3-idl build step) and all working well here. Have not done captures and looked at the data alignment, but my add-printer, modify, etc. tests are all working and haven't noticed any other side effects. Cheers, Kevin.
Working well here.
Created attachment 6274 [details] Patch for v3-5 This are the backports from v3-6-test
Comment on attachment 6274 [details] Patch for v3-5 looks good
Karolin, please pick for 3.5.x
Pushed to v3-5-test. Closing out bug report. Thanks!