Bug 1114 - prt job & "prt cmd" occasionally owned by different users
prt job & "prt cmd" occasionally owned by different users
Product: Samba 3.0
Classification: Unclassified
Component: Printing
Other Linux
: P3 normal
: none
Assigned To: Gerald (Jerry) Carter
Depends on:
  Show dependency treegraph
Reported: 2004-02-20 19:43 UTC by Tony Ewell
Modified: 2005-08-24 10:17 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Tony Ewell 2004-02-20 19:43:11 UTC
Hi All,

    I am running samba-3.0.0-1 on a Red Hat 8.0 server.

    I have noticed that /var/spool/samba is collecting un-printed
jobs.  So I wrote a script to see what is happening.  (See script
attached below.)  I am using the following in my smb.conf
to call the script:

     print command = /usr/bin/supersmbprint  %p %s %J tony,kpack
     guest account = pcguest

    The script will eMail me (tony) a simple error report 
(lpr -V ...) when a job does not print correctly.  This is a sample 
of two of these reports:

#1         UserName:   pcguest
           PrintName:  HP5SI
           FileName:   smbprn.00000092.B8gXdK
           JobName:    http://www.askfinancial.com/ana.PDF
           LPRng-3.8.19, Kerberos5, Copyright 1988-2002 Patrick Powell 
           Warning - Cannot open file 'smbprn.00000092.B8gXdK', 
           Permission denied HP5SI: nothing to print

#2         UserName:   jbarn
           PrintName:  HP4600
           FileName:   smbprn.00000314.fYLOy7
           JobName:    F:casescases0303257040318maxine.ltr.wpd
           LPRng-3.8.19, Kerberos5, Copyright 1988-2002 Patrick Powell
           Warning - Cannot open file 'smbprn.00000314.fYLOy7', 
           Permission denied  HP4600: nothing to print

Looking at the spool directory (ls -al /var/spool/samba):

-rw-------  1 tjone    users  100153 Feb 19 10:29 smbprn.00000092.B8gXdK
-rw-------  1 pcguest  nobody   8436 Feb 19 09:48 smbprn.00000314.fYLOy7

I notice that the print job B8gXdK should be owned by pcguest but is
actually owned by tjone and print job fYLOy7 should be owned by jbarn
but is actually owned by pcguest.  This explains the "Permission denied"
and why supersmbprint was unable to delete the print job.

Many thanks,

------------------ smb.conf:[printers] --------------------

   comment = All Printers
   path = /var/spool/samba
   browseable = no
   public = yes
   guest ok = no
   writeable = no
   printable = yes

------------------ /usr/bin/supersmbprint ---------------------

#! /bin/bash
# /usr/bin/supersmbprint   
# Purpose: check to see if Samba print jobs made it out of the 
#          samba print spool

# "print command" variables:
#       The print command is simply a text string. It will be used  ver-
#       batim after macro substitutions have been made:
#       %s, %f - the path and name of the spool file
#       %p - the appropriate printer name
#       %J - the job name as transmitted by the client.
#       %c  - The number of printed pages of the spooled job (if known).
#       %z - the size of the spooled print job (in bytes)
# Note: default Samba print command: lpr -r -P%p %s
# Note2: lpr is set to make 3 attempts spaced 10 seconds apart
#        before aborting with exist status of 1 by default.  See
#        /etc/printcap:send_try for custom setting (send_try not
#        supported in CUPS)
# Call to this script from smb.conf:
#   /root/supersmbprint  %p %s %J FailEmailAddress



echo "UserName:   `whoami`"     >  $tmp2
echo "PrintName:  $PrinterName" >> $tmp2
echo "FileName:   $FileName"    >> $tmp2
echo "JobName:    $JobName"     >> $tmp2
echo "  "                       >> $tmp2
echo "  "                       >> $tmp2

/usr/bin/lpr -V -P $PrinterName $FileName >> $tmp2 2>&1

if [ "$ExitStatus" = "0" ]; then  
   rm -f $FileName
   rm -f $tmp2
   exit 0

   cat $tmp2 | mail -s "supersmbprint failure" $FailureEmailAddress
   rm -f $tmp2
   rm -f $FileName
   exit 1
Comment 1 Gerald (Jerry) Carter 2004-03-02 07:18:39 UTC
any chance you could try to reproduce this against 
3.0.2a.  I'm not guaranteeing it has been fixed but 
there have been some fairly visible bugs fixed 
since 3.0.0
Comment 2 Tony Ewell 2004-03-02 08:57:35 UTC
Hi Jerry,

   I set 
          public = no
          guest ok = no

to see if it would help.  I will be at customer's site on Thursday
to check.  I will upgrade Sabma at that time as well (I will reset
public and guest ok back to their original values after I do.)

I will keep you informed.

Comment 3 Tony Ewell 2004-03-10 17:17:49 UTC
Hi Jerry,

   There was no symptom change under 3.0.2a.  But, I did uncover another 
bug: 1173.  Sorry.  

Comment 4 Tony Ewell 2004-03-19 16:05:13 UTC
Hi All,

    I modified my supersmbprint script so that it would do
an "ls -al" is it saw a "permission denied" when lpr tried
to print.  Here is the result of one of these:

        UserName:   jskel
        PrintName:  HP4600
        FileName:   smbprn.00000695.bTCfAP
        JobName:    Corel Office Document
        LPRng-3.8.19, Kerberos5, Copyright 1988-2002 Patrick Powell, 
        Warning - Cannot open file 'smbprn.00000695.bTCfAP', Permission 
        HP4600: nothing to print

        -rw-------    1 pcguest  nobody      33295 Mar 19 13:00

The user name is taken from the "whoami" command.

Just out of curiosity, is there a way to change the permissions on the 
print file from 600 to 644?

Many thanks,
Comment 5 Tony Ewell 2004-04-23 17:20:51 UTC
Hi Jerry,

   Is this fixed under 3.0.3rc1?

Comment 6 Tony Ewell 2004-05-14 18:21:08 UTC
Hi All,

   My customer has been has been on 3.0.4 for about a week now.  Not
a single peep out of supersmbprint (I should have gotten back about
30 notices by now if the bug had not been fixed).  

   This bug has been fixed!  Please close as fixed (I do not have 
high enough permission to do such).  :-) 

   I sincerely appreciate having you guys at the other end of this.

Many, many thanks,
Comment 7 Gerald (Jerry) Carter 2004-05-15 05:30:42 UTC
Thanks for the update.
Comment 8 Gerald (Jerry) Carter 2005-08-24 10:17:58 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.