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 email@example.com
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 ***
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?
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.
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://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
--------- ---- -------
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).
(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.
Output from smbd -b:
In case it's helpfull i can provide a shell or more
I've also been able to reproduce this problem.
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.
I am not sure if this is the same bug, but it is definitely related. Please see
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
Created attachment 625 [details]
fix for missing printing defaults (should apply to v3.0.3 & later)
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.
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
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.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.