Using URC6440 and OARUSB04G Remotes with Linux - Revision history

The Robman: 38 revisions imported

2025-11-02T18:52:49Z

38 revisions imported

← Older revision	Revision as of 18:52, 2 November 2025
(No difference)

Davecs: /* systemd */

2023-07-07T21:01:40Z

systemd

← Older revision		Revision as of 21:01, 7 July 2023
Line 32:		Line 32:
	===systemd===		===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 two lines in it as follows:		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'''		1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''

Davecs: /* systemd */

2023-07-07T21:01:01Z

systemd

← Older revision		Revision as of 21:01, 7 July 2023
Line 36:		Line 36:
	1. Change the line '''PrivateMounts=yes''' to '''PrivateMounts=no'''		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'''		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.		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.

Davecs: /* Mounting */

2023-07-07T20:59:54Z

Mounting

← Older revision		Revision as of 20:59, 7 July 2023
Line 26:		Line 26:
	The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.		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 (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:		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		Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

Davecs: /* Mounting */

2023-07-07T20:59:24Z

Mounting

← Older revision		Revision as of 20:59, 7 July 2023
Line 26:		Line 26:
	The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.		The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

	After a reboot, 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:		After a reboot, your remote will be mounted automatically (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		Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

Davecs: /* Mounting */

2023-07-07T20:58:03Z

Mounting

← Older revision		Revision as of 20:58, 7 July 2023
Line 26:		Line 26:
	The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.		The '''-o''' switch means '''"options"''' and those given, '''user''' and '''umask=0000''' will ensure that any user can access the remote.

	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:		After a reboot, 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		Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin

Davecs: /* Manual Method */

2023-07-06T12:59:34Z

Manual Method

← Older revision		Revision as of 12:59, 6 July 2023
Line 56:		Line 56:
	=Manual Method=		=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 or in a terminal:		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		sudo mkdir /mnt/REMOTE

Davecs: /* Automatic Method */

2023-07-03T19:00:18Z

Automatic Method

← Older revision		Revision as of 19:00, 3 July 2023
Line 8:		Line 8:

	=Automatic Method=		=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.		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.

Davecs: /* Automatic Method */

2023-07-03T15:43:46Z

Automatic Method

← Older revision		Revision as of 15:43, 3 July 2023
Line 8:		Line 8:

	=Automatic Method=		=Automatic Method=

	Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing is, that it was so simple to do once I got the information I needed.

	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''' -- there are two lines, by the way.

Davecs: Major change, remote One User At a Time method, substitute Manual Method.

2023-07-03T15:26:11Z

Major change, remote One User At a Time method, substitute Manual Method.

← Older revision		Revision as of 15:26, 3 July 2023
Line 54:		Line 54:
	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!		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!

	=~~One User at a Time~~ Method ~~(Deprecated)~~=		=Manual Method=

	~~This~~ is ~~an old method~~ which ~~works in single-user situations~~, ~~but is more complicated~~ and ~~may~~ not do so in a ~~computer used by multiple users with separate logins. It's left here for the time being, but may be removed~~ in ~~the future.~~		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 or in a terminal:

	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.		sudo mkdir /mnt/REMOTE

	~~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.~~		su -c mkdir\ /mnt/REMOTE

	~~ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015\|8020", RUN+="/usr/local/bin/mount_ofa_setup"~~		Use the first of these if your distro supports '''sudo''' or the second if it does not.

	~~The idProduct codes are 8015 for~~ the ~~URC6440~~ and ~~8020 for OARUSB04G, and putting a bar between them means "or".~~		Now you must edit the file /etc/fstab as root and add the following line:

	~~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~~:		/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

	~~#!/bin/bash~~		This line in fstab gives you permission as a user to mount and unmount the remote. To mount, the command is:
	~~/usr/local/bin/mount_ofa &~~

	~~This next script does the actual job. It also goes in '''~~/~~usr~~/~~local/bin''' and is called '''mount_ofa''' and must be made executable:~~		mount /mnt/REMOTE

	~~#!/bin/bash~~		To unmount, the command is:
	~~hisname=`who \| head -n1 \| awk '{print $1;}'`~~
	~~mkdir -p /media/$hisname/REMOTE~~
	~~chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE~~
	~~<span style="color:red">mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1~~
	~~/media/$hisname/REMOTE/ -o uid=`id -u $hisname`~~,~~gid=`id -g $hisname`,utf8,dmask=027,fmask=137</span>~~

	~~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'''.~~

	An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:		umount /mnt/REMOTE

	~~hisname=`who \| awk '/tty[17]/ {print $1;}'`~~		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.

	~~For PCLinuxOS users~~, or ~~if tty[17] returns blank~~, ~~try changing "[17]"~~ to ~~"8"~~. ~~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.~~

	~~Set up RemoteMasterIR to point to it correctly from its menus:~~

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

	~~Normally, with any USB-storage type interface,~~ you ~~have to un-mount it before unplugging, else data~~ may ~~get broken. But 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 once~~ the ~~data is transmitted. One distro tested requires root password, and RMIR to be closed~~, to ~~un-~~mount~~. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever~~.