Bug 8689 - Error 0x00000002 when installing network printer on Windows 7 client
Error 0x00000002 when installing network printer on Windows 7 client
Status: NEW
Product: Samba 3.5
Classification: Unclassified
Component: Printing
3.5.11
x86 Windows 7
: P5 normal
: ---
Assigned To: printing-maintainers
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-05 04:01 UTC by Kevin Shanahan (dead mail address)
Modified: 2012-01-29 22:55 UTC (History)
0 users

See Also:


Attachments
Driver properties showing driver path as expected (26.43 KB, image/jpeg)
2012-01-05 04:02 UTC, Kevin Shanahan (dead mail address)
no flags Details
Driver properties with missing driver path (25.48 KB, image/jpeg)
2012-01-05 04:03 UTC, Kevin Shanahan (dead mail address)
no flags Details
Test 1 using print management console (40.96 KB, application/octet-stream)
2012-01-05 04:11 UTC, Kevin Shanahan (dead mail address)
no flags Details
Log files and packet capture from second test (49.59 KB, application/x-gtar)
2012-01-29 22:27 UTC, Kevin Shanahan (dead mail address)
no flags Details
Log files and packet capture from third test (66.72 KB, application/x-gtar)
2012-01-29 22:55 UTC, Kevin Shanahan (dead mail address)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Shanahan (dead mail address) 2012-01-05 04:01:26 UTC
We've had problems for a while now with Windows 7 client being "temperamental" installing network printers from our Samba servers. When attempting to install the driver error 0x00000002 is returned. I believe that translates into "file not found".

Various forms of voodoo including logging in and out, rebooting, etc. have been used to get around the problem - i.e. persist and it will eventually work.

Today I was looking around in the print management snap in (printmanagement.msc) and saw some strange behaviour which I believe is linked to this same problem.

Connect to the samba server, select drivers on the left to list the installed printer drivers. In the main pane, right click the driver name and select properties. You will have a seemingly random chance of seeing the driver path or no driver path.

I'll attach extra info shortly.
Comment 1 Kevin Shanahan (dead mail address) 2012-01-05 04:02:53 UTC
Created attachment 7227 [details]
Driver properties showing driver path as expected
Comment 2 Kevin Shanahan (dead mail address) 2012-01-05 04:03:25 UTC
Created attachment 7228 [details]
Driver properties with missing driver path
Comment 3 Kevin Shanahan (dead mail address) 2012-01-05 04:11:22 UTC
Created attachment 7229 [details]
Test 1 using print management console

Test1: Server = UCWB-KVM-20, Client = UCWB-0191

* Start packet capture on Samba server: tshark -w test1.pcap host ucwb-0191
* Run printmanagement.msc on client
* Print driver "IT2" is already selected in the main pane
* Right click "IT2", select properties
=> Properties dialog is displayed with driver path missing.
* Close properties dialog
* Right click "IT2", select properties
=> Properties dialog is displayed with driver path present.
* Close properties dialog
* Close printmanagement.msc
* Stop packet capture
Comment 4 Andreas Schneider 2012-01-09 13:07:21 UTC
Could you please provide log files and give more information which printer drivers or how to set this up to be able to reproduce it?

Providing Samba log files
==========================

Provide all log files from '/var/log/samba/' directory and the tdb files from
'/var/lib/samba' and the configuration file '/etc/samba/smb.conf'. Post the
output of 'rpm -qi samba' or 'rpm -qi samba-<subpackage>' too. We need that
information to reconstruct what happened.

If winbind for logging in is part of the problem please provide
'/etc/security/pam_winbind.conf' and if you have enabled debug in
'pam_winbind.conf' Ä/var/log/messages' is requried too.

More detailed description about different Samba components can be found blow
this section.

Testing daemons (winbind, smb, nmb)
====================================

1. Stop all running Samba processes (winbind, smb, nmb)

2. Remove all log files from /var/log/samba/

    With this approach we ensure to have the start date of the testing in the
    log files.

3. Edit /etc/samba/smb.conf and set the following variables in the in the
   [general] section of the config:

     debug level = 10
     debug pid = Yes
     max log size = 0

    Instead of setting a global debug level in smb.conf it's also visible to
    use

     smbcontrol <damon_name> debug 10

    to increase the debug level of the Samba daemon in question to 10 at run
    time.

    If winbind is part of the scenario please set

     debug = yes

    in /etc/security/pam_winbind.conf

4. Start the processes again (winbind, smb, nmb)

5. Reproduce the error and note the time when you start any test. If a problem
   occurs while testing note the time (use date on the system you perform the
   tests on to get a time fitting to the log files).

Attach the log files from '/var/log/samba/' and the tdb files from
'/var/lib/samba/' to the bug. If possible, remove the tdb files and provide clean
files. Therefore it's best to bond them to one compressed tar archive. The
relevant parts of '/var/log/messages' could be interesting too.
Comment 5 Kevin Shanahan (dead mail address) 2012-01-11 03:51:56 UTC
Thanks Andreas. I'll have to make some time to do more tests and provide the log files you are after. For now, here is the process to set up the printer driver:

Relevant smb.conf bits:

[global]

   ...

   printing = cups
   printcap name = cups
   printer admin = "@WUM3\it - printer admin"

   ...

[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   guest ok = no
   read only = yes
   write list = "@WUM3\it - printer admin"

   store dos attributes = no
   map hidden = yes
   map system = yes
   map archive = yes
   map read only = yes

   # need permissive mask for "map *" options to work
   create mask = 0777
   directory mask = 0777

Set up permisssions on the the printer driver directory:

# chgrp -R "WUM3\it - printer admin" /var/lib/samba/printers/*
# chmod -R g+w /var/lib/samba/printers/*

Make sure the driver files are present for cups to upload:

# ls -l /usr/share/cups/drivers/
total 1444
-rw-r--r-- 1 root root    803 Jan 28  2011 cups6.inf
-rw-r--r-- 1 root root     72 Jan 28  2011 cups6.ini
-rw-r--r-- 1 root root   9529 Jan 28  2011 cups6.ppd
-rw-r--r-- 1 root root  12568 Jan 27  2011 cupsps6.dll
-rw-r--r-- 1 root root  13672 Jan 27  2011 cupsui6.dll
-rw-r--r-- 1 root root 132608 Jan 27  2011 ps5ui.dll
-rw-r--r-- 1 root root 464384 Jan 27  2011 pscript5.dll
-rw-r--r-- 1 root root  26038 Jan 27  2011 pscript.hlp
-rw-r--r-- 1 root root 792644 Jan 27  2011 pscript.ntf

Set up the CUPS print queue:

# lpadmin -p IT2 -E -v hp:/net/HP_Color_LaserJet_2605dn?ip=192.168.0.223 -P /usr/share/ppd/hplip/HP/hp-color_laserjet_2605dn-ps.ppd

Reload samba so it sees the new print queue:

# /etc/init.d/samba reload

Upload the printer driver using cupsaddsmb:

# cupsaddsmb -U 'WUM3\...' IT2
Comment 6 Kevin Shanahan (dead mail address) 2012-01-11 03:55:49 UTC
To clarify the testing platform:

Server is Linux x64 (Debian Squeeze), client is Windows 7 32-bit.
Comment 7 Kevin Shanahan (dead mail address) 2012-01-29 22:27:16 UTC
Created attachment 7265 [details]
Log files and packet capture from second test

Second test using 32-bit Windows 7 client: UCWB-0138 / 10.193.36.32
Samba 3.5.11 (Debian) x86 server: 10.193.36.254

Attempt to add a network printer from the "Devices and Printers" panel in Windows. Error given by Windows was 0x00000002.

Included all level 10 log files and packet capture between client and server.
Comment 8 Kevin Shanahan (dead mail address) 2012-01-29 22:55:52 UTC
Created attachment 7266 [details]
Log files and packet capture from third test

Same configuration as test3, except the attempt to install the printer was done after a fresh reboot. In this circumstance the client takes some time (20 seconds?) before returning the 0x00000002 error.

If attempting to install the printer a second time (as in the case of test2) the error is returned immediately.