Fujitsu ScanSnap IX500 scanner stopped working, possibly on upgrade from Debian jessie to stretch

Question

My ScanSnap IX500 stopped working recently, possibly on upgrade from Debian jessie to stretch.

Per the documentation in http://www.sane-project.org/man/sane-fujitsu.5.html I set the environmental variable SANE_DEBUG_FUJITSU=5and then ran xsane, I got:

fujitsu] sane_init: fujitsu backend 1.0.127, from sane-backends 1.0.25
[fujitsu] sane_get_devices: config option "buffer-size" (262144) is > 65536, warning!
[fujitsu] stat: return error 'Error during device I/O'
[fujitsu] WARNING: Brain-dead scanner. Hitting with stick 
[fujitsu] stat: return error 'Error during device I/O'
[fujitsu] WARNING: Brain-dead scanner. Hitting with stick again
[fujitsu] stat: return error 'Error during device I/O'
[fujitsu] wait_scanner: error 'Error during device I/O'
[fujitsu] connect_fd: could not wait_scanner

It shows up in lsusb as

Bus 004 Device 002: ID 04c5:132b Fujitsu, Ltd 

It shows up intermittently in scanimage -L, but currently it's showing:

SANE_DEBUG_FUJITSU=15 scanimage -L

[fujitsu] attach_one: start
[fujitsu] attach_one: looking for 'libusb:003:015'
[fujitsu] connect_fd: start
[fujitsu] connect_fd: opening USB device
[fujitsu] connect_fd: could not open device: 3
[fujitsu] connect_fd: finish

Why is it not working? How do I fix it?

Note: the scanner is plugged into a USB 2 slot. I earlier had it plugged into a USB 3 slot. I tried switching it to a USB 2 slot because of some reports that USB 3 was the problem, but it's still not working.

See for example the bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=1297169 and http://sane-devel.alioth.debian.narkive.com/kLQc0Aik/fujitsu-ix500-no-scanners-were-identified

In any case, a USB device should work regardless whether it's plugged into a USB 2 or USB 3 slot.

Thanks to Anthony (@derobert) for assistance debugging this.

It seems likely that sane-backends is the problem, and that downgrading or upgrading it will make the problem go away. stretch is using 1.0.25-4.1, while jessie used 1.0.24-8+deb8u2, and experimental has 1.0.27-1~experimental2.

Also, unplugging it and then plugging it back in again seems to make it visible again for awhile. Which suggests the problem may not be with sane-backends and may be a USB issue.

Answer 1

I also had this problem migrating from Raspbian (based on Debian) Stretch to Buster, with a previously working scanbd setup.

EDIT: Someone wanted to edit my answer to be scandb, but it is indeed scanbd.

So far, I've discovered a few issues.

One issue seemed to be related to scanbm.socket getting a "port already in use" error that seems to be because saned.socket was using the same port; using systemctl to stop and disable the latter seems to have worked for this (the service files are virtually identical).

The other issue was a permissions issue -- no devices found with scanimage -L, but the scanner was properly detected with sudo scanimage -L. Using sudo lsusb followed by ls -l /dev/bus/usb/BUSNUM/DEVNUM, I could see that the scanner was owned by root:saned, but grep saned /etc/group showed that the saned group had no members. There was however a scanner group that contained the saned user. This matches up with an option in the scanbd.conf file that asks about dropping privileges to a specific user and group (scanner being one of the suggestions).

I found a udev service file at /lib/udev/rules.d/99-saned.rules that was changing the permissions on matched USB devices to have the group saned. I copied this to /etc/udev/rules.d/99-saned.rules and modified it to use the group scanner instead of saned. I don't know if this udev rule changed between stretch and buster, but changing it and rebooting seems to have restored my ability to use scanbd.

Answer 2

I just exactly the same problem just now, with exactly the same symptoms, on upgrading from stretch (9.8) to Debian buster/testing.

I came across this thread, which mentioned the possibility that the scandb daemon was holding on to the scanner. To quote from the thread:

Found the culprit....
SANE DID work..... but I had scanbd installed too, so scanbd had the usb
connection with sane and kept the device locked.....
I disabled scanbd, as I remembered installing that and that it might
interfere with SANE... and so it did!

But the post didn't suggest any way to verify this hypothesis. I messed around for some time trying to figure out if I could use fuser with some device corresponding to the ScanSnap to see if scandb was indeed holding on to it, but could not figure out what device that should be. So finally I decided to just try removing scandb, which I was using, as far as I know, so I don't even know why it was installed. After doing

apt-get purge scandb

the scanner magically started responding. So if that wasn't the problem, it was one hell of a coincidence. So if you have similar problems, try that.

It looks like I did have scandb installed in stretch. As part of my upgrade from stretch to buster on 16th April, I see I have in term.log

Unpacking scanbd (1.5.1-4) over (1.4.4-1+b2) ...

As a tangent, when I was purging scanbd, I got a message asking whether the lines /etc/inetd.conf corresponding to sane-port should be removed. The default was no, so I went with that. But I'm not really clear what those lines are for, so if you know, please comment.

#:OTHER: Other services
sane-port stream tcp nowait saned /usr/sbin/scanbm scanbm
sane-port       stream  tcp     nowait  saned:saned     /usr/sbin/saned saned

Also, another indication that there might be something going on with scandb was that the messages about it in journalctl. journalctl goes back to 31st March, I started the install on the afternoon/evening of 15th April. But the first mention of scanbd in journalctl is on the early morning of 17th April, around the time my apt-get upgrade completed:

journalctl --unit=scanbd

Apr 17 00:52:18 orwell systemd[1]: Started Scanner button polling Service.
Apr 17 00:52:18 orwell scanbd[4942]: /usr/sbin/scanbd: dbus match type='signal',interface='org.freedesktop.Hal.Manager'
Apr 17 00:52:19 orwell scanbd[4942]: Created directory: /var/lib/snmp/mib_indexes
Apr 17 00:52:30 orwell scanbd[4942]: /usr/sbin/scanbd: no devices, not starting any polling thread
Apr 17 01:40:38 orwell scanbd[4942]: /usr/sbin/scanbd: dbus match type='signal',interface='org.freedesktop.Hal.Manager'
Apr 17 01:40:38 orwell scanbd[4942]: /usr/sbin/scanbd: no devices, not starting any polling thread
Apr 17 01:40:38 orwell systemd[1]: Stopping Scanner button polling Service...
Apr 17 01:40:39 orwell systemd[1]: scanbd.service: Succeeded.
Apr 17 01:40:39 orwell systemd[1]: Stopped Scanner button polling Service.

Finally, does anyone know how to figure out whether a process is holding on to a USB scanner, and if so, which one? I'd like to know.