Bug 7567 - printing from Windows 7 fails with 0x000003e6 (in AD w2k8r2 controlled domain)
Summary: printing from Windows 7 fails with 0x000003e6 (in AD w2k8r2 controlled domain)
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: Printing (show other bugs)
Version: 3.5.4
Hardware: x64 Linux
: P3 normal
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Reported: 2010-07-13 14:58 UTC by Matt L
Modified: 2011-03-02 14:26 UTC (History)
6 users (show)

See Also:

ntdrivers.tdb after removal and cupsaddsmb -a (96.00 KB, application/octet-stream)
2011-01-27 04:12 UTC, Kevin Shanahan (dead mail address)
no flags Details
ntprinters.tdb after removal and cupsaddsmb -a (68.00 KB, application/octet-stream)
2011-01-27 04:13 UTC, Kevin Shanahan (dead mail address)
no flags Details
ntprinters.tdb after modifying defaul paper size (68.00 KB, application/octet-stream)
2011-01-27 04:13 UTC, Kevin Shanahan (dead mail address)
no flags Details
Wireshark capture of driver install to Win 7 from Samba 3.2.5 server (331.60 KB, application/cap)
2011-02-16 10:32 UTC, Kevin Shanahan (dead mail address)
no flags Details
Wireshark capture of driver install to Win 7 from Samba 3.5.6 server (375.35 KB, application/cap)
2011-02-16 10:33 UTC, Kevin Shanahan (dead mail address)
no flags Details
Possible patch for 3.5.x. (926 bytes, patch)
2011-02-17 17:20 UTC, Jeremy Allison
no flags Details
Slightly better 3.5.x patch.. (987 bytes, patch)
2011-02-17 18:02 UTC, Jeremy Allison
metze: review-
Draft patches for master (need a lot of review) (10.83 KB, patch)
2011-02-22 12:42 UTC, Stefan Metzmacher
no flags Details
Rebased patch for 3.5.6 (6.61 KB, patch)
2011-02-23 10:28 UTC, Orion Poplawski
no flags Details
3.5.6 Patches with generated ndr code (just for testing!) (292.49 KB, patch)
2011-02-25 07:02 UTC, Stefan Metzmacher
no flags Details
Patch for v3-5 (306.05 KB, patch)
2011-03-02 03:54 UTC, Stefan Metzmacher
gd: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Matt L 2010-07-13 14:58:26 UTC
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)
[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)
[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.
Comment 1 Guenther Deschner 2010-07-13 15:28:41 UTC
Is this a standalone win7 box or are you member of a domain ?
Comment 2 Matt L 2010-07-13 15:31:11 UTC
Domain joined.
Comment 3 Guenther Deschner 2010-07-13 15:45:52 UTC
(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.

Comment 4 Matt L 2010-07-13 15:55:28 UTC
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?
Comment 5 Matt L 2010-07-13 16:34:08 UTC
I should also add that this appears to be a regression since 3.3.10.
Comment 6 Guenther Deschner 2010-07-15 08:23:13 UTC
Can you try setting "Always render print jobs on the server" explicitly to "disable" ?
Comment 7 Matt L 2010-07-15 14:28:33 UTC
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.
Comment 8 Jeremy Allison 2010-07-15 14:45:43 UTC
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.

Comment 9 Matt L 2010-07-15 17:27:55 UTC
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.
Comment 10 Matt L 2010-08-05 13:47:42 UTC
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.
Comment 11 Stijn Hoop 2010-09-29 05:07:26 UTC
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?
Comment 12 Matt Stucky 2010-11-10 12:28:40 UTC
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?

Comment 13 Matt Stucky 2010-11-10 13:57:24 UTC
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.
Comment 14 Kalani Sanders 2011-01-13 09:21:01 UTC
Matt's fix above (#13) has worked for us, at least for the last month.  
Comment 15 Kevin Shanahan (dead mail address) 2011-01-27 04:09:38 UTC
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 $?
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.
Comment 16 Kevin Shanahan (dead mail address) 2011-01-27 04:12:23 UTC
Created attachment 6229 [details]
ntdrivers.tdb after removal and cupsaddsmb -a
Comment 17 Kevin Shanahan (dead mail address) 2011-01-27 04:13:01 UTC
Created attachment 6230 [details]
ntprinters.tdb after removal and cupsaddsmb -a
Comment 18 Kevin Shanahan (dead mail address) 2011-01-27 04:13:36 UTC
Created attachment 6231 [details]
ntprinters.tdb after modifying defaul paper size
Comment 19 Kevin Shanahan (dead mail address) 2011-02-06 18:36:16 UTC
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.
Comment 20 Kevin Shanahan (dead mail address) 2011-02-16 10:30:43 UTC
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"). 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?
Comment 21 Kevin Shanahan (dead mail address) 2011-02-16 10:32:48 UTC
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
Comment 22 Kevin Shanahan (dead mail address) 2011-02-16 10:33:49 UTC
Created attachment 6251 [details]
Wireshark capture of driver install to Win 7 from Samba 3.5.6 server

Driver installation fails with error 0x0000003e6
Comment 23 Jeremy Allison 2011-02-16 11:21:56 UTC
Fantastic work. We'll look at this. Thanks a *lot* for your perseverance on this.
Comment 24 Jeremy Allison 2011-02-17 17:20:26 UTC
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.

Comment 25 Jeremy Allison 2011-02-17 18:02:20 UTC
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.
Comment 26 Kevin Shanahan (dead mail address) 2011-02-18 05:50:32 UTC
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 27 Jeremy Allison 2011-02-18 11:12:53 UTC
Comment on attachment 6259 [details]
Slightly better 3.5.x patch..

Guenther, Metze - please review for 3.5.next.
Comment 28 Stefan Metzmacher 2011-02-20 14:49:56 UTC
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.
Comment 29 Orion Poplawski 2011-02-21 17:43:47 UTC
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 30 Stefan Metzmacher 2011-02-22 12:40:21 UTC
Comment on attachment 6259 [details]
Slightly better 3.5.x patch..

I think this is the wrong fix
Comment 31 Jeremy Allison 2011-02-22 12:42:54 UTC
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.

Comment 32 Stefan Metzmacher 2011-02-22 12:42:59 UTC
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 33 Stefan Metzmacher 2011-02-22 12:44:05 UTC
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.
Comment 34 Robert Piasek (dead mail address) 2011-02-23 08:13:01 UTC

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.

Comment 35 Orion Poplawski 2011-02-23 10:28:54 UTC
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.
Comment 36 Stefan Metzmacher 2011-02-25 07:00:16 UTC
"make samba3-idl" is very important!
Comment 37 Stefan Metzmacher 2011-02-25 07:02:53 UTC
Created attachment 6271 [details]
3.5.6 Patches with generated ndr code (just for testing!)

With this patch "make samba3-idl" can be skipped.
Comment 38 Stefan Metzmacher 2011-02-25 07:46:14 UTC
(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.

Comment 39 Matt L 2011-02-25 15:10:34 UTC
Initial results with this seem encouraging.  I'm going to give it a bit wider deployment and see what comes up.
Comment 40 Jeremy Allison 2011-02-28 18:56:15 UTC
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 :-).

Comment 41 Kevin Shanahan (dead mail address) 2011-03-01 06:54:07 UTC
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.

Comment 42 Orion Poplawski 2011-03-01 10:08:31 UTC
Working well here.
Comment 43 Stefan Metzmacher 2011-03-02 03:54:41 UTC
Created attachment 6274 [details]
Patch for v3-5

This are the backports from v3-6-test
Comment 44 Guenther Deschner 2011-03-02 08:07:05 UTC
Comment on attachment 6274 [details]
Patch for v3-5

looks good
Comment 45 Guenther Deschner 2011-03-02 08:07:43 UTC
Karolin, please pick for 3.5.x
Comment 46 Karolin Seeger 2011-03-02 14:26:16 UTC
Pushed to v3-5-test.
Closing out bug report.