Bug 33505 - Windows clients rename printer during Point'n Print driver upload to server
Windows clients rename printer during Point'n Print driver upload to server
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Samba
UCS 3.0
Other Linux
: P5 normal (vote)
: UCS 3.2-3-errata
Assigned To: Arvid Requate
Felix Botner
:
Depends on:
Blocks: 37123
  Show dependency treegraph
 
Reported: 2013-11-21 13:34 CET by Arvid Requate
Modified: 2014-12-01 12:28 CET (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2013-11-21 13:34:07 CET
Windows clients rename the printer share while uploading Point'n Print drivers to a Samba server.

This is pretty confusing for the Administrator as the usual testpage printing doesn't work in this case and the admin faces the windows error code  0x0000007a instead.

Samba might offer a solution for this, as described in manpage for smb.conf:
==============================================================================
When assigning a new driver to a printer on a remote Windows compatible print server such as Samba, the Windows client will rename the printer to match the driver name just uploaded. This can result in confusion for users when multiple printers are bound to the same driver. To prevent Samba from allowing the printer´s printername to differ from the sharename defined in smb.conf, set force printername = yes.
==============================================================================
Comment 1 Arvid Requate univentionstaff 2014-05-27 20:05:16 CEST
Current status: This issue was raised again recently upstream https://bugzilla.samba.org/show_bug.cgi?id=10482

I tested driver upload with "force printername = yes" from a windows7 client but that consistently triggered this error message already at the point of driver upload.

The advantage is that the server side printer share UNC doesn't get renamed. This is a big plus, because it avoids ending up with a broken printer share after the driver was uploaded. The drawback is this (and possibly another) ugly "false" error message getting raised to the administrator.
Comment 2 Arvid Requate univentionstaff 2014-06-05 14:22:02 CEST
After some testing and research on the net it looks like the error message 0x0000007a is unrelated to the renaming of the printer.

The source of this error message is unidentified yet but it's also reported in native windows domains and technet forums suggest
a) an error during upload of the printer driver to the "print$" share
b) a problem with the print spooler (local or remote?)
c) driver files blocked via C:\Windows\inf\printupg.inf or printupg.pnf

It's true that I could reproduce the problems (yet not always) with the HP Universal PS driver which contains a file "pscript5.dll" which is listed in the printupg.inf file on my Windows 7 client. The problem didn't show (yet) with the Universal PCL6 driver. I would dare to bet that this is not a Samba problem.

Specifically the error code 0x0000007a does *not* seem to correlate to any of the protocol inherent WERR_INSUFFICIENT_BUFFER messages in the log.smbd. From the Microsoft provided protocol specification these seem to be regular messages occurring during response buffersize negotiations between client and server.


Finally note that only the "printername" is changed by the client-sent spoolss_SetPrinter command, but the "sharename" and "uncpath" are unmodified:

Before:
 printername: //master40/printer9
 sharename: printer9

After the client assigned "Driver XYZ":
 printername: //master40/Driver XYZ
 sharename: printer9
Comment 3 Arvid Requate univentionstaff 2014-06-05 14:25:59 CEST
I recommend adjusting the cups-printers.py listener module to set

 force printername = yes

on all (added or modified) printer shares. The default for this should be configurable via UCR.
Comment 4 Arvid Requate univentionstaff 2014-09-08 12:37:49 CEST
Fixed, Advisory: 2014-09-08-univention-printserver.yaml
Comment 5 Felix Botner univentionstaff 2014-09-09 13:42:54 CEST
OK - 3.2-3
OK - 4.0-0
OK - YAML
Comment 6 Arvid Requate univentionstaff 2014-09-09 15:12:18 CEST
I guess it's better to make the default configurable. Now there is a UCR variable samba/force_printername , which may be set to no/false in case the new default doesn't work for somebody. Advisory adjusted to mention new UCR variable.
Comment 7 Felix Botner univentionstaff 2014-09-09 15:44:53 CEST
OK
Comment 8 Janek Walkenhorst univentionstaff 2014-09-10 17:44:44 CEST
http://errata.univention.de/ucs/3.2/202.html