[Samba] Re: Linux, Samba, and the Lexmark z53

Sun May 12 05:43:05 GMT 2002

SO, the situation is, as I understand it:
You are using XP as a client.
You have successfully installed the lexmark drivers on the XP client.
When you print from the XP client, you get no error messages. 
The file size in the "spool" directory is zero after you print from XP.

Comments:
Let's define two terms, just for our own use.
I think the term "spool directory" is unclear. Let's call the "spool"
directory the place where samba stores the print file received from the
XP client, before samba invokes lpr to print it. When lpr is invoked, the
file is transferred to the "queue" directory specified in /etc/printcap. I
use /tmp as my "spool" directory because everyone can write to it but only
the user can remove his own files. And, if things are going properly,
the tmp directory is periodically cleaned out for you, usually during
boot up. All these things are good.  These are the permissions of my
/tmp directory.
  drwxrwxrwt  43 root     root        14336 May 12 08:18 tmp

Now, it it a BAD idea to use the queue directory (specified in
/etc/printcap) for your spool directory. If you set your permissions with
checkpc -f (which you should do), very likely the samba user will not be
able to write to that directory, and the file transfer will fail. SO,
I would put your spool directory someplace anyone can write to, like
/tmp, and try to print again from XP. You might make a special /SPOOL
directory with chmod 777 just to make this debugging easier. Leave out
the rm command from your print command and it would help to use
  print command = echo "Tried to print %s at `date` >> /tmp/junklog

Don't forget to upate your path command in your printer share, either.
You did follow my suggest to use the actual name of the printer instead of
%p ?

Please do the things I suggest you do and tell me the exact results.

Then, try printing. 

As an further note, I think your smb.conf file is the original file with the
distro and you just modified it. For debugging, you might consider a very
stripped now version of this file. Who knows what evil is lurking elsewhere
in your smb.conf file.

You do run testparm after you modify smb.conf?

Joel

On Sat, May 11, 2002 at 07:51:24PM -0700, adrian kaehler wrote:
> 
>    Hi,
>   Let me try to address the things you suggest in order...
>   The logs are not helping me at all... or at least I don't think so.  In the spool directory, nothing is being written to at all, even "status" is not written to.  The timestamps on all of these files are unchanged for quite some time.  I did move the /tmp to the same value as the spool directory indicated in the /etc/printcap since my last mail (I read that these should match) and now the print files themselves ("smbprn.tfjAhL" etc) are written to the spool directory, but as before they arrive with size zero.  Nothing is written to /var/log/messages.  in /var/log/samba, there are seperate log files for every client, and the WinXP client in question has a log file called "harmony.log".  This log is qritten to - quite cryptically - whenever I kill and restart smbd (when I change /etc/smb.conf).  The message which appears there is:
> [2002/05/11 07:28:23, 0] rpc_server/srv_spoolss_nt.c:_spoolss_fcpn(4663)
>   _spoolss_fcpn: Invalid handle (OTHER)
> [2002/05/11 07:28:23, 0] rpc_server/srv_spoolss_nt.c:close_printer_handle(257)
>   close_printer_handle: Invalid handle (OTHER)
> 
> These messages are correlated with starting smbd though, and not with the printing.  Why they appear in the file "harmony.log" is completely beyond me though... as starting the smbd daemon seems to have nothing in particular to do with the client "harmony" (perhaps this is because "harmony" has the printer "installed" and so there is some communication at startup time?)  The log for smbd itself "log.smbd" is not written to.  The last log you mentioned was in /usr/local/samba/var.  I do not have a /usr/local/samba directory.  Can you think of where else the information might be which you thought I might find there?
>   I have deleted those "rm" statements.  This now allows me to see the print files accumulate in the spool directory, but they still are size 0.  The last thing is your mentioning the impression that I had successfully printed something.  Looking back on what I wrote, I was terribly unclear.  The "same thing" I was referring back to was in fact "nothing".  What I meant by that passage was that I got the same message from WinXP when it failed.
>   I am not sure about the "real" guest account.  This smbuser is what is used in the "samba faq" and is what I use on the same machine for file sharing which works great.  It is also what I used back when I was using the cannon400s.  This does however raise the issue that one or the other of the programs called under the smbuser id might not have permission to do something they need to do.  For example the spool directory was perm 700, which was not allowing me to write the temp files to it.  Thinking on it now, is it possible that since the stuff like "status" in the spool directory is perm 700 and owned by root (actually lp) that this is causing some headache when samba tries to update those files?  --- wait... lemmie check --- ... doing experiment....
>   ... nope.  Set all those perms to 666, and still no visible improvement.   Ok... setting them back.
>   But this seems to me a clue yes?  Even the queue status file is not being written to?  What could this mean?
>   Thanks again and again for all of your help... are you at work?  Don't you ever get to go home?
>     _adrian
>  
>   Joel Hammer <Joel at HammersHome.com> wrote: Some comments, in no particular order:
> You are going to have to start reading the logs to see what is going on.
> I would remove valid users from your printer definition.
> Make sure security=share in the global section.
> I would use the real name of the print queue in place of %p.
> The first issue to solve is why you are not getting the files transferred
> from you windows clients to the /tmp spool directory. To that end, I would
> delete the rm %s from the printer command. Make sure there is a real guest
> account. I use ftp.
> The logs may help. (/var/log/messages, /var/log/samba,
> /usr/local/samba/var/, and the status files in your printer queue.
> 
> I assume this means you got two pages printed:
> > Under this setup the printer icon in WinXP actually has the word "ready" written under it, which was never there before... but printing a test page yields only the result described earlier.
> NOTE: lpc is in /usr/sbin. 
> Joel
> 
> On Sat, May 11, 2002 at 06:06:11PM -0700, adrian kaehler wrote:
> > 
> > 
> > Ok, so on the "lprng" issue, that seems to be what I have. I ran checkpc, and got the following message:
> > [adrian at valor lexmarkz53]# checkpc
> > Warning - permissions of '/var/spool/lpd/lexmarkz53' are 0777, not 0700
> > So if having checkpc implies having lprng, then that's me. Also if Redhat 7.1 uses it, it is at least reasonbable to suspect that RH 7.2 does as well.
> > Currently however, I am unable to get anything to print on the printer, garbage or otherwise. When I attempt to print a test page from WinXP, I get a popup that says something like "Print failed, would you like to run the troubleshooter?" (as if that would help). Of course I click "no" and that's that. If I go to the linux machine, I see that there is a file in /tmp (this is where it should be yes? Because that is the "path" variable in the smb.conf file?) with a name like smbprn.DK41em, but it is size zero bytes. As I waited for your response I was reading elsewhere, and reorganized the [lex] entry in my smb.conf file to read:
> > [lex]
> > printing = lprng
> > printer = z53-outfiles
> > printer name = z53-outfiles
> > comment = Raw Printer for Z53
> > path = /tmp
> > create mask = 0700
> > guest ok = yes
> > hosts allow = 192.168.
> > valid users = smbuser
> > printable = yes
> > ; print command = echo "Tried to print %s" > /tmp/junk.%s
> > print command = /usr/bin/lpr -P %p %s; rm %s
> > lpq command = /usr/bin/lpq -P %p
> > lprm command = /usr/bin/lprm -P %p %j
> > lppause command = /usr/bin/lpc hold %p %j
> > lpresume command = /usr/bin/lpc release %p %j
> > printer driver = Lexmark Z53 Series ColorFine
> > ; printer driver location = \\VALOR\public\Adrian\Drivers Etc\lxkz53
> > share modes = No
> > 
> > Now, I am not sure what the difference between "printer" and "printer name" is, but I set them both to the queue you suggested "z53-outfiles", and changed the explicit references to "lp" to the meta "%p" which my reading suggests interpolates either "printer" or "printer name", but I do not know which (so I made them the same).
> > Under this setup the printer icon in WinXP actually has the word "ready" written under it, which was never there before... but printing a test page yields only the result described earlier.
> 
> Also it should be mentioned that any attempt to print from any other WinXP application gives an "Invalid HANDLE error", which results in no print attempted.
> > So at the moment, my issues is how to get WinXP to thing the print was successful, which I would think is at least correlated with getting the smbpm.XXXXX file to appear in /tmp, and maybe even printed... but for now, I can not even get the garbage files that I was seeing a few weeks ago (then under some strange configuration involving BSD and other things lost in the annals of history now).
> > Thanks again for all of your help,
> > -Adrian
> > 
> > Joel Hammer wrote: Actually, never having used bsd or cups, I wouldn't really know.
> > If you have checkpc and it works, you likely have lprng. RedHat
> > 7.1 used lprng. 
> > Since printing goes for two lines and stops, you may fine something of
> > interest in the status files in your print queue.
> > Have you tried just cat'ing the file in the /tmp spool to lp0?
> > The type of printing software you have on linux won't affect the cat'ing
> > experiment.
> > Joel
> > 
> > 
> > 
> > ---------------------------------
> > Do You Yahoo!?
> > LAUNCH - Your Yahoo! Music Experience
> 
> 
> ---------------------------------
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience