From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko) Description of problem: I am not able to use my scanner (mustek usb 1200 CU). As user, scanimage -L only gives out my tv card, as root I can see the scanner with scanimage -L, but when I try to load xsane with this device, xsane hangs up. I've tried to make a user group "scanner" and to add permissions to the directory /dev/usb/scanner0 or to /dev/sg0 or sga, but nothing helped. Sandy Pond adviced me at the Fedora Mailing list (thx for that) to enter: chmod 777 $(sane-find-scanner | & grep '^found USB scanner' | & sed -e 's?^.*libusb:?/proc/bus/usb/?' -e 's?:?/?') It helps me to find the scanner with scanimage -L as user, xsane then shows it as device, but when I try to start with it, I get Failed to open device libusb:003:002 Error during I/O device. Next try was to change the mustek_usb.conf file (the device Message from xsane talks about mustek_usb:libusb:003:002) from autodetect to usb libusb:003:002, but than scanimage is unable ot recognize it. Xsane is able to scan pictures from my tv card, so the programm itself seem to work. Fedora Core 1 was able to detect my scanner corectly, I am sorry that I am not sure about FC2t1, so maybe there is a problem with selinux? Version-Release number of selected component (if applicable): sane-backends-1.0.13-5.1 , sane-frontends-1.0.11-4 How reproducible: Always Steps to Reproduce: 1. Install FC2t1 with an mustek 1200 CU USB Scanner 2. Update to development tree (last version tested: ~15. April 2004) 3. Look up scanimage -L as user or start xsane as root Actual Results: I am not able to find the scanner as user or to work with xsane as root. Expected Results: As user the scanimage -L should show the scanner (as in FC1), so that xsane works with it. Additional info:
"maybe there is a problem with selinux?" <- is SELinux enabled? If so, the first thing to do is disable it and see if things work then. If they do, then we know it's an SELinux problem -- if they don't of course it isn't.
I have a scanner that worked with the 2.4 kernels as joe user. It did not work as a normal user with the 2.6 kernel. After a discussion on the fedora-test list. I was led to try running xsane as root user. It worked as root, to my surprise. As a further test, I installed a fresh installation directly from the 4/21/04 devlopment tree. Then I tried xsane as user and it could not find a device. I then tried as root on the fresh install and xsane worked when run as root. The version of scanner that I use is an HP ScanJet 2100C. I do not have to configure anything to get this scanner model to function usually. SELinix was not used in all cases.
I tried to deactivate selinux with 'setenforce 0' as mentioned on the fedora-test-list. It does not help, it gives the same message out while trying to start xsane with the scanner. Failed to open device libusb:003:002 Error during I/O device. Roland
I just did a fresh install of FC2 Test3 from iso images. My Epson Perfection 1240U scanner which works great in FC1 (and many other distros) by simply uncommenting the last line of /etc/sane.d/epson.conf is not recognized by xsane. SELinux is supposed to be disabled by default in this install, so that is probably not the issue. scanimage -L gives this result as root: [root@gstpc sane.d]# scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). sane-find-scanner gives this result as root: [root@gstpc sane.d]# sane-find-scanner found USB scanner (vendor=0x04b8 [EPSON], product=0x010b [Perfection1240]) at libusb:003:002 running xsane as root or normal user gives the same "no devices available" error.
running sane-find-scanner as either a normal user or as root does not find anything. If I launch xsane as root, I can scan a picture. I just downloaded the below versions of xsane and friends. xsane-0.92-10 xsane-gimp-0.92-10 I'll try as a normal user and see if things are more sane, instead of insane.
With xsane-0.92-10 and xsane-gimp-0.92-10 installed, it still dos not work from the launcher. It still works as root user for me. I did not restart GNOME or try after a cold start. Are there any lingering libraries that might need a restarted X session or permission sets that might need to be set during the boot process?
After the update, root with xsane is able to scan images. But user is stil unable to scan, 'scanimage -L' can't find the scanner, with chmod 777 $(sane-find-scanner | \ grep '^found USB scanner' | \ sed -e 's?^.*libusb:?/proc/bus/usb/?' -e 's?:?/?') 'scanimage -L' find the scanner as user, but xsane still gives out the I/O error. Roland
As root: scanimage -L device `plustek:libusb:001:004' is a Hewlett-Packard Scanjet 2100c USB flatbed scanner as a regular user: scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). I did not change file permissions or any configuration settings. It detected the proper scanner, as root. Does the new usb driver for 2.6 need to be set to any permision that a regular user could use? I checked the permissions for the driver for my scanner. ls -l /usr/lib/sane/libsane-plustek.so.1.0.13 -rwxr-xr-x 1 root root 158000 Mar 5 01:34 /usr/lib/sane/libsane-plustek.so.1.0.13 Are these permissions rational? Or should they reflect a special group? Jim
I changed the permission of my usb device to allow write access also to the scanner plustek:libusb:001:004 I changed to permission of /proc/bus/usb/001/004 to allow writing by group and others. It scanned when I issued xsane plustek:libusb:001:004 at the command line. upon exiting the xsane program, I got the following error "failed to create file, permission denied." After clicking the close button on the above error dialog box, xsane closed down. dmesg reported this "badness" ppdev0: registered pardevice Badness in interruptible_sleep_on at kernel/sched.c:1927 Call Trace: [<022defe8>] interruptible_sleep_on+0x5a/0x230 [<0211a4ba>] default_wake_function+0x0/0xc [<22ba9716>] parport_claim_or_block+0x22/0x50 [parport] [<22bc846e>] lp_write+0x1f3/0x2c7 [lp] [<0215c8ff>] vfs_write+0xb8/0xe4 [<0215c999>] sys_write+0x2c/0x42 ppdev0: unregistered pardevice ppdev0: registered pardevice Badness in interruptible_sleep_on at kernel/sched.c:1927 Call Trace: [<022defe8>] interruptible_sleep_on+0x5a/0x230 [<0211a4ba>] default_wake_function+0x0/0xc [<22ba9716>] parport_claim_or_block+0x22/0x50 [parport] [<22bc846e>] lp_write+0x1f3/0x2c7 [lp] [<0215c8ff>] vfs_write+0xb8/0xe4 [<0215c999>] sys_write+0x2c/0x42 ppdev0: unregistered pardevice done for tonite anyway! Jim
So does this line (in /etc/security/console.perms) need changing?: <scanner>=/dev/scanner /dev/usb/scanner* What happens if you add '/proc/bus/usb/*' to it? Or do the hotplug scripts need something akin to /etc/hotplug/usb/usbcam, for changing the permissions correctly? What happens if you copy /etc/hotplug/usb/usbcam to /etc/hotplug/usb/scanner?
These lines changed nothign - do I have to reload anything to make them working?
Not sure. I think this is something that needs help from a hotplug script though. (CCing hotplug package maintainer.)
My scanner works as regular user when the usb device permission is changed to 006 but neither or the other permissions seem to make a difference. Root can use the device also with the 006 permission. chmod 006 /proc/bus/usb/001/004 makes the scanner work for all users. I tried out the scanner on a system upgraded from FC1, an ftp install from development and another FC2T1 to FC2T3 with the same results. I have a hub connected to the USB port. My flash reader seems to work. The USB hard disk is not recognized though. (Of course a different problem for the USB hard disk. Though might be for the same reason.)
You are right, I changed my permissions, too, and it works as user! chmod 006 /proc/bsu/usb/003/002 Thx very much, Roland
No problem with getting the hack to work. It would great for the reason that the file for the usb device has 644 permissions originally and does not work for the scanner. The only premission that seems to matter is for the last permission to have rw access. For now, setting the permission to allow others rw permission to the device works. I also changed owner for the scanner device and xsane recognized the scanner as a regular user. The file permissions were still set to 644 with jim as the owner. The problem seems to be that the usb device is mounted automatically as root being the owner. Since the device is mounted, a regular user cannot query for it, since it is only writable by root (the owner). I think that the scanner device has to somehow be writable by all users. How to do this is beyond my current knowledge. Hopefully, this will work for the Fedora Core 2 release. What they did for the 2.4 kernel to get scanners to work might need to be done for the new usb drivers that the 2.6 kernel uses to get it to work without manual trickery.
As mentioned previously, this needs to be handled in exactly the same way as USB cameras are now. This needs to be done with a hotplug script.
I have been trying to follow this bug report to get my Epson 1240U scanner to work in FC2T3 with no luck. Could someone post a complete step-by-step procedure that gets the scanners working either in this report, or to the fedora-test-list? Thanks. Gerry Tool
*** Bug 121893 has been marked as a duplicate of this bug. ***
From bug #121893: Hotplug correctly sets the permissions of USB devices (ie: /proc/bus/usb/001/*) when I plug in my digital camera. Hotplug gives read and write permissions to the console owner. However, the same is not true for scanners. Since the USB scanner kernel module was dropped some time ago in favor of libusb, scanners should be handled like digital cameras. This is how I got my scanner to work right: I added the following two lines to /etc/hotplug/usb.usermap (copied from /etc/hotplug/usb.distmap -- the map for old kernel modules): # Umax Astra 2200 scanner 0x0003 0x1606 0x0230 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000 Then I copied /etc/hotplug/usb/usbcam to /etc/hotplug/scanner and modified the script to reference scanners instead of cameras (actually a slight modification of the same script could probably be used in both cases).
Please tell us exactly which modification you needed to make to the script to get it to work -- I don't see anything camera-specific there, so I must be missing something.
I'm sorry, I should have been more clear in comment #19. The only thing in the script that is camera-specific is the comments. The actual logic of the script works fine out of the box with both scanners and cameras.
I noticed that this version was revised and has some script for USB hotplugging. http://www.sane-project.org/ I haven't downloaded the latest version and tried it yet. 2004-05-01: SANE-Backends-1.0.14 has been released * New backend: u12 * Updated backends: artec, artec_eplus48u, as6e, avision, canon630u, canon_pp, epson, fujitsu, gphoto2, gt68xx, hp, matsushita, mustek, mustek_pp, mustek_usb, plustek, plustek_pp, sm3600, snapscan, teco1, teco2, u12, umax, umax_pp, v4l. * Added scripts for USB hotplugging (Linux) The earlier update just stated that you need to change permissions as below. With Linux 2.4.* you could either use the kernel scanner module or libusb to access USB scanners. In Linux 2.6.4 the kernel scanner module was removed. Therefore with this and later kernels libusb must be used. While SANE automatically uses libusb when the library and its header file were present during the build of sane-backends, setting permissions will require some attention. The device files used by libusb are located in /proc/bus/usb/ (e.g. /proc/bus/usb/001/003). The exact file name can be found out by running sane-find-scanner which would print "libusb:001:003" in this case. While setting permissions with e.g. "chmod a+rw /proc/bus/usb/001/003" seems to work, this change is not permanent. The permissions will be reset when the scanner is replugged or Linux is rebooted. One solution to set permissions on-the-fly are the Linux hot-plug tools that should come with any current distribution. SANE itsself comes with a hotplug script and related documentaion in the tools/hotplug/ directory. Please refer to the README in that directory for the details. Jim
Please try the 1.0.13-6 package: ftp://people.redhat.com/twaugh/tmp/sane-backends/
This solution is better than having to become root and then change the file permissions as root. ls -la /proc/bus/usb/001/* shows the scanner after unplugging the scanner from the hub as 006 instead of 004 as it is when the system is booted up. (Of course 004 does not exist now.) Thanks for the addition to sane-backends. Jim (usb device permissions below, after replug of scanner) -rw-r--r-- 1 root root 43 May 4 20:53 /proc/bus/usb/001/001 -rw-r--r-- 1 root root 43 May 4 20:53 /proc/bus/usb/001/002 -rw-r--r-- 1 root root 50 May 4 20:53 /proc/bus/usb/001/003 -rw-r--r-- 1 root root 50 May 4 20:53 /proc/bus/usb/001/005 -rw------- 1 jim root 57 May 4 21:00 /proc/bus/usb/001/006
I installed the new rpm, rebooted, and nothign changed - scanimage -L still gives out just my tv-card. Any hints what to do? Must I add something somewhere? Roland
Roland: try powering off, and then on, the scanner after logging in.
You are right, to power off and power on the scanner helps, is there any possibility to avoid this? Roland
Suggestions welcome.
I see a new sane-backends package hit rawhide today... still same situation as before - works only after restarting the scanner... Perhaps sane backends 1.0.14 solves this? Any change it could be packaged before FC2 ships?
Yes, it is intentional that it only works when the scanner is attached after login. No better solution has presented itself. The upstream package uses a 'scanner' group -- which requires user intervention to set up. Eventually I think that pam_console (or something that invokes it) will need to get these hotplug scripts run again, to simulate unplug/insert events. Digital cameras have the same issue.
So pam_console should do something like this: for each hot-pluggable device: # brute removal seems deadly: export ACTION=remove export DEVPATH=/bus/usb/devices/<something> /sbin/hotplug usb.agent export ACTION=add export DEVPATH=/bus/usb/devices/<something> /sbin/hotplug usb.agent ? Is there an easier way to say "re-execute all agents for all hotplug devices?" Or better yet, "re-set the permissions on all hotplug devices?" Anyway, this seems like very important functionality because some USB devices may not be realistically usable without it.
Created attachment 100183 [details] Example code to find libusb device given vendor and product IDs Findusb.c is a simple program that prompts for a USB vendor and product ID and prints the path to the corresponding libusb device. This concept could be used to allow pam_console to properly set the permissions on libusb devices. The configuration syntax of pam_console could be modified to support lines like the following: <console> 0600 *1234-FEDC 0660 root.root In this case, 1234 would be a USB vendor and FEDC would be a USB product. * is a sort of "dereference" operator. Pam_console would then look up the corresponding libusb device given this information and properly set its permissions. To compile the example program: gcc -lusb findusb.c
Should this be filed against the pam package instead of sane-backends?
After looking at pam_console some more I have realized that the idea proposed in comment #32 could use some revising. It would be very neat if pam_console had some pre-defined file classes. For example, <libusb> could be recognized and cause /etc/hotplug/usb.usermap and /etc/hotplug/usb/*.usermap (just like /etc/hotplug/usb.agent) to be parsed for USB vendor and product IDs. These, in turn, could be used to determine the path respective libusb device (as described in comment #32). The permissions of the device could then be set. Here is an example configuration line from /etc/security/console.perms: <console> 0600 <libusb> 0600 root An alternative would be to handle <usbscanner>, <usbcamera>, etc. classes by parsing /etc/hotplug/usb.usermap or /etc/hotplug/usb/libsane.usermap. This may be easier to maintain but would make the permission handling more fine-grained. I would write a patch by I don't know lex, which is used by pam_console to parse console.perms!
This sounds like a good approach to me. Changed summary and component.
Eventually, udev will handle this.
All my steps to do my scanner usb work on fedora core 2. I think some of them aren't needed but I do all of them. [alpha:heberv] [~]$ sane-find-scanner found USB scanner (vendor=0x04a5 [Color], product=0x20b0 [ FlatbedScanner 23]) at libusb:002:003 [alpha:heberv] [~]$ scanimage -L device `snapscan:libusb:002:003' is a Acer FlatbedScanner23 flatbed scanner /etc/fstab: none /proc/bus/usb usbdevfs defaults,mode=777 0 0 [alpha:root] [/etc]$ rpm -qa | grep sane xsane-gimp-0.92-10 sane-backends-1.0.13-7 xsane-0.92-10 sane-frontends-1.0.11-4 [alpha:root] [/etc]$ ls -ld sane.d/ drwxr-xr-x 2 root root 4096 Jun 18 00:00 sane.d/ [alpha:root] [/etc/sane.d]$ ls -la *.bin -rw-rw-rw- 1 root root 30653 Jun 15 07:39 u176v042.bin /etc/sane.d/snapscan.conf: firmware /etc/sane.d/u176v042.bin /etc/rc.d/rc.local: chgrp users $(sane-find-scanner | grep '^found USB scanner' | sed -e 's?^.*libusb:?/proc/bus/usb/?' -e 's?:?/?') chmod 0777 $(sane-find-scanner | grep '^found USB scanner' | sed -e 's?^.*libusb:?/proc/bus/usb/?' -e 's?:?/?') /etc/hotplug/usb.usermap: # Acer Peripherals Inc.|S2W 3300U/4300U scanner 0x0003 0x04a5 0x20b0 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000 /etc/hotplug/usb/scanner: #!/bin/bash if [ "${ACTION}" = "add" ] && [ -f "${DEVICE}" ] then # New code, using lock files instead of copying /dev/console permissions # This also works with non-gdm logins (e.g. on a virtual terminal) # Idea and code from Nalin Dahyabhai <nalin> if [ -f /var/run/console.lock ] then CONSOLEOWNER=`cat /var/run/console.lock` elif [ -f /var/lock/console.lock ] then CONSOLEOWNER=`cat /var/lock/console.lock` else CONSOLEOWNER= fi if [ -n "$CONSOLEOWNER" ] then chmod 0000 "${DEVICE}" # chown "$CONSOLEOWNER" "${DEVICE}" chgrp users "${DEVICE}" chmod 0777 "${DEVICE}" fi fi [alpha:root] [/etc/hotplug/usb]$ ls -laR /proc/bus/usb/* /proc/bus/usb/002: total 0 -rwxrwxrwx 1 root users 57 Jun 18 01:07 003 If I don't use the scanner in some time it turn off automatically (or turn it off manually) and don't work as regular user, then I need to log as user and call it on xsane again... [alpha:root] [/etc/hotplug/usb]$ xsane [snapscan] Scanner warming up - waiting 21 seconds. [snapscan] Scanner warming up - waiting 21 seconds. But finally work!
chgrp users "${DEVICE}" chmod 0777 "${DEVICE}" Eek! I don't think we want to do that! The best solution I've seen, although it seems to be a work in progress, is to have that script make a symlink for /dev/scanner to point to the right place in /proc: http://sourceforge.net/mailarchive/message.php?msg_id=8617034
*** Bug 125612 has been marked as a duplicate of this bug. ***
*** Bug 131945 has been marked as a duplicate of this bug. ***
Moving to udev
nothing udev can do about that!
sorry, pam neither, maybe hotplug can? Note that there is /dev/scanner and /dev/usb/scanner* entry in console.perms.
Why wouldn't this be done in udev for things that match the proper vendor/device IDs for scanners?
udev is for /dev hotplug for the vendor/device, whatever... why not make this part of usb.agent? remember this is /proc/bus/usb/ !!
*** Bug 135803 has been marked as a duplicate of this bug. ***
re comment #37: Permissions 0777 are obviously excessive on a (pseudo)file in /proc/bus/usb/<something>/<something>. What do you want to execute on your scanner? But this is a perfect example what happens when you restrictive beyond reason in some security settings. Somebody will eventually break that wide open beyond all imaginable needs (one only wonders why suid, sid and sticky bits were not added too). The recipe asked for in comment #17 is utterly trivial: - make sure that you have an entry for your USB scanner in /etc/hotplug/usb/libsane.usermap (add one if needed) - in /etc/hotplug/usb/libusbscanner put 'chmod 0666 "${DEVICE}"' before the last closing 'fi'; if you need better access control then create a group 'scanner' (maybe both no-login user 'scanner' with a group 'scanner'), add all accounts authorized to use that device to a group 'scanner' and instead of 'chmod' above do 'chown scanner.scanner "${DEVICE}"; chmod 0660 "${DEVICE}"'. Whatever pam is happen to be doing is irrelevant. It took me the whole twenty minutes to get my new scanner going with FC2. That long because this was an "unknown scanner" to a version of sane included there. Even less with FC3test where also some small tweaks were still needed. Querry in bugzilla failed somehow to find that bug so I added https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135803 with a bit more of details. It looks from this long discussion that I was lucky that my bugzilla search found nothing. :-) BTW - the scanner works very nicely and even some persons around here, who usually need to be shown things a few times, got themselves beautiful scans when I was away. :-)
Are there any plans to actually fix this? You know, it's not like USB scanners are common or anything.
Created attachment 106546 [details] Modified usb.agent script Modified version of /etc/hotplug/usb.agent script. The current version of this script uses readlink to set the value of the REMOVER variable (see line 347). This blows up when the sysfs entry no longer exists, which is the case during a USB remove event. I've changed the script to use a simple echo. This makes REMOVER work for me during USB remove events, but I'm not sure that it doesn't have negative consequences that I'm not seeing. (And I've been told that asking about it on the linux-hotplug-devel list is "flamebait".) REVIEW BY SOMEONE WHO UNDERSTANDS THE HOTPLUG SYSTEM IS REQUIRED!
Created attachment 106547 [details] Modified libusbscanner script Modified version of /etc/hotplug/usb/libusbscanner. When used with the modified usb.agent script, this makes my USB scanner work for non-root users when it is "cold plugged". It creates a symlink, /dev/usb/scanner-BBB:DDD which points to the corresponding /proc/bus/usb/BBB/DDD file. This makes pam_console set the permissions of /proc/bus/usb/BBB/DDD when a "console user" logs on. When the scanner is cold plugged, the add event occurs before the root filesystem is writeable, before /dev/usb exists, or both. I've added a simple loop to wait until /dev/usb exists, and this seems to work my my system, but, as with the modified usb.agent script, it really needs to be reviewed by someone who understands the hotplug system. Can we please get this fixed now?
BTW, the version of this bug needs to be updated to FC3.
For what its worth: the folks who are working on gnome-volume-manager and hal-cups-utils seem to be considering this issue with USB devices already being plugged in when a user logs in. See bug #132388, comment 19.
*** Bug 139203 has been marked as a duplicate of this bug. ***
The libusbscanner part looks sane to me: I've built sane-backends-1.0.15-2 in Fedora development. (Thanks!)
hotplug part added in -10.
I hope that people realize that in a lot of instances scanners are used by others than the console login user. I think scanners are more similar to printers than they are to cameras (they are accessed by multiple users and normally are always connected to the computer). I think that using the sane daemon "saned" with a secure initial setup (similar to cups) may be the best approach. In any case, tying the scanner to the console login user is not the correct answer.
re comment #56: You do not need an extra daemon _if_ pam does adjust correctly initial permissions and permissions after every hotplug event. What they should be is a matter of a local policy and adjustable _then_ in /etc/security/console.perms. I agree that 0600 for an initial default is missing the point. What that default should be is a matter for a discussion but probably an extra group like 'scanner' and 0660 would be a reasonable compromise. You can find in /etc/security/console.perms examples of such arrangements for other devices. With that you have a control over which accounts can, or cannot, use that scanner. In a specific situtation 0666 configuration could be what is really needed but that may be too loose for a general default (although I do not see right now what harm that can do with a scanner plugged and powered up).
0666 can do harm if a confidential document is left in a scanner. The document is then world readable. It is also possible for a remote user to grab a copy of a document during active use. This could be a real problem in an office using NIS login, where any user can log onto any machine.
I think that leaving a confidential document on a scanner is âworld readableâ by default :). The same as leaving one on a printer or copier. So I really don't see a problem with 0666 except for firmware issues. In any case, PAM doesn't do it for people that want to share a scanner with those close by. For instance we have several scanners within our office that have auto-feeders for archiving and saving documents. These are used in the same manner as a printer would be (when is someone going to make a âJetDirectâ like scanner that is network plug and play). If the daemon is used in a default fedora setup I hope it would be initially configured to only accept connections from localhost (similar to cups).
I think the question is whether saned has been audited recently. Can anyone confirm that the pam_console fix works?
This seems to work for me. The permissions of my scanner are changed even when it was plugged in before I log in. However, Fedora's strict SELinux policy seems to break this. This is a SELinux policy issue and I will have to look into it another time. So as far as this bug report goes, this looks fixed. Thanks!
It would be useful to have the audit messages. If you open a separate bug report for this could you add a comment here with the bug number? Thanks.
See bug #140059 for documentation about the SELinux issue. I hope to add more to this bug over the weekend.
Seems like the libusbscanner script doesn't handle the case of there being no other USB devices on the system. In that situation, /dev/usb will never be created and the libusbscanner script will wait indefinitely. Should it just make /dev/usb like this?: mkdir -m 0755 -p /dev/usb ..or will that make the SELinux situation even worse?
Note that the script currently uses the existence of /dev/usb as a signal that udev is up and running. If you simply create /dev/usb in /dev, you risk doing it before udev is mounted on /dev. Too bad none of the gurus on the hotplug mailing list will deign to talk to mere users.
How about looping to wait for 'mount' to say it's mounted?
Scanner (Epson 1240U) still not detected for me with latest rawhide sane-backends and hotplug installed. [root@gstpc-fc3 ~]# rpm -q sane-backends sane-backends-1.0.15-2 [root@gstpc-fc3 ~]# rpm -q hotplug hotplug-2004_04_01-10 Scanner is not recognized until I execute a script to change permissions, even if another USB device (USB flash drive) is active. [root@gstpc-fc3 ~]# ls /dev/usb ls: /dev/usb: No such file or directory [root@gstpc-fc3 ~]# ps axf | grep sleep 4124 ? S< 0:00 | \_ sleep 1 4126 pts/2 S+ 0:00 \_ grep sleep [root@gstpc-fc3 ~]# ps axf | grep libusbscanner 1336 ? S< 0:00 | \_ /bin/bash /etc/hotplug/usb/libusbscanner 4132 pts/2 S+ 0:00 \_ grep libusbscanner I try to Acquire in Gimp at this point, and it fails to find scanner. [root@gstpc-fc3 ~]# cat /usr/local/bin/fixscan chmod a+w /proc/bus/usb/003/002 [root@gstpc-fc3 ~]# fixscan Acquire with Gimp now works. No change in above queries. [root@gstpc-fc3 ~]# ls /dev/usb ls: /dev/usb: No such file or directory [root@gstpc-fc3 ~]# ps axf | grep sleep 4210 ? S< 0:00 | \_ sleep 1 4212 pts/2 R+ 0:00 \_ grep sleep [root@gstpc-fc3 ~]# ps axf | grep libusbscanner 1336 ? S< 0:00 | \_ /bin/bash /etc/hotplug/usb/libusbscanner 4219 pts/2 S+ 0:00 \_ grep libusbscanner
Can you please try these packages from rawhide?: sane-backends-1.0.15-7 hotplug-2004_04_01-10 pam-0.78-2 If they work I would like to organise an official update for FC3. If they don't, well we need to fix it!
Upgraded with sane-backends-1.0.15-8 ad the -7 version is no longer available. Upgraded hotplug and pam as shown above. Upgraded to db4-3.21-1 as this was required by pam-0.78-2. Replaced pam.d/system-auth with new version. Left unchanged modifications to dll.conf and epson.conf. Used --force to upgrade db4. With the above steps scanimage and xsane work as desired. There appears to be some breakage as a result of the forced upgrade of db4. I have not attempted to complete the upgrade dependency chain caused by the db4 replacement.
Use packages from FC 3 updates/testing they won't require new db4 so you can downgrade it back to FC3 version.
Retested with the following packages from /pub/fedora/linux/core/updates/testing/3/i386/ hotplug-2004_04_01-8.1.i386.rpm pam-0.77-66.1.i386.rpm sane-backends-1.0.15-1.4.i386.rpm Restored db4-4.2.52-6.i386.rpm and used rpmnew versions of dll.conf and epson.conf. scanimage -L and xsane work correctly. This is a good fix.
The updates fixed the problem for me as well on my x86_64 system: Dec 15 10:21:10 Updated: pam.x86_64 0.77-66.1 Dec 15 10:21:11 Updated: hotplug.x86_64 3:2004_04_01-8.1 Dec 15 10:21:16 Updated: sane-backends.x86_64 1.0.15-1.4 Dec 15 10:21:18 Updated: sane-backends.i386 1.0.15-1.4 Dec 15 10:21:21 Updated: pam.i386 0.77-66.1 Dec 15 10:21:21 Updated: pam-devel.x86_64 0.77-66.1 The only oddity was the creation of a number of .rpmnew files, all of which appear to be identical to the existing config files. I don't know if this is the expected or correct behavior: Updating: sane-backends 100 % done 3/12 warning: /etc/sane.d/abaton.conf created as /etc/sane.d/abaton.conf.rpmnew warning: /etc/sane.d/agfafocus.conf created as /etc/sane.d/agfafocus.conf.rpmnewwarning: /etc/sane.d/apple.conf created as /etc/sane.d/apple.conf.rpmnew warning: /etc/sane.d/artec.conf created as /etc/sane.d/artec.conf.rpmnew warning: /etc/sane.d/artec_eplus48u.conf created as /etc/sane.d/artec_eplus48u.conf.rpmnew warning: /etc/sane.d/avision.conf created as /etc/sane.d/avision.conf.rpmnew warning: /etc/sane.d/bh.conf created as /etc/sane.d/bh.conf.rpmnew warning: /etc/sane.d/canon.conf created as /etc/sane.d/canon.conf.rpmnew warning: /etc/sane.d/canon630u.conf created as /etc/sane.d/canon630u.conf.rpmnewwarning: /etc/sane.d/canon_pp.conf created as /etc/sane.d/canon_pp.conf.rpmnew warning: /etc/sane.d/coolscan.conf created as /etc/sane.d/coolscan.conf.rpmnew warning: /etc/sane.d/coolscan2.conf created as /etc/sane.d/coolscan2.conf.rpmnewwarning: /etc/sane.d/dc210.conf created as /etc/sane.d/dc210.conf.rpmnew warning: /etc/sane.d/dc240.conf created as /etc/sane.d/dc240.conf.rpmnew warning: /etc/sane.d/dc25.conf created as /etc/sane.d/dc25.conf.rpmnew warning: /etc/sane.d/dll.conf created as /etc/sane.d/dll.conf.rpmnew warning: /etc/sane.d/dmc.conf created as /etc/sane.d/dmc.conf.rpmnew warning: /etc/sane.d/epson.conf created as /etc/sane.d/epson.conf.rpmnew warning: /etc/sane.d/fujitsu.conf created as /etc/sane.d/fujitsu.conf.rpmnew warning: /etc/sane.d/gt68xx.conf created as /etc/sane.d/gt68xx.conf.rpmnew warning: /etc/sane.d/hp.conf created as /etc/sane.d/hp.conf.rpmnew warning: /etc/sane.d/hp5400.conf created as /etc/sane.d/hp5400.conf.rpmnew warning: /etc/sane.d/hpsj5s.conf created as /etc/sane.d/hpsj5s.conf.rpmnew Updating: sane-backends 1 % done 4/warning: /etc/sane.d/ibm.conf created as /etc/sane.d/ibm.conf.rpmnew warning: /etc/sane.d/leo.conf created as /etc/sane.d/leo.conf.rpmnew warning: /etc/sane.d/ma1509.conf created as /etc/sane.d/ma1509.conf.rpmnew warning: /etc/sane.d/matsushita.conf created as /etc/sane.d/matsushita.conf.rpmnew warning: /etc/sane.d/microtek.conf created as /etc/sane.d/microtek.conf.rpmnew warning: /etc/sane.d/microtek2.conf created as /etc/sane.d/microtek2.conf.rpmnewwarning: /etc/sane.d/mustek.conf created as /etc/sane.d/mustek.conf.rpmnew warning: /etc/sane.d/mustek_pp.conf created as /etc/sane.d/mustek_pp.conf.rpmnewwarning: /etc/sane.d/mustek_usb.conf created as /etc/sane.d/mustek_usb.conf.rpmnew warning: /etc/sane.d/nec.conf created as /etc/sane.d/nec.conf.rpmnew warning: /etc/sane.d/net.conf created as /etc/sane.d/net.conf.rpmnew warning: /etc/sane.d/pie.conf created as /etc/sane.d/pie.conf.rpmnew warning: /etc/sane.d/plustek.conf created as /etc/sane.d/plustek.conf.rpmnew warning: /etc/sane.d/plustek_pp.conf created as /etc/sane.d/plustek_pp.conf.rpmnew warning: /etc/sane.d/qcam.conf created as /etc/sane.d/qcam.conf.rpmnew warning: /etc/sane.d/ricoh.conf created as /etc/sane.d/ricoh.conf.rpmnew warning: /etc/sane.d/s9036.conf created as /etc/sane.d/s9036.conf.rpmnew warning: /etc/sane.d/saned.conf created as /etc/sane.d/saned.conf.rpmnew warning: /etc/sane.d/sceptre.conf created as /etc/sane.d/sceptre.conf.rpmnew warning: /etc/sane.d/sharp.conf created as /etc/sane.d/sharp.conf.rpmnew warning: /etc/sane.d/snapscan.conf created as /etc/sane.d/snapscan.conf.rpmnew warning: /etc/sane.d/sp15c.conf created as /etc/sane.d/sp15c.conf.rpmnew warning: /etc/sane.d/st400.conf created as /etc/sane.d/st400.conf.rpmnew warning: /etc/sane.d/tamarack.conf created as /etc/sane.d/tamarack.conf.rpmnew warning: /etc/sane.d/teco1.conf created as /etc/sane.d/teco1.conf.rpmnew warning: /etc/sane.d/teco2.conf created as /etc/sane.d/teco2.conf.rpmnew warning: /etc/sane.d/teco3.conf created as /etc/sane.d/teco3.conf.rpmnew Updating: sane-backends 1 % done warning: /etc/sane.d/test.conf created as /etc/sane.d/test.conf.rpmnew warning: /etc/sane.d/u12.conf created as /etc/sane.d/u12.conf.rpmnew warning: /etc/sane.d/umax.conf created as /etc/sane.d/umax.conf.rpmnew warning: /etc/sane.d/umax1220u.conf created as /etc/sane.d/umax1220u.conf.rpmnewwarning: /etc/sane.d/umax_pp.conf created as /etc/sane.d/umax_pp.conf.rpmnew warning: /etc/sane.d/v4l.conf created as /etc/sane.d/v4l.conf.rpmnew Updating: sane-backends 100 % done 4/12 warning: /etc/pam.d/other created as /etc/pam.d/other.rpmnew warning: /etc/security/access.conf created as /etc/security/access.conf.rpmnew warning: /etc/security/chroot.conf created as /etc/security/chroot.conf.rpmnew warning: /etc/security/group.conf created as /etc/security/group.conf.rpmnew warning: /etc/security/limits.conf created as /etc/security/limits.conf.rpmnew warning: /etc/security/opasswd created as /etc/security/opasswd.rpmnew warning: /etc/security/pam_env.conf created as /etc/security/pam_env.conf.rpmnewwarning: /etc/security/time.conf created as /etc/security/time.conf.rpmnew
Boris: thanks for the feedback. These multilib conflicts are noted in bug #135172.
I tried out the scanner today and it worked without any additionals steps needed. This is much nicer from a user experience. sane-backends-1.0.15-1.4 hotplug-2004_04_01-8.1 pam-0.77-66.1 I did not have any package conflict issues.
My epson 1240u scanner will still not work without a change of permissions as root. I have [root@gstpc-fc3 ~]# rpm -q sane-backends sane-backends-1.0.15-2 #from normal updating [root@gstpc-fc3 ~]# rpm -q hotplug hotplug-2004_04_01-10 #from normal updating [root@gstpc-fc3 ~]# rpm -q pam pam-0.77-66.1 #downloaded and installed by me To make it available, I execute chmod a+w /proc/bus/usb/003/002 What am I missing? A reboot didn't help.
Gerry: not sure how you ended up with sane-backends-1.0.15-2: that's the wrong one. Get the package from FC3 updates-testing: 1.0.15-1.4.
Thanks, Tim. Downgrading to sane-backends-1.0.15-1.4 fixed it. I coudn't get around to trying your fix until this morning and by then, normal updates as prompted by the rhn applet had installed sane-backends-1.0.15-2.
I'm using a HP psc2110 multi-function usb dev. with an update as shown usb scanning will not work. [david@reddwarf ~]$ rpm -qa | grep sane sane-frontends-1.0.12-4 sane-backends-1.0.15-1.4 sane-backends-devel-1.0.15-1.4 xsane-gimp-0.92-13 xsane-0.92-13 [david@reddwarf ~]$ rpm -qa | grep hotplug hotplug-2004_04_01-8.1 [david@reddwarf ~]$ rpm -qa | grep pam pam_passwdqc-0.7.5-2 pam-0.77-66.1 pam_smb-1.1.7-5 pam_krb5-2.1.2-1 pam_ccreds-1-3 pam-devel-0.77-66.1 [david@reddwarf ~]$ sane-find-scanner found USB scanner (vendor=0x03f0 [Hewlett-Packard], product=0x2811 [PSC 2100 Series]) at libusb:003:004 [david@reddwarf ~]$ scanimage -L No scanners were identified. chmod a+w /proc/bus/usb/003/004 makes no difference
david walcroft: you need to install libsane-hpoj and set up hpoj. Your problem is not related to this bug report.
Hi - just my $0.02: I've got a fresh install and fully-patched version of fc3. I was experiencing the same permission problems when using SANE with my epson 1240U scanner. Upgrading to the following versions of hotplug and sane-backends (from updates testing) solved the problem. I can now scan from a non-root user account. Thanks! hotplug-2004_04_01-8.1 sane-backends-1.0.15-1.4 (pam is already patched to pam-0.77-66.1 after up2date patching) -K
Reply to #79. Thanks Tim it works now and will test later
Hello, I have a Canon 5000F USb scanner. It does not work under FC3. I tried the the pacjakes mentioned in e.g. in #74: root@hopkins ~]rpm -q sane-backends sane-backends-1.0.15-1.4 [root@hopkins ~]# rpm -q hotplug hotplug-2004_04_01-8.1 [root@hopkins ~]# rpm -q pam pam-0.77-66.1 Then: [root@hopkins ~]# sane-find-scanner # No SCSI scanners found. If you expected something different, make sure that # you have loaded a SCSI driver for your SCSI adapter. # Also you need support for SCSI Generic (sg) in your operating system. # If using Linux, try "modprobe sg". found USB scanner (vendor=0x04a9 [Canon], product=0x2212 [CanoScan]) at libusb:001:003 # Your USB scanner was (probably) detected. It may or may not be supported by # SANE. Try scanimage -L and read the backend's manpage. # Not checking for parallel port scanners. # Most Scanners connected to the parallel port or other proprietary ports # can't be detected by this program. root@hopkins ~]# scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). I tried to make a new backend for this scanner modifying canon630u.conf root@hopkins sane.d]# cat canon5000f.conf # Options for the canonusb backend # Autodetect the Canon CanoScan 5000F usb 0x04a9 0x2212 # device list for non-linux-systems (enable if autodetect fails): #/dev/scanner #/dev/usb/scanner0 The results was the same. Janos Lichtenberger
This bug report is for permissions problems, which I think are now fixed. Please open a separate bug report for backend problems. thanks.
> I have a Canon 5000F USb scanner. It does not work under FC3 ... > found USB scanner (vendor=0x04a9 [Canon], product=0x2212 [CanoScan]) > at libusb:001:003 ... > # scanimage -L > No scanners were identified. This a typical response from 'scanimage' when a scanner was actually identified but you do not have __write__ permissions on a needed device node. In the case above on /proc/bus/usb/001/003. This may happen when: a. /etc/hotplug/usb/libsane.usermap is missing an entry for your scanner and you have add one yourself (not the case here AFAICS) b. /etc/hotplug/usb/libusbscanner does not run, or is "old", or is messed up by some other reasons; run yourself providing required arguments and see what happens c. <scanner> entry in /etc/security/console.perms is of such sort that results are not writable d. if you checked all the above and perms on /proc/bus/usb/001/003, or whatever that may be in a given moment, are indeed correct that, as Tim says, this is something else and open a new bug.
('scanimage -L' had been run as root, and so it is not a permissions issue.)
Created attachment 109660 [details] A patch to /etc/security/console.perms that solves the bug for me.
The file /dev/scanner* is a symbolic link to the file that needs its ownership changed: $ ls -l /dev/scanner*;ls -Ll /dev/scanner* lrwxrwxrwx 1 root root 21 Jan 12 14:08 /dev/scanner-usb-:proc:bus:usb:005:006 -> /proc/bus/usb/005/006 -rw------- 1 nicku root 50 Jan 12 14:08 /dev/scanner-usb-:proc:bus:usb:005:006 The fix given in the patch above changes one line in /etc/security/console.perms from: <scanner>=/dev/scanner /dev/usb/scanner* to <scanner>=/dev/scanner* /dev/usb/scanner* Is there any security problem that anyone can see in this simple fix? All the other solutions just seem like too much work to me.
Nick: this change does not apply to the console.perms shipped with Fedora Core 3 in the pam package. That file already has /dev/scanner*. This bug remains open only because the SELinux bug it depends on is not confirmed closed.
*** Bug 124053 has been marked as a duplicate of this bug. ***
*** Bug 132194 has been marked as a duplicate of this bug. ***
I'm getting upset...I know this is not good for finding a solution. But I have customers waiting for the ability to use their desktop scanners as a normal user. I have tried the suggestions listed here to no avail. I'm using a fully updated version of FC4 with "updates-testing" enabled in order to take advantage of the updates to packages hotplug and sane-backends. My scanner is an "Epson Perfection 4870" USB scanner. I have tried modifying the console.perms file. And a few other ideas listed in this bugzilla entry...but nothing works. I can still use the scanner as root, but not as arthur. I thought this would be fixed long ago.
ok...was able to use lsusb to find the proper device and use Konqueror to change the permissions quickly and easily to get GIMP able to acquire. But this is NOT a good solution because turning the scanner off and back on puts me back at square one. I have found solutions to a few other bugs in FC4 and this one is the "last one" that I need to solve before heartily recommending FC4 to novice computer users. I was successful in getting Sun's version of JRE, J2SE, J2EE, and NetBeans all working perfectly...so I can visit websites with Java stuff. And I fixed the sound for Flash by deleting the file libnullplugin.so in /usr/lib/firefox-1.0.7/plugins directory before auto-installing the plugin. Then I fixed the automounting of floppies and CD's. So I do have some skill. But this scanner thing is driving me nuts.
I finally decided to give the "development" channel a try and found newer versions of hotplug and sane* packages, but all of the sane* packages fail on a long list of dependencies. So I left the sane* packages uninstalled. With the development version of hotplug installed the problem remains.
Closing this as a dup, as I posted some potential fixes in the other bug (sorry, didn't see this one first.) Testers needed, though, as I don't have the hardware. *** This bug has been marked as a duplicate of 177650 ***
With the changes to console, the HP scanner that I use works fine and permissions do not need to be set. I will examine bug 177650 to see if similar to this problem.