Bug 1464 - printer unavailability
printer unavailability
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: Printing
3.0.4
x86 Windows 98
: P3 normal
: none
Assigned To: Gerald (Jerry) Carter
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-17 13:32 UTC by Klaus Neuschaefer
Modified: 2005-08-24 10:24 UTC (History)
4 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Neuschaefer 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 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 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

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

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

[pdf-generator]
   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
machine):
$ 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://192.168.0.27:9100/
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:
 http://tecneeq.dyndns.org/~karsten/netbsd/sendpr/samba_smb.conf

Output from smbd -b:
 http://tecneeq.dyndns.org/~karsten/netbsd/sendpr/samba_smbd_3.0.5.txt
 http://tecneeq.dyndns.org/~karsten/netbsd/sendpr/samba_smbd_3.0.2a.txt

In case it's helpfull i can provide a shell or more
information.
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 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 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 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
setups.
Comment 12 Gerald (Jerry) Carter 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 2005-08-24 10:24:54 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.