Univention Bugzilla – Bug 35846
Error on printer driver assignment (error 0x0000007a)
Last modified: 2020-07-03 20:55:58 CEST
With a UCS 3.2-3 printserver with samba4 (i guess with samba3 too) i get a 0x0000007a error after assigning a driver to a printer via win7. Printer settings could not be saved. Operation could not be completed (error 0x0000007a). https://bugzilla.samba.org/show_bug.cgi?id=10482
We should check if this a) works with samba3 b) worked in a previous version of samba3
This has been seen again in UCS 4.0 PT. Samba4/Windows7 x64/Serverside Printer Driver (Univenersal HP PS). Samba printer share had been loaded properly (i.e. afgter fixing Bug 36578) with the option "force printername = yes". Despite the error message the driver seems to be assigned correctly and printing a test page was successfull.
reported again by 2014112721000202
reported again with detailed guidance by 2015010921000254
> reported again with detailed guidance by 2015010921000254 No, error 0x0000001f != 0x0000007a. I created Bug 37864 for that.
reported again http://forum.univention.de/viewtopic.php?f=48&t=3818&hilit=0x0000007a
Note: Samba spoolss is an implementation of [MS-RPRN] ( https://msdn.microsoft.com/en-us/library/cc244528.aspx , see also the print protocol overview https://msdn.microsoft.com/en-us/library/hh441794.aspx ).
tl;dr: It only happens the second time a driver gets assigned. =============================================================================== Steps to reproduce the problem: 1. On the Samba Server set "spoolss: architecture = Windows x64" in smb.conf and create two CUPS-backed printer queues (not strictly required, but since I was testing with a x64 Windows client this simplifies driver upload). 2. On an x64 Windows Client unpack the native Windows printer example driver upd-pcl6-x64-5.5.0.12834.exe (HP Universal). In the WinZip dialog deselect "When done unzipping open: .\install.exe" > unzip. 3. Open printmanagement.msc Connect to Samba DC hosting the printer share (print server > right click > Add server > ...) 4. Click on the "drivers" node below the Samba DC node, right click -> "Add driver" > continue > habe x64 selected (only) > continue > have disc > Navigate to the unpacked HP Universal Printer driver > Select hppscnd (e.g.) > open > ok > Select PCL 6 > continue > finish => The driver files ge uploaded to the Samba Server \\dcname\print$\x64, No error, Upload dialog closes automatically. 5. In printmanagement.msc click on the printers node below the Samba DC node. Right click on the first printer share > properties > Popup appears "The printer driver "" is not installed. [...]. Do you want to install the driver now?" > No (fails anyway in my experiments) > printer properties window opens > click on tab > advanced > Driver dropdown appears empty > click on it > select "HP Universal Printing PCL 6" > click Ok > Dialog "Do you trust this driver?" opens, click on "Install driver" > Driver files are downloaded from the Server > No error, Dialog closes automatically. 6. In printmanagement.msc click on the printers node below the Samba DC node. Right click on the second printer share > properties > Popup appears "The printer driver "" is not installed. [...]. Do you want to install the driver now?" > No (fails anyway in my experiments) > printer properties window opens > click on tab > advanced > Driver dropdown appears empty > click on it > select "HP Universal Printing PCL 6" > click Ok > Error 0x0000007a > Ok 7. In printmanagement.msc right click on printer queue #2 > delete. this causes the printer driver to become disassociated from the printer queue. This can be seen with remote regedit > File > Connect to network registry > Enter name of Samba DC > possibly supply domain administrator credentials, navigate to Samba DC Name> HKLM > Software > Microsoft > Windows NT > CurrentVersion > Print > Printers > Name of printer queue. Deleting the driver in printmanagement.msc causes some registry values do be deleted there, e.g. the value "Printer Driver". Note: Deleting the printer queue in printmanagement.msc will not remove the share and the printer name still is shown in the Windows printer management tool. 8. Repeat step 6 => error 0x0000007a is reproducable this way. (Note: Instead of step 7, in my setup it seemed to be enough to remove the Registry value "Printer Driver" from the Samba DC registry key associated with the printer share.) =============================================================================== Debugging this is pretty much like searching a needle in a haystack: A cut from the log.smbd taken at debug level "12 ldb:1" in step 6 in the relatively short time window from just before clicking ok to getting the error message shows about 100 RPC calls. To the uninitiated it looks like a lot of redundancy: there are a lot of SPOOLSS_OPENPRINTEREX and SPOOLSS_CLOSEPRINTER calls, not necessarily occurring in pairs. I also enabled Windows client side event viewer debugging for the printer spool but it didn't show any errors in that time window, only success messsages. So currently the only check left on the TODO list is to check if: > * worked in a previous version of samba3 Since the earliest known report for this at Univention is Ticket#2013022121001026 (UCS 3.1-0 or earlier, beat the guy that didn't report the exact version). So we might want to test this again e.g. with UCS 3.0-2 samba3.
Same error with UCS 3.0-2 Samba 2:3.5.11~dfsg-10.532.201207162212 , tested with Windows 7 x64 against i386 server (dual driver arch uploaded). Note that currently there are no known problems connected with this error message (see e.g. http://forum.univention.de/viewtopic.php?f=48&t=3818&p=15450 for an example where this was not the real issue). So, no clue currently how to proceed here. Waiting for upstream input or other ideas for debugging this (like installing Windows debug symbols and running WinDbg or something, google: Debugging Spooler Components).
This might also be something client side: Testing with UCS 2.3-0 Samba 3.3.9 I used the same Windows client that still had the drivers. This time the error message occurred directly at the first driver assignment. The error seems to occur if the driver which gets assigned is already present in C:\Windows\System32\spool\drivers\3 . When I disassociate the driver from the printer share (by right-click-"removing" the printer share in printmanagement.msc, see above) and then rename/remove that directory I can reset the state in such a way that the next time i assign the driver to the printer Windows asks me again if I want to download the driver. When I hit ok, no error popup appears.
Reset target milestone since the bug status is set to NEEDMOREINFO.
Just a wild idea: Maybe the procedure of Bug 37148#c11 would help: =========================================================================== To give the Windows printer driver the opportunity to save correct standard settings for the printer, you now need to switch to the Device settings tab. The name of the tab differs from manufacturer to manufacturer and may also be Settings or even just Configuration. Clicking on OK closes the window. You can then print a test page. If Windows displays an error message here 0x00000006, the printer settings must be checked again to see whether there is a manufacturer-specific tab called Device settings (or something similar). If so, it should be opened and then simply confirmed with OK. This closes the dialogue window and saves the printer drivers settings (PrinterDriverData)in the Samba registry. =========================================================================== from http://docs.software-univention.de/manual-4.0.html#print-services:winclients
Ignore Comment 12, I just tested it, this doesn't change anything.
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4. If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
Just a follow up on this: Bug 43252 Comment 4 suggests, that this error message might be specific to non-package-aware drivers.
This issue has been filed against UCS 4.2. UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.