From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 Description of problem: sane-frontend applications (xsane, kooka, scanimage -L) do not find a scanner when run by user. At the same time, the superuser may run them correctly. The particular scanner is a parallel-port Plustek 9636T. The user has an UID number 500, and belongs to a group with gid number 1000 ("users"). The relevant files (etc/sane.d/*, /usr/lib/sane/*) seem to have proper permissions (read for all, read and execute for all, correspondingly). Version-Release number of selected component (if applicable): sane-backends-1.0.13-7 How reproducible: Always Steps to Reproduce: 1. Install FC2, set up a group with GID=100, and an user account with UID=500, gid=1000 2. Hook up a scanner and get it running. In my case, this required uncommenting line plustek_pp in /etc/sane.d/dll.conf. 3. run "scanimage -L" as a root and as the user Actual Results: running "scanimage -L" as root (results in reporting the device) running as user fails to find any scanners Expected Results: running as user should also work Additional info: it also turned out that the kernel needed to be recompiled to shrink it somewhat to get the module drivers working; this however appears to have nothing to do with the access problem, similar symptoms occur in any of the kernels I try (2.6.5, 2.6.7, 2.6.8) Running the standard distribution kernel, as well as any of the upgrades kernel-2.6.5-1.358 kernel-2.6.7-1.494.2.2 kernel-2.6.8-1.521 causes problems with module drivers: vmware 4.5.2 loses access to a CD-ROM, plustek_pp scanner gets into a dead loop (moving sensor back & forth) while prescanning, sound chip (VIA 8233, ALSA drivers) produces only thrashing voices. These problems cease after kernel recompilation with some options turned off.
You need to power the scanner off, and then on, *after* you log in at the console. This is because the new 2.6 kernel no longer provides the old access method. This is a known limitation of Fedora Core 2, and will be addressed in a future release. *** This bug has been marked as a duplicate of 121511 ***
(You pointed out that this is a parallel port scanner not a USB one.) You'll have to change the permissions on /dev/ppdev*, or set up /etc/security/console.perms to do so for you. As far as I'm aware parallel port scanners have never been available to the console user without some other action being taken. You shouldn't need to recompile the kernel.
I describe the final solution below. Situation: neither /dev/ppdev* was present on my system nor there was a relevant device in the /etc/security/console.perms. The scanner backend (sane-plustek_pp) was using /dev/parport0. The kernel recompilation mentioned in the mail above was taken as a remedy to an apparently separate problem (kernel too large or too many space used by modules). It also worked OK. Instalation howto: If you happen to have a parallel-port Plustek scanner, 1) edit /etc/sane.d/dll.conf, uncomment "plustek_pp" and comment out "plustek" 2) run "scanimage -L" as root and then as a normal user. If the scanner is found when attempting as root and not when attempting as a normal user (the response should read: device `plustek_pp:parport0' is a Plustek 9636T/12000T parallel port flatbed scanner) 3) edit /etc/security/console.perms: find line starting with <scanner> and append /dev/parport0 to the end of it. 4) log out and in as normal user (if working under gdm/kdm, close the session and log in again). 5) run "scanimage -L". If OK, test your favorite sane frontend.