Using URC6440 and OARUSB04G Remotes with Linux: Difference between revisions

From JP1 Remotes Wiki
Jump to navigationJump to search
Davecs (talk | contribs)
No edit summary
m 38 revisions imported
 
(26 intermediate revisions by 2 users not shown)
Line 1: Line 1:
When you connect a JP1.x type remote to a Linux computer, running RMIR, all should be well. If RMIR can't find your remote, it may well be a permissions problem. This is currently being investigated and any updates will be posted to this page. If all else fails, you might have to set up RMIR so that it runs as root.
When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!


However, when you connect a USB remote to your computer, it connects by creating a "device" that you can mount. In many cases it will mount automatically, and the RMIR program will find it automatically. You will not need to take any special action, just Plug and Play. If that's the case, you don't need to read this section further. In other cases, it may not mount. This seems to be a problem with the OARUSB04G or URC-6440, when using recent releases of Linux. This is thought to be because the file system on these two remotes does not fully conform to standards. The problem is that it wasn't documented what you have to do if it doesn't mount... until now.
The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.


The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" shortcut that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.
That path is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''


That shortcut is: '''/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1'''
It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the '''mount''' command.


It's not very short for a shortcut, but it will always be the same, so we can make use of it in the '''mount''' command.
=Automatic Method=


==One User at a Time Method==
===Mounting===


The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.
Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- there are two lines, by the way.  


Create the following script and store it under '''/etc/udev/rules.d''' with a name of your choice, such as '''62-usbremote.rules''' -- it's all one line, by the way.
ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
 
  ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"
  ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"


The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".
The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".


This next script serves merely to return control to the udev system as quickly as possible, hence the '''&''' at the end of the line. I've called it '''mount_ofa_setup''' and it goes in '''/usr/local/bin'''. It must be made executable:
This next script will mount your remote. I've called it '''mount_ofa''' and it goes in '''/usr/local/bin'''. It must be owned by '''root''' and made executable: Although the mount will be owned by root, there will be read-write access to all users:


  #!/bin/bash
  #!/bin/bash
  /usr/local/bin/mount_ofa &
  mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000
 
The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.
 
After a reboot, your remote will be mounted automatically whenever it is plugged in (but see next section re systemd). RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:
 
Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin
 
===systemd===
 
The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a folder called '''/usr/lib/systemd/system/''' (or /lib/systemd/system/ — due to symlinks, it's often the same folder) containing a file called '''systemd-udevd.service'''. As root, you need to copy it to the folder '''/etc/systemd/system''' and then edit one or two lines in it as follows:
 
1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''
 
2. If there is a line that reads '''SystemCallFilter=@system-service @module @raw-io bpf''', change it to '''SystemCallFilter=@system-service @mount @module @raw-io bpf''' but don't do anything if it's not there.
 
The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.
 
===Unmounting===


This next script does the actual job. It also goes in '''/usr/local/bin''' and is called '''mount_ofa''' and must be made executable:
This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it '''umount_ofa''' and it also goes in '''/usr/local/bin''', and must be owned by '''root''' and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:


  #!/bin/bash
  #!/bin/bash
  hisname=`who | head -n1 | awk '{print $1;}'`
  sleep 1
  mkdir -p /media/$hisname/REMOTE
  umount /media/REMOTE/
  chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
  sleep 1
<span style="color:red">mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
rmdir /media/REMOTE
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137</span>
 
   
It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that '''rmdir''', without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.
NOTE: The lines in <span style="color:red">RED</span> should be made into a single line when typed in. Make sure these is a space between '''part1''' and '''/media'''.
 
I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!
 
=Manual Method=
 
There is another way of mounting your remote, which you may prefer, and hopefully will work if the Automatic Method does not. This is done by creating a permanent mount point for your remote. For this to work, you will need to create a permanent mount point for it by adding a new folder as root. You can do this in a root file manager (create folder REMOTE inside /mnt) or in a terminal:
 
  sudo mkdir /mnt/REMOTE
 
su -c mkdir\ /mnt/REMOTE
 
Use the first of these if your distro supports '''sudo''' or the second if it does not.
 
Now you must edit the file /etc/fstab as root and add the following line:


After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.
/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /mnt/REMOTE vfat user,noauto,umask=0,nosuid,nodev,nofail,x-gvfs-show 0 0


Set up RemoteMasterIR to point to it correctly from its menus:
This line in fstab gives you permission as a user to mount and unmount the remote. To mount, the command is:


  Remote > Interface > JPS... > Other : /media/''your-user-name''/REMOTE/settings.bin
  mount /mnt/REMOTE


As with any USB-storage type interface, remember to un-mount it before unplugging, else data may get broken.
To unmount, the command is:


==Any User Method==
umount /mnt/REMOTE


The problem is that when you use su, sudo, gksu, and so on, to become root, the $USER variable is not changed, it will still return your username, but if it's run from UDEV, it will return root. If and when it has been determined how to get this to work for any user, this page will be updated.
There are so many variations between distros and desktop environments as to how you can add these commands to your menu, your panel or your desktop, so it is not possible to go into it here. This method has the advantage that you're not subject to future changes in systemd or udev policy. If you use this method, your remote will be mounted at '''/mnt/REMOTE''' and the file it uses, in RMIR, will be '''/mnt/REMOTE/settings.bin''' — the disadvantage is that you may end up with said file literally on your computer and not in the remote, if it somehow fails to mount.

Latest revision as of 18:52, 2 November 2025

When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!

The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.

That path is: /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1

It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the mount command.

Automatic Method

Mounting

Create the following script and store it under /etc/udev/rules.d with a name of your choice, such as 62-usbremote.rules -- there are two lines, by the way.

ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"

The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".

This next script will mount your remote. I've called it mount_ofa and it goes in /usr/local/bin. It must be owned by root and made executable: Although the mount will be owned by root, there will be read-write access to all users:

#!/bin/bash
mkdir /media/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000

The -o switch means "options" and those given, user and umask=0000 will ensure that any user can access the remote.

After a reboot, your remote will be mounted automatically whenever it is plugged in (but see next section re systemd). RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:

Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

systemd

The above will work if your Linux system does not run systemd. However, the majority of systems nowadays do. If you plug in your remote and the directory /media/REMOTE is created but there is nothing in it, then you probably have systemd. To check, use your File Manager to see if there is a directory at /usr/lib/systemd or /lib/systemd. In a small number of cases (for example MX-Linux) you get a choice of whether your system boots up with systemd or the more traditional sysV, and the above will work or not, depending on your choice! But there is a way to make the above work under systemd. If you have it there will be a folder called /usr/lib/systemd/system/ (or /lib/systemd/system/ — due to symlinks, it's often the same folder) containing a file called systemd-udevd.service. As root, you need to copy it to the folder /etc/systemd/system and then edit one or two lines in it as follows:

1. Change the line PrivateMounts=yes to PrivateMounts=no

2. If there is a line that reads SystemCallFilter=@system-service @module @raw-io bpf, change it to SystemCallFilter=@system-service @mount @module @raw-io bpf but don't do anything if it's not there.

The entry in /etc/ has priority over the entry in /usr/lib/, and will not be overwritten by your operating system. After a reboot, your remote will be automatically mounted. I've noticed an occasional error saying it's already mounted (even though it wasn't), but that doesn't really matter.

Unmounting

This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it umount_ofa and it also goes in /usr/local/bin, and must be owned by root and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:

#!/bin/bash
sleep 1
umount /media/REMOTE/
sleep 1
rmdir /media/REMOTE

It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that rmdir, without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.

I have no reason to doubt that this will work on many versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I use regularly actually use both. The thing is that there should be a rules.d folder somewhere!

Manual Method

There is another way of mounting your remote, which you may prefer, and hopefully will work if the Automatic Method does not. This is done by creating a permanent mount point for your remote. For this to work, you will need to create a permanent mount point for it by adding a new folder as root. You can do this in a root file manager (create folder REMOTE inside /mnt) or in a terminal:

sudo mkdir /mnt/REMOTE
su -c mkdir\ /mnt/REMOTE

Use the first of these if your distro supports sudo or the second if it does not.

Now you must edit the file /etc/fstab as root and add the following line:

/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /mnt/REMOTE vfat user,noauto,umask=0,nosuid,nodev,nofail,x-gvfs-show 0 0

This line in fstab gives you permission as a user to mount and unmount the remote. To mount, the command is:

mount /mnt/REMOTE

To unmount, the command is:

umount /mnt/REMOTE

There are so many variations between distros and desktop environments as to how you can add these commands to your menu, your panel or your desktop, so it is not possible to go into it here. This method has the advantage that you're not subject to future changes in systemd or udev policy. If you use this method, your remote will be mounted at /mnt/REMOTE and the file it uses, in RMIR, will be /mnt/REMOTE/settings.bin — the disadvantage is that you may end up with said file literally on your computer and not in the remote, if it somehow fails to mount.