Adding a raw printer on a samba server from windows 7 64 bit fails with error 0x0000000d. There is no point'n'print driver installed on the server. Win7 32bit works fine on the same setup. The following error is printed in samba's log. [2009/11/11 12:03:47, 3] smbd/error.c:60(error_packet_set) error packet at smbd/ipc.c(132) cmd=37 (SMBtrans) STATUS_BUFFER_OVERFLOW
Created attachment 4940 [details] Log
Created attachment 4941 [details] My smb.conf
64bit windows spoolss clients are currently not supported. Hopefully we can support them with a later version of samba.
I get the same error using Windows 7 64bit. But when I downgrade to samba 3.3.8 it works just fine. Why wouldn't 64bit spools be supported in 3.3 and not supported in 3.4?
Ok, you are absolutely right. Marking this as a blocker. It really is one. Short explanation: The core problem is that the marshalled buffers (containing printer/driver info) in v3-3-test are marshalled in exactly the same way windows marshalls them while marshalling is different in v3-4-test. Longer explanation: Assume the server sends a blob to the client with offered blob size. PIDL currently constructs that blob containing relative pointers like this: [offset1] [offset2] [offset3] [buffer1] [buffer2] [buffer3] [0,0... to fill up total offered blob size]. In order to make 64bits clients work again (as of http://msdn.microsoft.com/en-us/library/cc244870%28PROT.13%29.aspx#id31) PIDL needs to move all marshalled buffers to the *end* of the blob in *reverse* order. [offset1] [offset2] [offset3] [0,0... to fill up total offered blob size] [buffer3] [buffer2] [buffer1] Metze and me were discussing ways to accomplish this and we need to solve this for v3-4-test and v3-5-test.
Sounds good. Has this been committed to the test branches? I really need to get my printers going as soon as possible. I would fall back to 3.3.8, but the developers of the distro I'm using have compiled it against a version of heimdal that breaks other software if heimdal is downgraded. This makes downgrading is a major pain. If you could let me know if this is ready, I'll see if I can find some time to try it out. Thanks (In reply to comment #5) > Ok, you are absolutely right. Marking this as a blocker. It really is one. > > Short explanation: The core problem is that the marshalled buffers (containing > printer/driver info) in v3-3-test are marshalled in exactly the same way > windows marshalls them while marshalling is different in v3-4-test. > > Longer explanation: > > Assume the server sends a blob to the client with offered blob size. > PIDL currently constructs that blob containing relative pointers like this: > [offset1] [offset2] [offset3] [buffer1] [buffer2] [buffer3] [0,0... to fill up > total offered blob size]. > > In order to make 64bits clients work again (as of > http://msdn.microsoft.com/en-us/library/cc244870%28PROT.13%29.aspx#id31) PIDL > needs to move all marshalled buffers to the *end* of the blob in *reverse* > order. > [offset1] [offset2] [offset3] [0,0... to fill up total offered blob size] > [buffer3] [buffer2] [buffer1] > > Metze and me were discussing ways to accomplish this and we need to solve this > for v3-4-test and v3-5-test. >
as it never worked in a 3.4 release this is a blocker for 3.5.0 but not for 3.4.6. Changing version tag accordingly.
Created attachment 5382 [details] Fixes from Günther and Metze (pushed to master)
Comment on attachment 5382 [details] Fixes from Günther and Metze (pushed to master) looks good :)
...but does not apply too v3-5-test... :-( Applying: libndr: add ndr_push_relative_ptr2_start and ndr_push_relative_ptr2_end. error: patch failed: librpc/ndr/libndr.h:385 error: librpc/ndr/libndr.h: patch does not apply Patch failed at 0001 libndr: add ndr_push_relative_ptr2_start and ndr_push_relative_ptr2_end.
Created attachment 5391 [details] patch for 3.5
Created attachment 5392 [details] patch for 3.4
stefan, the memset still to be resolved though. easy reproducer: local rpcclient enumports.
Wow - nice work, but BOY are we going to have to review this before 3.5.0 final :-). Thanks, Jeremy.
Created attachment 5397 [details] patch for 3.4 adds 76aa37f653fec2d511921768381db7da661750cb
Created attachment 5398 [details] patch for 3.5 adds 76aa37f653fec2d511921768381db7da661750cb
Comment on attachment 5397 [details] patch for 3.4 Looks good
Comment on attachment 5398 [details] patch for 3.5 Looks good
Karolin, please pick into the release branches
Pushed to v3-4-test and v3-5-test. Re-assigning to Günther.
Hi, I just tried 3.5.1 and 64 bit windows 7 printing with a variety of drivers (Rico, KonicaMinolta, HP). In the mmc the add driver stuff works fine for both 64 and 32 bit. The driver do not show up in the 'advanced' tab of the printer options though. I can assign them to a printer using 'rpcclient' on the samba box. They are shown than for the individual rpinter as expected and test page prints fine. The KM driver has some additional problems: > "C:\....\mmc.exe > Function adress 0xff38117a caused a protection fault (exception code > 0xc000005) some or all properties pages may not be displayed" > > In the samba logfile I see one error, don't now if it is realted though: > > [2010/03/17 10:57:22.771269, 3] smbd/error.c:76(error_packet_set) > error packet at smbd/trans2.c(4130) cmd=50 (SMBtrans2) > NT_STATUS_INVALID_LEVEL > [2010/03/17 10:57:22.771592, 5] lib/util.c:617(show_msg) > [2010/03/17 10:57:22.771727, 5] lib/util.c:620(show_msg) > size=35 > smb_com=0x32 > smb_rcls=72 > smb_reh=1 > smb_err=49152 > smb_flg=136 > smb_flg2=51203 > smb_tid=1 > smb_pid=1044 > smb_uid=101 > smb_mid=74 > smt_wct=0 > smb_bcc=0 > [2010/03/17 10:57:22.773226, 10] > lib/util_sock.c:726(read_smb_length_return_keepalive) > got smb length of 224 cheers christoph
(In reply to comment #21) > Hi, > > I just tried 3.5.1 and 64 bit windows 7 printing with a variety of drivers > (Rico, KonicaMinolta, HP). In the mmc the add driver stuff works fine for both > 64 and 32 bit. > > The driver do not show up in the 'advanced' tab of the printer options though. The Samba spoolss server currently always advertises itself as 32 bit, this causes Windows clients to only permit association of 32-bit drivers with Samba shared printers. The following procedure can be used to share both 32-bit and 64-bit drivers for point and print functionality: - The 64bit driver must be uploaded using the "//share/printers/ -> server properties" wizard. This wizard allows the uploading of printer drivers that differ in architecture to what is reported by the spoolss server (currently always 32bit in samba). - A 32bit driver with an identical name must also be uploaded to the server and associated with the printer, the regular add printer wizard can be used for this. For further details see the "Using Point and Print with Different Processor Architectures" section in: http://download.microsoft.com/download/5/c/3/5c331f2d-3c1e-40b8-a2ec-0282c047d201/Pointandprint.doc
What's the status of this bug? In release notes for version 3.4.6 is written that this issue was fixed, but now I'm using version 3.5.8 of samba and problem still occurs. When I'm trying to install printer shared by samba on Windows 64-bit workstation it returns error code no 0x000000d8. I know that this error code is different from that one previously posted in this bug report but symptoms are exactly the same. In 32-bit versions of Windows adding printer works fine but adding the same printer on 64-bit Windows 7 or Vista results by getting this error
Günther, David do you think there's more to do here? Or does 32-Bit and 64-Bit drivers can't work at the same time?
adding printer drivers with the same name for a different architecture does not work with 3.5.15. The "HP Universal Print Driver" is a good test candidate available for x32 and x64. Also setting a driver for a printer is only possible for drivers uploaded for x32. As a result of both: If you want to set a x64 driver for a printer you have to do that manually using rpcclient setdriver on the samba server currently.
(In reply to comment #25) > If you want to set a x64 > driver for a printer you have to do that manually using rpcclient setdriver on > the samba server currently. It should be possible from a Windows client using the method in comment 22. I'll run a quick test today against 3.6.3, last time I checked this was working.
as the issues mentioned in the end of this bug and my summary in comment #25 are actually no longer the same thing as the initially reported issue it would make sense to close this bug as fixed and open up a new one, right? printing-maintainers ?
I'm getting the same problem as described by Krzysiek in comment #23, using the latest version of Samba at the moment (3.6.6). Any hints?
Created attachment 7794 [details] Windows x64 Shared printer bug This is the error that comes up when you try to add a printer via share name on a Windows 7 x64 computer.
I'm able to add shared printers on a Windows 7 x86 computer via share name without any issues, but when I try to do it on a Windows 7 x64 computer I get the following error: https://bugzilla.samba.org/attachment.cgi?id=7794 The server is running Ubuntu 12.04 LTS ubuntu@orange:~$ smbd --version Version 3.6.3 ubuntu@orange:~$ nmbd --version Version 3.6.3 This was working fine in Ubuntu 10.04 LTS which ran: Version 3.4.7
Take care of this bug too : "printer driver short architecture dir (w32x86) is not treated case insensitive" https://bugzilla.samba.org/show_bug.cgi?id=6669 To make "HP Universal Print Driver" uploading works for me, I've made symbolic links : root@fagus:/etc/samba/drivers# smbd -V Version 3.6.3 root@fagus:/etc/samba/drivers# ls -l total 28 drwxrwxr-x 2 administrator Domain Admins 4096 juin 24 2008 COLOR drwxrwxr-x 2 administrator Domain Admins 4096 oct. 12 2004 W32ALPHA drwxrwxr-x 2 administrator Domain Admins 4096 oct. 12 2004 W32MIPS drwxrwxr-x 2 administrator Domain Admins 4096 oct. 12 2004 W32PPC lrwxrwxrwx 1 root root 6 août 30 16:03 w32x86 -> W32X86 drwxrwxr-x 4 administrator Domain Admins 4096 août 30 14:04 W32X86 drwxrwxr-x 3 administrator Domain Admins 4096 juil. 21 2005 WIN40 lrwxrwxrwx 1 root root 3 août 30 16:02 x64 -> X64 drwxrwxr-x 4 administrator Domain Admins 4096 août 30 16:03 X64
I report the same on 3.6.6, packaged by Canonical. On Windows x86 clients the installation of the printer occurs normal, but at x64 clients it throws an 0x000000d8 error. There's any quick'n dirty workaround?
(In reply to comment #32) > I report the same on 3.6.6, packaged by Canonical. > > On Windows x86 clients the installation of the printer occurs normal, but at > x64 clients it throws an 0x000000d8 error. > > There's any quick'n dirty workaround? I have same issue. PL
Fixed in 3.6.0 and 4.0.0