Understanding the export printer driver feature

[Kurt Pfeifle]

Chris Howells wrote:

> Hi,
> 
> On Saturday 25 January 2003 22:58, Kurt Pfeifle wrote:
> 
> <snip because it's long>
> 
> Thanks Michael and Kurt, that was an excellent explanation. Hrm, it really
> needs to go onto the web site some time... will see what I can do.
> 
> In the end, I just ended up using cupsaddsmb -- unfortunately it doesn't seem
> to want to work (the rpcclient bit fails):
> 
> su-2.05b# cupsaddsmb -v -U root hpdj3820
> Password for root required to access localhost via SAMBA:
> Running command: smbclient //localhost/print\$ -N -U'root%root' -c 'mkdir
> W32X86;put /var/spool/cups/tmp/3e31d101ccf7e W32X86/hpdj3820.PPD;put
> /usr/local/share/cups/drivers/ADOBEPS5.DLL W32X86/ADOBEPS5.DLL;put
> /usr/local/share/cups/drivers/ADOBEPSU.DLL W32X86/ADOBEPSU.DLL;put
> /usr/local/share/cups/drivers/ADOBEPSU.HLP W32X86/ADOBEPSU.HLP'
> added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0
> Domain=[MIDDLEEARTH] OS=[Unix] Server=[Samba 2.2.7a]
> NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86
> putting file /var/spool/cups/tmp/3e31d101ccf7e as \W32X86/hpdj3820.PPD (224.6
> kb/s) (average 224.6 kb/s)
> putting file /usr/local/share/cups/drivers/ADOBEPS5.DLL as
> \W32X86/ADOBEPS5.DLL (2031.2 kb/s) (average 1411.1 kb/s)
> putting file /usr/local/share/cups/drivers/ADOBEPSU.DLL as
> \W32X86/ADOBEPSU.DLL (1540.7 kb/s) (average 1437.5 kb/s)
> putting file /usr/local/share/cups/drivers/ADOBEPSU.HLP as
> \W32X86/ADOBEPSU.HLP (367.7 kb/s) (average 1326.0 kb/s)
> 
> <snip>
> 
> Running command: rpcclient localhost -N -U'root%root' -c 'adddriver "Windows
> NT x86"
> "hpdj3820:ADOBEPS5.DLL:hpdj3820.PPD:ADOBEPSU.DLL:ADOBEPSU.HLP:NULL:RAW:NULL"'
> cmd = adddriver "Windows NT x86"
> "hpdj3820:ADOBEPS5.DLL:hpdj3820.PPD:ADOBEPSU.DLL:ADOBEPSU.HLP:NULL:RAW:NULL"
> result was NT_STATUS_UNSUCCESSFUL
> 
> Running command: rpcclient localhost -N -U'root%root' -c 'adddriver "Windows
> 4.0"
> "hpdj3820:ADOBEPS4.DRV:hpdj3820.PPD:NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"'
> cmd = adddriver "Windows 4.0"
> "hpdj3820:ADOBEPS4.DRV:hpdj3820.PPD:NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"
> result was NT_STATUS_UNSUCCESSFUL
> 
> Running command: rpcclient localhost -N -U'root%root' -c 'setdriver hpdj3820
> hpdj3820'
> cmd = setdriver hpdj3820 hpdj3820
> Succesfully set hpdj3820 to driver hpdj3820.
> 
> 
> Running the rpcclient command on its own also fails. I noticed this in the 
> samba log files:
> 
> [2003/01/25 00:00:21, 0] 
> printing/nt_printing.c:move_driver_to_download_area(1426)
>   move_driver_to_download_area: Unable to connect

The "download area" is the "print$" share of the Samba server (or, any NT print
server). Win clients are hardcoded to retrieve printer drivers from a share
named "print$". It *must* appear in the smb.conf with a [print$] heading,
and the "path" defined in there *must* exist on Unix.

But that's not enough:

  * "smbclient" should be able to create subdirectories underneath that "print$"
    share, which are named "W32X86" and "WIN40". [From your quoted output I can
    see this didn't fail in your case].

  * Moreover, then "rpcclient" should be able to create subdirectories "0" and
    "2" in "WIN40", respectively "W32X86". [This isn't directly indicated by the
    "cupsaddsmb" or "rpcclient" output...]

  * Finally, "rpcclient" should also "initialize" the drivers for the clients
    to use, by setting a so-called "device mode".[A real NT print server is able
    to execute the driver locally to set the device mode. A Samba server can
    *not* execute Windows binaries and therefor needs to resort to some other
    means...  but this leads away from the topic we need to deal here.]


--> "WIN40" and WIN40/0" is used by 'WIN40' clients (which are Win9x/ME).

--> "W32X86" and "W32X86/3" is normally used by MS type W32X86 (which are
     NT/2K/XP); the W32X86 clients fall back to "WINX86/2" if "WINX86/3" is not
     there. (The latter *isn't* created by Samba's method -- Samba relies on the
     "fall back to '2'"-mechanism.)

The creation of the "0" and "2" subdirs and the moving of the driver file into
these is achieved by the "rpcclient adddriver" command; the initializition
(setting the so-called "device mode") is done by the "rpcclient setdriver"
command.


Items to check:
---------------
  * Can you check if the "0" and "2" subdirs are created?

  * Are they accessible?

  * What are the access rights?

  * What are the access rights for their parent dirs ("<print$>",
    "<print$>/W32X86", "<print$>/WIN40") ?  (You could do "smbclient
    //localhost/print\$ -U root%root" and see if you get the "smb: \>" prompt; if
    yes, try to see what's in and if you can move there: "dir" ; "cd 2"; "dir".

  * What do you see as the respective content of the subdirs?

  * Is it really true that there is nothing there in the "download area"? )


Things to try:
--------------
You could try and start with a *clean* Samba environment. To cleanse that
environment for the purpose....

   ...delete all existing files and subdirs underneath [print$], and

   ...delete all *.tdb files created by Samba (possibly in "/var/lib/samba/",
      "/var/lock/samba/", "/var/cache/samba/", "/usr/var/lib/samba/", or
      "/usr/var/cache/samba/" or "/usr/var/lock/samba/", depending on your
      distro...

and restart Samba. (NOTE, that all user auth info might be lost -- if you
need it back up the files first, or just delete the "ntprinters.tdb",
"printing.tdb" and "ntdrivers.tdb" files selectively.)

I noticed you are using Samba 2.2.7a (that's OK -- it's the latest). What is
the version of CUPS you are running (This could be very relevant, because
IIRC, there were some incompatibilities and/or bugs between certain CUPS
and certain Samba versions...?

> Cheers,
> 
> --
> Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org

Cheers,
Kurt