Only works as root

Bug #48871 reported by evilhamsterman on 2006-06-07
Affects Status Importance Assigned to Milestone
libifp (Ubuntu)

Bug Description

Binary package hint: libifp4

Any program trying to use libifp while not in root mode is unable to access Iriver devices. For example the ifp program from ifp-line-libifp returns
"Device is busy. (I was unable to claim its interface.)"
Amarok 1.4 just doesn't see it
Ifpgui says "Could not communicate with iRiver device."

However all the programs work fine when run in root mode. There are many other people having the same issue in the forums, that solved it by switching to the UMS firmware which makes the device appear as a harddrive. But that is a cop-out way of doing it, the managed mode is faster and has more functions such as the ability to program radio stations. The support is there in libifp it just needs to work as a regular user.

Jonathan B. Wiebe (jbwiebe) wrote :

I can confirm this bug. I have found that immediately upon plugging my iRiver iFP-780 player into a usb port the rhythmbox application is launched automatically. However there is no obvious way to access my player from rhythmbox. From a terminal the output is as follows:

jonathan@gideon$ ifp ls
Device is busy. (I was unable to claim its interface.)
jonathan@gideon$ sudo ifp ls
wrn: [ifp_delta] interesting, there were only 4 bytes.
Detected: model IFP-780, firmware 1.21, battery =[####], delta

Browsing the Debian bug database I found this bug reported there as Bug Report #355051. The bug is marked as closed with the upload of libifp version

The bug report also contains this comment:
You also need udev > 0.079-080+1, which contains the up-to-date udev rules for ensuring the device has the
proper permissions.

Is there any chance of getting these bug fixes into the dapper repositories? I can access my player using sudo but obviously I would prefer not to use root privileges if I don't have to.

Thanks for your help,

Jonathan Wiebe

Jonathan B. Wiebe (jbwiebe) wrote :

I have investigated this bug a little bit further. Please keep in mind that I am NOT a seasoned developer, just a user.

Since the Debian bug report mentioned a change in the udev permission rules I started by looking in the Debian udev changelog. From the following page:

I went to the changlog and searched for a reference to iRiver. I found the following changes to the file


+# usbfs-like devices
+SUBSYSTEM=="usb_device", MODE="0664"
+# iRiver music players
+SUBSYSTEM=="usb_device", GROUP="plugdev", \
+ SYSFS{idVendor}=="4102", SYSFS{idProduct}=="10[01][135789]"

In Ubuntu Dapper the udev package installs the following file:


and looking in this file I found this line (similar to the first line above):

# USB devices (usbfs replacement)
SUBSYSTEM=="usb_device", MODE="0664"

however there was no reference in this file to an iRiver player.

I backed up the file and then edited the file as root, adding the lines referring to the iRiver player.

Now when I plug in my iRiver player to a usb port rhythmbox still auto-launches but I can now access my player as a regular (non-root) user.

jonathan@gideon:/etc/udev/rules.d$ ifp ls
wrn: [ifp_delta] interesting, there were only 4 bytes.
Detected: model IFP-780, firmware 1.21, battery =[####], delta

I still don't know what to do about the warning message or the auto-launching of rhythmbox but I am happy to report that I have non-root access to my flash player again.

I hope the preceeding has been helpful. If you need any more information from me don't hesitate to ask.


Jonathan Wiebe

Changed in libifp:
status: Unconfirmed → Confirmed
John Steele Scott (toojays) wrote :

Thanks for your comment Jonathan. It has helped me with the permissions issue.

To stop rhythmbox from automatically popping up, go to System->Preferences->"Removable Drives and Media", select the multimedia tab, and clear the box that says "Play music files when connected".

drberg1000 (drberg1000) wrote :

This is still a problem in edgy and feisty. Does this fix need to be made to udev or libifp? I'd be happy to do the work of uploading a patch, just point me in the right direction.


Adam Kessel (ajkessel) wrote :

Fix above works for me. Makes sense that the fix would be for udev rather than libifp; although I guess it's possible for other packages to provide /etc/udev/rules.d/* files. So libifp could just have a standalone stanza in a new rules.d file with the permissions fix. Still I think it would be better for it to be changed in udev, since not all iriver users necessarily will use libifp.

Changed in libifp:
importance: Undecided → Medium
Changed in libifp:
status: Confirmed → Triaged
Patrick Den (pat31) wrote :

This problem is still in 7.10 (Gutsy Gibbon)
See my message at Bug #42437

Daniel T Chen (crimsun) on 2008-09-13
Changed in libifp:
importance: Medium → Undecided
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers