Bug 7506 - Cannot print from Windows Server 2008 (x64) Terminal Server to samba-hosted printer
Summary: Cannot print from Windows Server 2008 (x64) Terminal Server to samba-hosted p...
Status: RESOLVED WORKSFORME
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: Printing (show other bugs)
Version: 3.5.3
Hardware: x64 Linux
: P3 normal
Target Milestone: ---
Assignee: Guenther Deschner
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-09 18:03 UTC by Dev Null
Modified: 2021-01-07 22:49 UTC (History)
1 user (show)

See Also:


Attachments
log.smbd (73.73 KB, text/plain)
2010-06-09 18:06 UTC, Dev Null
no flags Details
wireshark packet trace (93.68 KB, application/octet-stream)
2010-06-09 18:07 UTC, Dev Null
no flags Details
output from testparm (2.87 KB, text/plain)
2010-06-09 18:10 UTC, Dev Null
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dev Null 2010-06-09 18:03:17 UTC
I hope that this is a bug and not something which I've misconfigured, but: 1) noone on the Samba list seems to recognise it, and 2) it works from XP but not Server 2008, which seems highly suspicious.

I have a redhat EL5 samba server hosting a collection of printers and
joined to a domain.  I can connect to this server and print happily from
a 32-bit XP box on the domain, but a 64-bit windows server 2008 box
cannot connect, and returns the error: "Windows cannot connect to the printer: Operation could not be completed (error 0x000006d1)."

I get the same results with samba 3.0.33 (came with redhat), 3.5.3 (the
latest from sernet), and 3.3.12 (this message from the samba-technical
archives -
http://lists.samba.org/archive/samba-technical/2010-February/069145.html
- mentions that at least as of February there were issues with 3.4.x+
and 64-bit client OS'.)

From the 2008 machine, I can browse the samba server in wexplorer and
see the printers, but trying to set up a networked printer generates the
error above.  /var/log/samba/log.smb from the time around the failed connection (using 3.3.12 - the last version I tried) contains:

[2010/06/08 11:35:36,  3] smbd/ipc.c:handle_trans(442)
  trans <\PIPE\> data=44 params=0 setup=2
[2010/06/08 11:35:36,  3] smbd/ipc.c:named_pipe(393)
  named pipe command on <> name
[2010/06/08 11:35:36,  4] rpc_server/srv_pipe_hnd.c:get_rpc_pipe(1231)
  search for pipe pnum=71df
[2010/06/08 11:35:36,  3] smbd/ipc.c:api_fd_reply(351)
  Got API command 0x26 on pipe "spoolss" (pnum 71df)
[2010/06/08 11:35:36,  3] rpc_server/srv_pipe_hnd.c:free_pipe_context(500)
  free_pipe_context: destroying talloc pool of size 0
[2010/06/08 11:35:36,  4] rpc_server/srv_pipe.c:api_rpcTNP(2352)
  api_rpcTNP: spoolss op 0x1d - api_rpcTNP: rpc command:
SPOOLSS_CLOSEPRINTER
[2010/06/08 11:35:36,  4]
rpc_server/srv_lsa_hnd.c:find_policy_by_hnd_internal(179)
  Policy not found: [000] 00 00 00 00 18 00 00 00  00 00 00 00 0E 4C 78
8D  ........ .....Lx.
  [010] 28 24 00 00                                       ($..
[2010/06/08 11:35:36,  2]
rpc_server/srv_spoolss_nt.c:find_printer_index_by_hnd(273)
  find_printer_index_by_hnd: Printer handle not found: Policy not found:
[000] 00 00 00 00 18 00 00 00  00 00 00 00 0E 4C 78 8D  ........ \
.....Lx.
  [010] 28 24 00 00                                       ($..
[2010/06/08 11:35:36,  2]
rpc_server/srv_spoolss_nt.c:find_printer_index_by_hnd(273)
  find_printer_index_by_hnd: Printer handle not found:
close_printer_handle: Invalid handle (OURS:9256:9256)
[2010/06/08 11:35:36,  4] rpc_server/srv_pipe.c:api_rpcTNP(2387)
  api_rpcTNP: bad handle fault return.

(I'll add the full log in as an attachment.)

I set up wireshark to do a packet trace of the connection attempt.  I'm
not familiar enough with what the traffic should look like to know whats
unusual, but the one thing that jumped out at me towards the end of the
conversation was a SPOOLSS OpenPrinterEx request on the network printer,
followed by a response with the return code of 5 - Access denied.
"Aha!" I say to myself, must be a permissions problem... but a packet
trace of the successful connection from the XP box shows several similar
Access denied messages.  Maybe that means its irrelevant, but it seemed worth
mentioning - I'll attach a packet trace as well.
Comment 1 Dev Null 2010-06-09 18:06:12 UTC
Created attachment 5785 [details]
log.smbd

log.smbd from the time around a failed connection attempt
Comment 2 Dev Null 2010-06-09 18:07:45 UTC
Created attachment 5786 [details]
wireshark packet trace

Wireshark pcap file for the time around a failed connection.
Comment 3 Dev Null 2010-06-09 18:10:13 UTC
Created attachment 5787 [details]
output from testparm

output from testparm - my smb.conf without all the annoying comments
Comment 4 Dev Null 2010-06-11 11:47:54 UTC
Now this is interesting...

The Server 2008 machine I was using to test this was running Windows server 2008 _Terminal Server_.  (Sorry, should have noticed and mentioned that earlier.)  Tested it today running s Server 2008 x64 _without_ Terminal Server, and it prints fine.  So it sounds like its actually the Terminal Server aspect thats causing the problem.  Since I hadn't noticed this before, I'll do some more digging to see if this is a known problem that I had simply misidentified, and post the results here.
Comment 5 Dev Null 2010-06-11 19:01:15 UTC
Ok, apparently Microsoft completely changed the way printing is done from Terminal Server between 2003 and 2008 - see http://technet.microsoft.com/en-us/library/cc753853%28WS.10%29.aspx for details.  We have found a workaround:

1) On the Windows Server 2008 TS host, bring up the Server Manager.
2) Under Features, install Group Policy Management if it isn't installed already.
3) Under Group Policy Management, drill down til you find the policy which is applying to your machine.
4) Right click the Group Policy Object and select "edit".
5) In the resulting editor window, drill down to Computer Configuration:Policies:Administrative Templates:Printers
6) Find the setting "Always render print jobs on the server" and disable it.
7) reboot the machine.

So its definitely Windows' fault (surprise surprise).  Whether this therefore counts as a bug in samba or not I will leave up to you folks to decide; I am satisfied with my workaround, so you can close this out if you like as far as I'm concerned.
Comment 6 Björn Jacke 2021-01-07 22:49:40 UTC
printing is working as expected in recent samba versions also with modern windows clients