Red Hat Bugzilla – Bug 4135
printfilter fails on NFS filesystem - bogus permission checks?
Last modified: 2008-05-01 11:37:51 EDT
Shell script named filter exists in
the printer spool directory defined
in the /etc/printcap.
This script fails if this directory
exists on an NFS file system. After moving
it to local filesystem the problem
The script fails when it is invoked
from lpd and trying to read its
standard input; error message is
Input/Outpuer error. The problem results
in a message "no way to print this file
type" (don't remember it exactly)
printed on the printer.
Works fine for me here when the spool directory is NFS
mounted - of course, it has to be mounted no_root_squash.
after each print attempt there is a message
in the NFS server's syslog:
kernel: fh_verify: hp1100/df..... permission failure
So I checked the file permissions in the spool directory
on my system (NFS client):
- script named filter runs wtih UID=lp, GID=root
- it read the df.... file from its standard input
- that df.... file has UID=root, GID=lp, mode=660 (rw-rw----)
- this means that process 'filter' is not able to
open and read the df.... file
- there is normally (i.e. without NFS) no problem
with this, becasue 'filter' has already a valid
open descriptor (stdin) for this df.... file
- it seems to me that NFS checks during the read
operation the file permissions of already open
file and thus causes the described problem
What happens if you upgrade to the latest lpr package from
Raw Hide (0.39)?
After the upgrade I CAN print. No permission problem
anymore; the process runing 'filter' has now GID=lp
in its supplemental group list.
It's still odd that it would fail in the first place.
What permissions are you mounting the spool directory
This the spool directory:
drwxrwxr-x 3 root daemon 1024 Aug 3 19:43 .
drwxr-xr-x 8 root root 1024 Jul 16 22:32 ..
drwxr-xr-x 2 root lp 1024 Aug 2 21:51 hp1100
-rw-r--r-- 1 root root 4 Aug 3 18:47 lpd.lock
drwxr-xr-x 2 root lp 1024 Aug 2 21:51 .
drwxrwxr-x 3 root daemon 1024 Aug 3 19:43 ..
-rw-r----x 1 root lp 4 Aug 2 21:51 .seq
-rwxr-xr-x 1 root root 9443 Jul 31 19:24 filter
-rwxr-xr-x 1 root root 187 Jul 31 19:24 general.cfg
-------rw- 1 root root 4 Aug 3 18:47 lock
-rwxr-xr-x 1 root root 338 Jul 31 19:24 postscript.cfg
-rw-rw-r-- 1 root root 33 Aug 2 21:51 status
-rwxr-xr-x 1 root root 147 Jul 31 19:24 textonly.cfg
Everything is on one root-NFS filesystem on a diskless PC.
Hmm... comparing that to a spool directory here everything looks OK.
Are both the server and client RH 6.0 machines, or are they
Both machines are running freshly installed RH6.0 plus
some updates that were available at the time of installation.
The kernel is 2.2.10, I have compiled it from the source,
not installed from some RPM. Hardware is quite standard
and stable. I was able to duplicate the bug also on only
one machine exporting NFS filesystem to localhost.
Hm... although I'm not sure while it's failing, it is fixed
with the lpr update. I'm marking this fixed for now, and
I'll look at the NFS issues later.