Univention Bugzilla – Bug 38172
Some printer drivers cannot be uploaded
Last modified: 2020-12-15 16:14:39 CET
There are still some printer drivers that can't be uploaded to samba print servers. For example all windows 7 PCL 5 drivers for kyocera p2x series: http://www.kyoceradocumentsolutions.de/index/serviceworld/downloadcenter.false.driver.ECOSYSP2135DN._.DE.html As well as some brother series I don't remember. When selecting the driver for upload (32 or 64bit Windows 7; 32 or 64bit "spool server", does not matter) the client always complains that: "The folder you specified doesn't contain a compatible software driver for your device. If the folder contains a driver, make sure it is designed to work with Windows for 32-bit systems." (on 64-bit systems the given architecture is different of cause). The same driver can be installed via the workaround described in http://sdb.univention.de/1309
I tried it with some of the Kyocera drivers, and at my first attempt at some point it asks for ntprint.inf which cannot be found. Just googling for ntprint.inf shows that this is a common problem with some printer drivers, see e.g. the first match: http://blogs.technet.com/b/core/archive/2012/06/05/print-installation-von-x86-druckertreiber-auf-64-bit-betriebssysteme.aspx That said, I tried quite a couple of the tricks suggested there and faild miserably. I tried different ways of uploading a driver and faild in other, yet unseen ways. When testing this again I would strongly suggest to first check that this works with a x86-only setup to see if the driver has a problem. I.e. UCS Server with "samba/spoolss/architecture: Windows NT x86" and a 32bit Windows client. If this doesn't work, cross-architecture stuff cannot either. If x86 works, than the workaround described the URL above should be attempted. Anyway, I guess it's a documentation issue currently.
The Problem still exists in UCS 4.3 @ school. The parsing of the Driver ini throws an error because it doesn´t expect Version Numbers. The Driver can be manipulated to be accepted by Samba, but the digital signature gets lost in this process, which is a huge Problem with Windows 10. I documented Driver Manipulation in my Blog https://paedmllinux.blogspot.com/2017/12/druckertreiber-fur-die-serververteilung.html [Manufacturer] Kyocera=Kyocera,NTx86.6.0,NTamd64.6.0 must currently be changed to: [Manufacturer] Kyocera=Kyocera,NTx86,NTamd64 and [Kyocera.NTx86.6.0] to [Kyocera.NTx86] and [Kyocera.NTamd64.6.0] to [Kyocera.NTamd64] If Samba would be able to accept the Phrase "NTamd64.6.0" in Addition to "NTamd64" the Problem with these Printers would be solved.
To clarify: I have UCS@school 4.3 in the paedML Linux 7.1 Version. The Problem should IMO be assigned to Samba, not UCS manual.
Thanks for the report. With that information we may be able to fix it in Samba and not only document the workaround.
I can confirm: - Reproducable with -- Kyocera ECOSYS P2040dn -- UCS 4.3-3 -- Kyocera Universal Driver PCL6 With the workaround in comment #2, we were able to upload the driver to the print server.
see also ticket 2017121921000372 for a similar problem
FYI: With the Kyocera Classic Universaldriver PCL6 (DriverVer 3.30.0120) we additionally ran into Bug 41852 while debugging this. That was another source of confusion.
Ok, we did not find a way to make this work. Tested against Samba 4.10.2 (DC Master as well as Memberserver). We fould one thing though: We were able to upload the Kyocera driver without removing the ".5.1" etc. version numbers in the inf file by modifying something else in the inf file: The inf file had "PackageAware=TRUE" in "[PrinterPackageInstallation.amd64]" section. When we removed that section, the driver upload worked without error message. We did not neet to adjust spoolss:os_version or anything serverside. Reaching this point I remembered discussing https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Print_Server#Enabling_the_spoolssd_Service with a customer. Unfortunately that didn't work. Note: I tested that on the UCS Memberserver because the smb.conf parameters that need to be adjusted for that may get ignored in a Samba/AD DC (I guess, from reading the samba source code). I added a comment to https://bugzilla.samba.org/show_bug.cgi?id=12763 about this.
Hit another customer with a "Triumph Adler 4006ci" printer today, which seems to be a branded white label product of Kyocera (or Utax?). I used the workaround in comment #2 which seemed to work. Wasn't aware of the possibility mentioned in comment #8.
A nice person made the changes in Comment 2 and let Microsoft recertify the Kyocera Classic Universal Driver. It can be downloaded here: https://downloads.van-belle.nl/samba4/Kyocera/KyoClassicUniversalPCL5_v3.0_Samba_WHQL.zip I have no affiliation with the creator, but I thought the link it might help some people.
Awesome, thanks for the news update!
Same problem with a TASKalfa 520i We modified the .inf file as recommended in comment 8 and the driver was uploadable, with Win7 and Win10. "needmoreinfo" is flagged, which information are needed?
(In reply to Christina Scheinig from comment #16) > "needmoreinfo" is flagged, which information are needed? also don't see open questions, set to "NEW"
Documented that issue on help: https://help.univention.com/t/problem-printer-driver-upload-via-windows-client-failes-with-error-in-application/13134
I checked the suggested solution with the driver: https://www.kyoceradocumentsolutions.ch/de/index/service_support/download_center.false.driver.ECOSYSP6230CDN._.DE.html --> KXPSDrv_2.2.101...SKalfa351ci.zip I was not able to upload the Driver in the original state and I was not able to upload it with the removal of the "PackageAware=TRUE" Section. Trying to add the Driver the "Druckerverwaltung" said in both cases: "Im angegebenen Ordner befindet sich kein kompatibler Softwaretreiber für das Gerät. Falls der Ordner einen Treiber enthält, stellen Sie sicher, dass dieser für "Windows für x64-basierte Systeme" bestimmt ist." When doing the Changes I suggested in Comment 2 the upload works with the loss of the "digitale Signatur" which renders the Driver mostly useless because a Printer-Installation via GPO won´t download manipulated drivers. (The "Vertrauen Sie diesem Drucker" Dialog doesn´t show when installing Printers via GPO.
Additional Info for Comment 19: The Driver Upload was tested in the Druckverwaltung of Windows 10 1903 and Windows 7 Build 7601. The Server is a paedML Linux 7.1 UCS@school 4.3-3-errata520 The Upload of the Driver mentioned to a Windows Printserver works perfectly fine.
Created attachment 10193 [details] Bug38172-Kyocera-TASKalfa-351ci-KX-XPS-Typ-3-Windows7.tar.bz2 Thanks for your comment. I just did another experiment with the driver you mentioned and found that I could at least convince the Windows Client to accept the x64 driver without adjusting Kyocera.NTamd64.6.0" to "Kyocera.NTamd64" by raising the value of the server side smb.conf parameter "spoolss: os_major": ====================================================================== echo -e '\n[global]\n\tspoolss: os_major = 6' >> /etc/samba/local.conf ucr commit /etc/samba/smb.conf /etc/init.d/samba restart ====================================================================== Unfortunately that only solves this part of the issue in my test. Still, after copying a bunch of files the driver upload finally failed with two sequential error popups. The first one said: "Ein Treiber Kyocera TASKalfa 351ci KX (XPS), Typ 3 - Benutzermodus, x64 konnte nicht installiert werden. Dieser Vorgang wird nicht unterstützt." and after confirming the popup the second obe appears with this detail: "Fehler beim Hinzufügen des Treibers. Der Vorgang konnte nicht abgeschlossen werden (Fehler 0x00000578).". That error code doesn't seem to lead to much, but the event viewer shows an HResult error coe of 0x80070032, which, according to [MS-ERREF] is ERROR_NOT_SUPPORTED. That 0x00000578 error code is pretty general for Windows, but for Samba specifically I found https://bugzilla.samba.org/buglist.cgi?quicksearch=0x00000578 , but I'm unsure if that issue is the same as the one we are looking at here. The attached archive contains level 10 samba logs and network traces of two upload attempts.
Ok, I also receive the 0x00000578 error when trying to upload the classic standard HP Universal Print Driver, if I have spoolss:os_major = 6. If I unset that again, I can upload the HP Universal Print Driver normally. So there's some quirk related to that but I think that should not distract us here from the core issue: The core issue seems to be, that the Kyocera TASKalfa 351ci KX XPS Type 3 driver is a strictly "package aware" thing. The oemsetup.inf file declares a dependency on the core driver (see https://docs.microsoft.com/en-us/windows-hardware/drivers/print/package-aware-print-drivers-that-share-files ), see also slides 9-15, 33 and 34 of https://sambaxp.org/archive-data-samba/SambaXP2017-SLIDES/Day2/Track1/New%20printing%20protocols%20in%20Samba%20-%20G%FCnther%20Deschner.pdf about this. ============================================================== [PrinterPackageInstallation.amd64] PackageAware=TRUE CoreDriverDependencies={D20EA372-DD35-4950-9ED8-A6335AFE79F5} ============================================================== So, in clear text: I guess the driver requires some core core drivers which microsoft ships with Windows but doesn't make available separately for distribution. Günther Deschners presentation above explains the whole topic a bit ( at about minute 9 in the audio here: https://sambaxp.org/archive-data-samba/SambaXP2017-AUDIO/Day2/Track1/New%20Printing%20Protocols%20in%20Samba.mp3 ). Btw, it looks like currently there is some upstream activity regarding the implementation of the MS-PAR protocol, which seems to be required required to support these types of drivers (see slide 12 of Günther Deschners presentation): https://git.samba.org/?p=gd/samba/.git;a=shortlog;h=refs/heads/master-par-ok
Please also note that the behaviour is very specific for each driver. E.g. the "Classic Universal Treiber KPDL / PCL5e/c / PCL6" offered by Kyocera (e.g. here: https://www.kyoceradocumentsolutions.de/index/serviceworld/downloadcenter.false.driver.ECOSYSP2135DN._.DE.html# ) can be uploaded by following the procedure described here: https://help.univention.com/t/problem-printer-driver-upload-via-windows-client-failes-with-error-in-application/13134 but I could not get that trick to work with the "Kyocera TASKalfa 351ci KX XPS Type 3 driver". I guess because that one additionally has the "NTamd64.6.0" problem.
Ok I found some insight and a workaround for the "Kyocera TASKalfa 351ci KX XPS Type 3 driver" from Comment 19: I made another attempt to upload the driver by doing two modifications to that drivers oemsetup.inf file: 1) Follow the workaround described in Comment 2 (instead of the server side adjustment of spoolss:os_major) 2) Follow the workaround described in Comment 18 If I do that, the driver upload starts but aborts after a couple of files with the error code 0x0000023f. According to Bug 32771 Comment 3, that corresponds to WERR_APP_INIT_FAILURE and is returned also by native Windows servers if a file referenced in the drivers inf file is missing. Now, which file is it? Fortunately log.smbd tells us: ============================================================================ [2019/10/02 17:25:15.446075, 0, pid=5866] ../../source3/printing/nt_printing.c:1462(move_driver_file_to_download_area) move_driver_file_to_download_area: Unable to rename [x64/{17C88AC7-BAB9-4FD5-BC61-794D2731290D}/mxdwdrv.dll] to [x64/3/mxdwdrv.dll]: NT_STATUS_OBJECT_NAME_NOT_FOUND [2019/10/02 17:25:15.446196, 0, pid=5866] ../../source3/rpc_server/spoolss/srv_spoolss_nt.c:8621(_spoolss_AddPrinterDriverEx) _spoolss_AddPrinterDriverEx: move_driver_to_download_area failed - WERR_APP_INIT_FAILURE ============================================================================ Brilliant, the oemsetup.inf references this file in the "DriverFile" directives in several sections. Apparently that file is expected to be present on the destination server (I only found the https://docs.microsoft.com/en-us/windows-hardware/drivers/print/v4-driver-manifest for this, but it looks like this is also true for v3 type printer drivers). I guess it's one of those coredrivers that are expected to be present on the target server. I guess, when Samba has implemented MS-PAR, they are expected to be found in /var/lib/samba/DriverStore/FileRepository/ on the Samba server, but currently that doesn't help. On Windows systems I can find the file in C:\Windows\System32\spool\drivers\x64\3 as well as in subdirectories of C:\Windows\System32\DriverStore\FileRepository. So, in addition to the workarounds 1) and 2) I did a third adjustment to the oemsetup.inf file: 3) add "mxdwdrv.dll" to the [corefiles] section. After that the client was able to upload the driver and after that I find the file as /var/lib/samba/drivers/x64/3/mxdwdrv.dll on my UCS 4.4-2 Samba/AD DC.
From going over this issue I recognize that not all printer driver uploads are affected. I therefore changed the issue title.
Based on the ongoing analysis I don't expect a generic solution for Windows printer drivers on Samba printer servers in the near future. We should compare with "driverless" solutions like https://wiki.debian.org/CUPSDriverlessPrinting
Again a support ticket caused by this. Error message: spoolss_AddPrinterDriverEx: move_driver_to_download_area failed - WERR_APP_INIT_FAILURE
Have an other ticket with a Kyocera driver, will test the workarounds from here and report.
(In reply to Christina Scheinig from comment #29) > Have an other ticket with a Kyocera driver, will test the workarounds from > here and report. We could fix the Issue with the solution from comment2 and this article https://help.univention.com/t/problem-printer-driver-upload-via-windows-client-fails-with-error-in-application/13134
We will focus on driverless printing as described at Bug 51681, because I don't see a solution for the upload of drivers that require to run code on a Microsoft Windows system. I close this issue with WONTFIX.