lp : drivers loaded but no devices found - [re-opened]

[samwathegreat]

Also, I want to point out that with the fix from my above post, I am NOT having xav's problem with the spool directory still containing files. Everything gets removed - I've also noticed that NOW (after using fix), cups automaticly deletes the processed/completed jobs after a few minutes. I can look in /var/spool/cups OR the Cups jobs page (show completed jobs), and they both show empty. Before, everything just piled up in there, so seems to have fixed this problem as well.

[Patriot]

Hmmm .....

This /var/spool/cups folder issue reminds me of one old cups-1.1.23 problem I had a long time ago ... I moved it to tmp to make it work ...

I guess its time to start poking into cups again soon ... Ok, guys, can't make any promises when it'll happen but I'll look into the spool folder issue again later and see what its about ...


Rgds

[xav795]

Also setting "AutoPurgeJobs Yes" and "MaxJobs 1" and then restarting cups doesn't work either?

jpeps,

I then have only one job in the folder, but it does not print anymore, i still have the permission denied error message.

Rgds

[jpeps]

Did you change it to root root? (eg, chown the cups directory)

[jpeps]

Did you change it to root root? (eg, chown /cups/*)

[xav795]

jpeps,

After having changed it with:
chown root:root cups
I then restart cups, and the old owner went back.
I don't know if having "nobody" in group is a problem

Rds

[jpeps]

jpeps,
I don't know if having "nobody" in group is a problem
Rds

According to samwathegreat, that seems to be the issue. Puzzling, though, because he claimed the permission change occurred only after a reboot, not after a cups restart. I believe the cups directory (and its files) should be root:root

Code: Select all

drwx--x--- 4 root root 4096 2010-02-08 15:56 /var/spool/cups/

[samwathegreat]

I don't see a difference in the permissions of the /var/spool/cups directory when cups gives the error vs. when everything is working normally.

They are identical in both instances (root:root), so it seems that when cups is restarted (or just started) with the /var/spool/cups directory missing, cups subsequently re-creates them and "repairs permissions" (I've seen this in my debug cups log) that it also changes something else? Seems to me like it also changes the way cups writes data to the /var/spool/cups.

Also, I've noticed that when I print from my other computer running puppy (through IPP), the job shows up under "anonymous" - but anything printed locally or via samba shows up as "root", so it's not always root. (but still works with workaround)

I'm still quite puzzled myself. However, the fix I referenced before (modify /etc/init.d/cups file) is still going strong. Puppy always prints, even after several reboots.

[rcrsn51]

@samwathegreat

May I make a few comments about your situation? First, the persistent c0000x files are a "feature" of CUPS. There is some maximum default number of these files that are retained, at which point CUPS will start deleting them. However, I was able to make them auto-delete by using these lines in cupsd.conf just below the LogLevel line:

Code: Select all

PreserveJobHistory No
PreserveJobFiles No

There is nothing wrong with the root:nobody ownership of CUPS files. That's how CUPS works normally. IIRC, it has something to do with security issues and CUPS 1.3.x not wanting to process print jobs as the full privileged root:root user .

That said, I set up a fresh copy of 4.3.1 and installed CUPS 1.3.11 and your Canon MP-240 driver. (Since I don't own your printer, I assigned it to a disconnected port like LPT1.) In all cases, print jobs were processed correctly and there were no errors reported from the pstops filter.

FWIW, I have two other printers working fine in this setup. I also have CUPS 1.3.11 working correctly in another Linux with non-root ownership of print jobs.

I am certainly not disputing your own experience, but I don't know what would be causing your problem. Are you installing any additional printing functionality, like the Samba server? Or maybe the Canon backend is causing the problem. It would be interesting to know what happens if you install a different printer on your system.

[Edit] Are you using the cupsd.conf file that comes with Patriot's package or an older / modified version? It looks like you have configured CUPS for network printer sharing. Maybe that's involved.

Are you, like xav795, using a version of Puppy 4.1.2?

What install method - full, frugal, flash drive?

[rcrsn51]

What install method - full, frugal, flash drive?

I can confirm that if you have Puppy and CUPS 1.3.11 installed on a flash drive, you will get the Permission Denied error described above.

I suspect that the problem is caused by the special layered filesystem used on a flash drive. It looks like CUPS always starts off using the original /var/spool/cups folder in the sfs filesystem, which has root:root ownership. Hence the permission problem. Once you white out that folder and let CUPS replace it with the correct version, you can print. But on the next reboot, CUPS somehow reverts back to the original even though you see the correct one in your view of the filesystem.

In retrospect, I believe that there have been other episodes of strange CUPS behaviour involving flash drives.

[samwathegreat]

Thank you for confirming my situation...I had wondered if the layered filesystem was the culprit.

Yes, indeed, I am running 4.3.1 from (you guessed it) a flash drive.

Do you feel that my workaround (modifying /etc/init.d/cups) is the best solution for this problem?

[rcrsn51]

Do you feel that my workaround (modifying /etc/init.d/cups) is the best solution for this problem?

Definitely. The other solution would be to remaster pup-431.sfs and change the ownership of /var/spool/cups to root:nobody.

BTW, kent41 in this thread had the same problem (and solution) as you. And I suspect that he was also using a flash drive.