Get APLawrence.com by RSSSCO OpenServer 5.0 root can print to local prtr users can't
Author: anonymous
Date: Thu Mar 9 19:53:29 2006
Subject: SCO OpenServer 5.0 root can print to local prtr users can't
I have a Lexmark printer on /dev/lp0, entry in printcap seems fine. root is the only account that can successfully perform an lp to this printer and have it print. Other users can cat > /dev/lp0 and have it print to that printer, just can't get jobs to it through lp.
Remote printing is set up on the machine, but the permissions on /usr/bin/lp seem fine. I can even do an lp from the other accounts and it'll assign a job name, it just won't print. It's not stuck in the queue, doing an lpstat never shows any jobs.
Any ideas?
More Articles by anonymous
/Forum/anonymous36.html copyright March 2006 anonymous All Rights Reserved
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
I sell and support
Kerio Mail server
Click here to add your comments
Thu Mar 9 20:32:04 2006: Subject: TonyLawrence
Lot of posts here on that; have you read them?
Thu Mar 9 21:05:16 2006: Subject: TonyLawrence
Something doesn't make sense: you say it's not stuck in the queue. If it's not in the queue, it either failed to print or did print (was sent to the printer anyway).
Look in the /var/spool/lpd/printername : are the jobs there and lpstat just isn't seeing them?
Wait - you said it's on /dev/lp0 - so it isn't a remote - WHAT users can't print to this? Local users? Remote users?
Fri Mar 10 12:39:57 2006: Subject: anonymous
the jobs aren't in /var/spool/lpd, in fact it seems like they disappear just as soon as I put in the lp command. (permissions on the directory were fine too)
root has no problems printing with lp - those jobs come out fine, it's just the other user accounts that refuse to print. There's no entries in the users.deny and I did a scoadmin printer just to check to see if any users had been set to be denied and there were none. I'm just completely baffled.
Fri Mar 10 12:40:51 2006: Subject: anonymous
sorry, it's the local user accounts that don't print
Fri Mar 10 12:55:46 2006: Subject: TonyLawrence
Look in the "requests" log. Do the users show up there? If they do, then the lp system *did* print and it's what they are sending that is somehow whacked.
You said they got a job id, so unless your system is totally broken, these got spooled. You can confirm that by "disable lexmark" (or whatever you called it)
and observing that the files do show up in the spool directory.
If you then "enable", and the jobs disappear, they'll be in the "requests" log and they went to the printer..
Fri Mar 10 12:57:04 2006: Subject: TonyLawrence
And it wouldn't be /var/spool/lpd: this is a local printer so it's /usr/spool/lp/temp
Fri Mar 10 15:00:06 2006: Subject: anonymous
This is interesting.
I disabled the local printer (local_lp is the name) and sent a job to the queue from one of the local user accounts. I checked /usr/spool/lp/temp and found the job there.
Then I enabled the printer and the job immediately disappeared. But the printer still printed nothing.
Fri Mar 10 15:05:52 2006: Subject: TonyLawrence
Well, I've been trying to tell you this: the problem is what you are sending to the printer. The job apparently is going there: if you really, really need to prove it you could:
touch /tmp/printfile
chmod 777 /tmp/printfile
/usr/lib/lpadmin local_lp -v /tmp/printfile
Fri Mar 10 15:38:19 2006: Subject: anonymous
Sorry for the continued craziness. But it keeps going.
I did the above - created /tmp/printfile, set permissions, and set it as the default device for printer local_lp.
Then I sent it jobs through lp from both root and the user accounts.
When I sent it jobs through root, they were clearly being appended to the file. When I sent it jobs through the user accounts, the file didn't change.
Fri Mar 10 15:41:29 2006: Subject: TonyLawrence
Then the user should have gotten email explaining what happened..
Fri Mar 10 16:35:18 2006: Subject: TonyLawrence
And now this really looks like your perms are munged. Have you REALLY checked this?
Mon Mar 13 19:31:51 2006: Subject: anonymous
Here are the permissions for lp:
/usr/bin
---x--s--x 1 bin lp 2600 Apr 27 1999 lp@
/usr/lpd/local
---x--s--x 1 bin lp 91484 Apr 27 1999 lp
/usr/lpd/remote
-rws--s--x 1 root daemon 36680 Apr 22 1999 lp@
/var/spool/lpd directory:
drwxrwxr-x 11 root daemon 512 Mar 13 14:12 lpd
Is there anything else I should be checking?
Tue Mar 14 13:19:47 2006: Subject: TonyLawrence
Did you run scoadmin to fix permissions - or at least check them?
There is something whacked here - you probably need to have someone log in and see what is really happening here.. or if there is someone local to you, have them stop in. I think we are just missing something obvious.
Tue Mar 20 20:17:11 2007: Subject: anonymous
hen I try to print to a network printer when *not* logged
in as root, the print job never reaches the printer. There
are no errors at the command line.
Solution
One of the reasons this can occur is due to incorrect
permissions on the /etc/hosts file. Check this first.
Common /etc/hosts permissions should be 0644.
So, change your /etc/hosts to the permissions above,
by using following command:
# chmod 0644 /etc/hosts
Take Control of Fonts in Leopard
Sat Jun 2 15:28:58 2007: Subject: anonymous
common problem with unix printing. i've found no way to resolve this issue, under unix or linux. Seems the the lp command demands only root to print. Shoddy programming if you ask me. Should be a lpuser file somewhere on the system and anyone (username) listed in the file should be able to print to any printer allowed. No matter how screwed up his/her/it's document is, it should print something.
Tue Jul 31 09:26:41 2007: Subject: John
Had the same problem, print jobs for ordinary users 'stick' in the print queue & stop anything else printing in that queue. Cancel all the jobs for ordinary users & then any root jobs would print.
Set permissions on /etc/hosts (was a link file on my system, so cd to the link directory) & set the permissions to 644, all jobs dissapeared from queue as soon as set permissions & now printing fine !
Fri Aug 31 17:21:31 2007: Subject: anonymous
simply check the dev directory for the persmissons on lp, change to 666 and off you go!)
Mon Feb 16 21:08:47 2009: Subject: SCO Printing anonymous
FYI: I have encountered this kind of issue in the past and the resolution was this: The lp command was producing an error message due to the -o options not working with the driver file used. EG -o si was not understood by the version of the driver file used. When you are root, this error is reported (if you capture it) but the print job continues. If you are not root-equivalent, the error stops the print job from spooling out, it just disappears. Remove all the options on the line first, and test print, and you might find it to be the cause.
Mon Feb 16 21:18:11 2009: Subject: TonyLawrence
I'd have to see your driver script to understand how that could happen. An unknown option would just be ignored by any script I recall.
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar