More help requested with UDEV. To automount something with no LABEL or UUID.

davecs · 09-25-2019, 03:36 PM

I've posted about this before, but I'm narrowing down what the problem is.

I have hardware which connects via USB, but increasingly doesn't mount automatically as distros get updated. The problem appears to be that the latest distros can no longer find its Label or its UUID. It uses the FAT12 file system and shows as Mass Storage though that's not its main purpose.

There are two versions of it, and I can capture it in udev with:

ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020"

In both cases, it mounts as the next available device in /dev/sd*1, with a shortcut in /dev/disk:

/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1

Does anyone know how to get it to automount? The only rule I can write is to nominate a user, which is probably ok for most purposes but I want to do it properly!

ondoho · 09-26-2019, 02:24 AM

Have you created a udev rule for it?
If the rule can recognize it unmistakably, you can perform all sorts of actions on it, incl. (auto)mounting.
I don't see the problem?

davecs · 09-26-2019, 06:32 AM

Quote:

Originally Posted by ondoho

Have you created a udev rule for it?
If the rule can recognize it unmistakably, you can perform all sorts of actions on it, incl. (auto)mounting.
I don't see the problem?

The problem is that I want some help. I've created a rule, and it works, but I can't work out how to get the current user name from a UDEV script, so I've had to settle on a named user. Which is adequate for me, but I want to do it properly.

ondoho · 09-26-2019, 12:20 PM

Quote:

Originally Posted by davecs

I can't work out how to get the current user name from a UDEV script

Just to be clear, are you talking about a script that is invoked by a udev rule?
And why cannot root do the mounting? AFAIK, mounting requires superuser privileges anyhow.
Please show us everything you actually implemented (not just excerpts).
Please use CODE tags where appropriate.

davecs · 09-26-2019, 05:14 PM

It's been an issue for a year or two. Anyway, I published my temporary solution here:

http://www.hifi-remote.com/wiki/inde...tes_with_Linux

As I said, I need to know how to automount a plugged in USB item without a Label or UUID, maybe using the /dev/disk/by-id definition.

Shadow_7 · 09-26-2019, 11:58 PM

Hot plugged? Or already plugged in at boot time?

At boot time, you can use the information outputted by mount (after you have it mounted) to make an fstab entry for it. Hot plugged, autofs something or other. I tend to not auto anything if I can avoid it. Takes longer to boot and I change my configurations too often to have that hassle.

ondoho · 09-27-2019, 11:58 AM

Quote:

Originally Posted by davecs

automount a plugged in USB item without a Label or UUID, maybe using the /dev/disk/by-id definition.

As I said: if udev can identify it unambiguously ('udevadm monitor'), then why shouldn't you be able to do that?
Please show us exactly what you tried & where & how it failed.

davecs · 09-27-2019, 03:44 PM

Quote:

Originally Posted by Shadow_7

Hot plugged? Or already plugged in at boot time?

At boot time, you can use the information outputted by mount (after you have it mounted) to make an fstab entry for it. Hot plugged, autofs something or other. I tend to not auto anything if I can avoid it. Takes longer to boot and I change my configurations too often to have that hassle.

Nope it's actually a remote control that appears as a mass-storage device on my computer. If it was permanently plugged in, I'd get it sorted in /etc/fstab.

davecs · 09-27-2019, 03:49 PM

Quote:

Originally Posted by ondoho

As I said: if udev can identify it unambiguously ('udevadm monitor'), then why shouldn't you be able to do that?
Please show us exactly what you tried & where & how it failed.

I did. I wrote the page that I linked to in my previous post. I can identify it:

Code:

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

That UDEV line works, it's what I do in the script file that's the problem.

tofino_surfer · 09-27-2019, 11:03 PM

Quote:

Any User Method

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.

For a user logged into a machine the loginctl command can be used to print out what users are currently logged in. If there is only one user with UID=1000 the following can be used

Code:

$ loginctl list-users | awk '/^1000/ {print $2;}'

Since many systems start numbering of ids for regular users at 1000 a more general form is:

Code:

$ loginctl list-users | awk '/^1[0-9]{3}/ {print $2;}'

Your script would then become:

Code:

#!/bin/bash
USER=$(loginctl list-users | awk '/^1[0-9]{3}/ {print $2;}')
mkdir -p /media/$USER/REMOTE
chown $USER:$(id -gn $USER) /media/$USER/REMOTE
SOURCE=/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
OPTIONS="-o uid=$(id -u $USER),gid=$(id -g $USER),utf8,dmask=027,fmask=137"
mount -t vfat $SOURCE /media/$USER/REMOTE/ $OPTIONS

This would only work if you were already logged into XFCE before hotplugging the remote. If you boot with the remote attached the udev rule will run at startup before you are logged in.

ondoho · 09-28-2019, 02:57 PM

Quote:

Originally Posted by davecs

That UDEV line works, it's what I do in the script file that's the problem.

Tadaa!
And you still haven't shown us that.

And I still don't understand why you don't want to be root when you mount this device.

tofino_surfer · 09-28-2019, 06:25 PM

Quote:

That UDEV line works, it's what I do in the script file that's the problem.

Quote:

Tadaa!
And you still haven't shown us that.

No Tadaa needed or applicable. The OP already showed this in post #5 with a link to their wiki guide page "Using USB Remotes with Linux". The whole script file is shown. They may not have copied the text into this thread but it doesn't take much effort to click the link as I did.

ondoho post #7

Quote:

Please show us exactly what you tried & where & how it failed.

The OP showed everything in the link posted in #5. What they tried didn't fail in that it works for one user by hardcoding a user name. They want to make their script applicable to anyone who logs in.

My post #10 just before yours proposes a solution to their problem using loginctl to find the username of the user using the desktop and which shows changes to their script. Their problem was fairly simple as they didn't know how to find the identity of the user logged into the computer from inside a script running as root. The actual problem actually has nothing to do with udev as their udev rule was working before they created this post.

Quote:

And I still don't understand why you don't want to be root when you mount this device.

They want to be able to write to the mounted directory with a graphical program running as a regular user. Therefore the regular user logged in to the desktop needs to have write permission to the mounted directory so they can write to the settings.bin file. It's not about which user mounts this device, it's about who has write permission to the mounted directory.

Code:

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

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

RemoteMasterIR is a GUI program which runs with the regular user's permissions.

Quote:

Just to be clear, are you talking about a script that is invoked by a udev rule?
And why cannot root do the mounting? AFAIK, mounting requires superuser privileges anyhow.

root is doing the mounting as the udev daemon runs as root and so do any scripts that it calls. However the regular user using the computer needs to have write access to the mounted directory. Therefore this script running as root needs to determine the identity of the user logged in. If only one user is logged into the machine it is simple enough with

Code:

USER=$(loginctl list-users | awk '/^1[0-9]{3}/ {print $2;}')

davecs · 09-30-2019, 11:03 AM

Quote:

Originally Posted by tofino_surfer

For a user logged into a machine the loginctl command can be used to print out what users are currently logged in. If there is only one user with UID=1000 the following can be used

Code:

$ loginctl list-users | awk '/^1000/ {print $2;}'

Since many systems start numbering of ids for regular users at 1000 a more general form is:

Code:

$ loginctl list-users | awk '/^1[0-9]{3}/ {print $2;}'

Your script would then become:

Code:

#!/bin/bash
USER=$(loginctl list-users | awk '/^1[0-9]{3}/ {print $2;}')
mkdir -p /media/$USER/REMOTE
chown $USER:$(id -gn $USER) /media/$USER/REMOTE
SOURCE=/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
OPTIONS="-o uid=$(id -u $USER),gid=$(id -g $USER),utf8,dmask=027,fmask=137"
mount -t vfat $SOURCE /media/$USER/REMOTE/ $OPTIONS

This would only work if you were already logged into XFCE before hotplugging the remote. If you boot with the remote attached the udev rule will run at startup before you are logged in.

Thanks, that's really helpful. The problem is that it has to be available for any linux system, not just those that use systemd. But you've set me on a hunt for another method.

davecs · 09-30-2019, 12:59 PM

Quote:

Originally Posted by tofino_surfer

Your script would then become:

Code:

#!/bin/bash
USER=$(loginctl list-users | awk '/^1[0-9]{3}/ {print $2;}')
mkdir -p /media/$USER/REMOTE
chown $USER:$(id -gn $USER) /media/$USER/REMOTE
SOURCE=/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
OPTIONS="-o uid=$(id -u $USER),gid=$(id -g $USER),utf8,dmask=027,fmask=137"
mount -t vfat $SOURCE /media/$USER/REMOTE/ $OPTIONS

loginctl only works with systemd. What I really want is to produce the same reaction when a mass storage device is inserted without its VolumeId or UUID being recognised as when it is, it seems that this remote has a problem with more recent versions of Linux, which, I think are more sensitive to its partitioning insecurity. I'll keep working on that.

However, in the meantime, your answer was very helpful, it got me thinking how I might achieve this. For a desktop computer, one person at a time is generally logged in, though two may be on occasions. So my first line in the script is changed to:

Code:

hisname=`who | head -n1 | awk '{print $1;}'`

And the search goes on... but thanks lots.

EDIT: As I can boot into MX19ß2.1 with or without systemd, I tried it with, and it worked at the second time of asking.

tofino_surfer · 09-30-2019, 11:14 PM

Quote:

However, in the meantime, your answer was very helpful, it got me thinking how I might achieve this. For a desktop computer, one person at a time is generally logged in, though two may be on occasions. So my first line in the script is changed to:

Code:

hisname=`who | head -n1 | awk '{print $1;}'`

A better way to exclude remote logins is to search for the user logged into tty1 which is usually mapped to the XWindow display on vt1 (Ctrl+Alt+F1). This also shortens the command with only two processes.

Code:

USER=$(who | awk '/tty1/ {print $1;}')

If a remote user is logged in first on a pts simply grabbing the first line of who will give the wrong user. It is better to search for tty1.