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 disappeared. 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.
Additional info: 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 02-AUG-1999 vlado_potisk
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 with?
This the spool directory: /var/spool/lpd: 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 /var/spool/lpd/hp1100: 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 something different?
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.