Bug 1464 - printer unavailability
Summary: printer unavailability
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Printing (show other bugs)
Version: 3.0.4
Hardware: x86 Windows 98
: P3 normal
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact: Samba QA Contact
Depends on:
Reported: 2004-06-17 13:32 UTC by Klaus Neuschaefer (dead mail address)
Modified: 2005-08-24 10:24 UTC (History)
4 users (show)

See Also:

fix for missing printing defaults (should apply to v3.0.3 & later) (433 bytes, patch)
2004-08-31 11:28 UTC, Gerald (Jerry) Carter (dead mail address)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Neuschaefer (dead mail address) 2004-06-17 13:32:53 UTC
We have several clients running RH-9 and Samba for file services, mostly 
replacing Novell servers.  For the sake of MS compatibility, we have been 
looking forward to and using Samba 3x.  We currently have 2 clients running 
samba3_0_2a-1_rh9_i386.rpm.  It worked great except for chronic and ever 
worsening printer connection problems.  In particular, shared printers would 
come and go (be unavailable mostly).  The printers in question were both 
connected directly to the server (lp0) or via an HP JetDirect. We have been 
using lpd and bsd print settings with no problems until now.  I decided to try 
the latest release (samba3.0.4-1_rh9.i386.rpm) I upgraded the system to see if 
the print problems were improved.  All printers became completely unavailable.  
After fiddling with the system and attempting smb.conf changes, I was forced to 
go back to samba 2.7x (out of the RH box), which works flawlessly.  
Incidentally, this required a complete re-install of RH9. (not fun)  Do we have 
a bug or is lpd & bsd no longer supported?  We have used lpd & bsd printing with 
such success that we have never fiddled with cups.  Cups seems to require more 
overhead & setup (at first glance).  
Thank you,     Klaus Neuschaefer     klausn@qadas.com
Comment 1 Gerald (Jerry) Carter (dead mail address) 2004-06-21 14:11:28 UTC
This is probably the same as bug 1147 which was fixed in 3.0.3.

*** This bug has been marked as a duplicate of 1147 ***
Comment 2 Karsten Kruse 2004-06-22 11:42:12 UTC
Today i updated from 3.0.2a to 3.0.4 and ran into the same problem, the
lpd-printer does not print anymore (nothing in lpd.err, smbd.log or nmbd.log).
If i delete the package and install 3.0.2a it works again without changing
anything in smb.conf or elsewhere.

Bug 1464 is marked as resolved with "DUPLICATE of bug 1147" wich was fixed in
3.0.3 . How can it be that a fix in 3.0.3 solves a problem in 3.0.4?
Comment 3 Gerald (Jerry) Carter (dead mail address) 2004-06-22 12:11:18 UTC
I didn't see where you had tried 3.0.4 before.  
In any event I need much more information.  Please attach
your smb.conf file to the report and provide more details 
on howto specifically reproduce the bug report.

Also please include the output from smbd -b in the 
problematic 3.0.x install.

Sorry for the confusion.
Comment 4 Buchan Milne 2004-06-25 10:59:36 UTC
I don't know if this is related, but on 3.0.4 and 3.0.5pre1 I'm seeing an
off-by-one error in available printers (when I had 1 printer configured, I
thought printing was broken ...). All my printers are via cups, I have the
following relevant entries in my smb.conf:

   printcap name = cups
   load printers = yes
   printing = cups

   comment = All Printers
   path = /var/spool/samba
   browseable = no
   guest ok = yes
   writable = no
   printable = yes
   create mode = 0700

   path = /var/lib/samba/printers
   browseable = yes
   write list = @adm root
   guest ok = yes
   inherit permissions = yes

   path = /var/tmp
   guest ok = No
   printable = Yes
   comment = PDF Generator (only valid users)
   printing = bsd
   print command = /usr/share/samba/scripts/print-pdf %s ~%u //%L/%u %m %I "%J" &

Printers available via CUPS (all configured on my the CUPS server on the same
$ lpstat -t
scheduler is running
system default destination: telkom_hp2100
device for hp3700dn: socket://hp3700dn.obsidian.co.za:9100/
device for hp3700n: socket://hp3700n.obsidian.co.za:9100/
device for telkom_hp2100: socket://
hp3700dn accepting requests since Jan 01 00:00
hp3700n accepting requests since Jan 01 00:00
telkom_hp2100 accepting requests since Jan 01 00:00
printer hp3700dn is idle.  enabled since Jan 01 00:00
printer hp3700n is idle.  enabled since Jan 01 00:00
printer telkom_hp2100 is idle.  enabled since Jan 01 00:00

Printers available via samba:
$ smbclient -L localhost -N
Anonymous login successful
Domain=[RANGER] OS=[Unix] Server=[Samba 3.0.5pre1]

        Sharename       Type      Comment
        ---------       ----      -------
        installs        Disk
        print$          Disk
        IPC$            IPC       IPC Service (Samba Server 3.0.5pre1)
        ADMIN$          IPC       IPC Service (Samba Server 3.0.5pre1)
        hp3700dn        Printer   HP color LaserJet 3700
        hp3700n         Printer   HP color LaserJet 3700
Anonymous login successful

(as you will see hp2100_telkom is mssing ...

AFAICR, this issue was not present on 3.0.2a (I can test again if necessary).
Comment 5 Karsten Kruse 2004-07-28 14:03:29 UTC
(In reply to comment #3)
> Please attach
> your smb.conf file to the report and provide more details 
> on howto specifically reproduce the bug report.

How to repeat: Use my smb.conf with 3.0.2a, print from a
Windowsclient. it works. Use 3.0.4 or 3.0.5 with the
same smb.conf, print from the same Windowsclient, nothing
happens. Reinstall 3.0.2a and it works again.

My smb.conf:

Output from smbd -b:

In case it's helpfull i can provide a shell or more
Comment 6 Michael H. Warfield 2004-08-22 08:36:11 UTC
I've also been able to reproduce this problem.

3.0.2a works
3.0.3  fails
3.0.4  fails
3.0.5  fails
3.0.6  fails

All I did was install from the rpm, run a test print from a Windows client,
stop, save the logs, then install the next version.  All versions after 3.0.2a
fail to print anything and Windows gets no error.  The print job just seems to
drop into a black hole somewhere and Windows indicates the printer is ready with
no jobs in the queue.  lpstat on the Linux box shows no jobs having been processed.
Comment 7 Buchan Milne 2004-08-22 08:48:39 UTC
I am not sure if this is the same bug, but it is definitely related. Please see
bug 1644.
Comment 8 Gerald (Jerry) Carter (dead mail address) 2004-08-26 16:41:33 UTC
Some clarifications....

Prior to 3.0.3, Linux servers would incorrectly be assign BSD 
printing by default even if cups libs were found.

Beginning in 3.0.3 'printing = cups' becomes the default
if configure can detect sups support.  To disable this you 
can set --enable-cups=no.

Note that you can override the default printing value 
as well.  Just set 'printing = bsd' in the global section
of smb.conf.
Comment 9 Gerald (Jerry) Carter (dead mail address) 2004-08-31 11:28:14 UTC
Created attachment 625 [details]
fix for missing printing defaults (should apply to v3.0.3 & later)
Comment 10 Gerald (Jerry) Carter (dead mail address) 2004-08-31 11:33:34 UTC
the problem is that the default for the various printing commands 
(print command, lpq command, etc...) was not getting set unless 
you explicitly defined "printing" to some value.  Please test 
the attached patch.

This fix will be included in 3.0.7.
Comment 11 Björn Jacke 2004-09-21 16:01:51 UTC
with this change it is not possible to have "printing=cups" and have a single
printer which uses a different "print command" like a pdf printer for example.
Also the man page states that "print command" etc. are not global settings but
can be different from share to share. This change also breaks a lot of existing
Comment 12 Gerald (Jerry) Carter (dead mail address) 2004-09-22 10:22:18 UTC
Bjorn,  things work prefectly for me.  Besides, the original bug 
has been fixed from what I can tell.  Please open a new bug report
(and include smb.conf and log files)  if you think that something 
has regressed.  But from my tests, things are working ok.
Comment 13 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:24:54 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.