[Request] Add usbmount to image to allow auto-mounting of USB drives

[OutsourcedGuru]

What were you doing?

I inserted a USB thumbdrive into my OctoPi-imaged OctoPrint Raspberry Pi 3B.

What did you expect to happen?

I expected it to auto-mount like you might see in the Ubuntu Desktop.

What happened instead?

It didn't mount by default. The instructions for doctoring fstab seem far from an easy solution for the average user.

Did the same happen when running OctoPrint in safe mode?

Yes

Version of OctoPi

0.15.1

Printer model & used firmware incl. version

Robo C2, Marlin 1.1.6

I have read the FAQ.

Request

Add the usbmount command and adjust a file. This will allow people to simply insert a USB drive and to then access it via /media/usb, for example.

sudo apt-get install -y usbmount
sudo nano /lib/systemd/system/systemd-udevd.service
# Change "MountFlags=slave" to "MountFlags=shared"

That's all it takes. I'm working on a plugin now that will take advantage of this but I thought everyone could take advantage of this functionality.

You might consider also adding a symlink named usb under ~/.octoprint/uploads for the first drive inserted.

[guysoft]

Hey, Sorry I didn't reply to this sooner - why would you need that function? cc @foosel does adding the usb symlink make sense to you?

[OutsourcedGuru]

It's what I'm using on the 3D printer that I'm helping to write. I thought I'd be generous and help to "mainstream" this functionality for everyone else.

Basically, on a Robo 3D printer there's a USB Type A connector right next to the TFT screen. When you plug in a USB thumbdrive it's incorporated into the Files side panel widget and into the Kivy-based menu system on their printer.

It's working well for this new printer I'm making. From the Kivy-based interface I allow the user to upload from USB (which copies to the Watched folder). I'm also doing things like including a preview image of STL files, avatars and such.

from os                 import listdir
allFilesAndFolders =    listdir('/media/usb')
gcodeFiles =            filter(lambda x: x.find('.gcode') != -1, allFilesAndFolders)

[foosel]

cc @foosel does adding the usb symlink make sense to you?

Yes, it does.

[guysoft]

@OutsourcedGuru

I could add to the build

1. sudo apt-get install -y usbmount
   sudo nano /lib/systemd/system/systemd-udevd.service

2. Where do I change # Change "MountFlags=slave" to "MountFlags=shared"?

3. I am not sure how to do the symlink. It might require watching the folder which seems complicated.

[OutsourcedGuru]

Um, the second line indicates nano so this is an edit session (describing how to do it). That's the file that you'd want to edit. So it's more of a sed or echo >> ... sort of thing if you're scripting it.

sed 's/MountFlags=slave/MountFlags=shared/' /lib/systemd/system/systemd-udevd.service

[OutsourcedGuru]

You might consider also adding a symlink named usb under ~/.octoprint/uploads for the first drive inserted.

I've just discovered that Raspbian assigns device-by-ID for the four /media/usbn devices it issues. Since I've kept my thumbdrive in the only available Type A connector I hadn't noticed this until now. Having just moved my apartment—and subsequently inserting the USB thumbdrive into a different connector—I now see that it's not on /media/usb0 anymore. 🤦‍♂ The more I troubleshoot this, however, it's not related to location (which connector) but it seems to have to do with the replacement of the Robo controller board with the Smoothieware controller. I'm guessing that Raspbian is issuing them by ID order. By disconnecting the Smoothieware board and rebooting, I've confirmed this theory:

• Bus 001 Device 004: ID 1d50:6015 OpenMoko, Inc. (Smoothieware board)
• Bus 001 Device 005: ID 222a:0001
• Bus 001 Device 006: ID 058f:6387 Alcor Micro Corp. Flash Drive
• Bus 001 Device 007: ID 072f:2200 Advanced Card Systems, Ltd ACR122U

(Apologies that I didn't discover this earlier. This then should make this "simple" FR more complicated so feel free to re-evaluate this FR. Having a single symlink of usb which points to /media/usb0 will only work one out of probably two times.)

Perhaps a different approach would be to have the ~/.octoprint/uploads/usb symlink point to /media instead. The user could then navigate to whichever one has the files. It's not as controlled as you might find with a set configuration (like with a 3D printer manufacturer that can manage which plug goes where). But it should work better for everyone if it's selected to be added as a feature.

[guysoft]

Should I do anything or wait?

[OutsourcedGuru]

You might want to just abort on this. I cloned my microSD over to another card, inserted it into the exact same rig and the it's now moved back to /media/usb0 with the exact same everything (cable positioning, things plugged in, etc). It's got a mind of its own.

Translation: this will lead to more frustration to users than what it's worth.

Fun trivia: I'm now coding something that looks like this in my own rig:

class JobManagerUSBListContent(Widget):
    bCopying =                              False
    usbMediaPath =                          None

    def __init__(self, **kwargs):
        super(JobManagerUSBListContent, self).__init__(**kwargs)
        # Confirmed: only one instance
        op.op_usbfilelist =                 self
        for device in ['/media/usb0', '/media/usb1', '/media/usb2', '/media/usb3']:
            filelist =                      listdir(device)
            unrelatedFiles =                filter(lambda x: x.find('FIRMWARE.CUR') != -1, filelist)
            if len(unrelatedFiles) == 0:
                self.usbMediaPath =         device
                break
        self.update()

[guysoft]

OK, I am keeping this open for a while, if you do manage to figure it out. So we might still get this feature in.

[OutsourcedGuru]

Oh joy... Buster's /lib/systemd/system/systemd-udevd.service file's attribute has changed from MountFlags=shared to PrivateMounts=no from the default "yes".

And to make matters worse, running a sudo apt-get upgrade reverted those settings back to the defaults, rendering the mounts for pi unusable. So I had to re-edit that value and reboot. 🤦‍♂

[guysoft]

Ok, so does this mean we are still stuck about introducing this as a feature?

[OutsourcedGuru]

It means it's a can-of-worms. Let's close this; it's not worth the grief, I'd suggest.

It was a reasonable idea before all this craziness.

[OutsourcedGuru]

For what it's worth, usbmount now has a Debian package and it's been recently upgraded.

mkdir ~/tmpu && cd ~/tmpu
wget https://github.com/nicokaiser/usbmount/releases/download/0.0.24/usbmount_0.0.24_all.deb
sudo dpkg -i usbmount_0.0.24_all.deb
 (Reading database ... 67332 files and directories currently installed.)
 Preparing to unpack usbmount_0.0.24_all.deb ...
 Unpacking usbmount (0.0.24) over (0.0.22) ...
 Setting up usbmount (0.0.24) ...
cd ~ && rm -Rf ~/tmpu