Exposing SD Card to Custom Application Container

Technical Support
, , , , ,
1

I am currently working with the following configuration for a custom image:

  • Ixora Board v1.2
  • Apalis-iMX6
  • TorizonCore 6.1.0 Build 1
  • Developing a Qt application using the Visual Studio Code Extension for Torizon

My application is using an SD Card as file storage, so I need to expose the port to the container.

Using the lsblk command, I can see the SD card is identified as /dev/mmcblk0p1

Attempted Method 1
So my first attempt was to add this device to the configuration on VS Code, like so:
image

Then, inside my application container, I tried running the command mount /dev/mmcblk0p1 /mnt, to get the following output:

image

Using sudo prompts me for a password, which I do not know since it doesn’t seem to be the same one set on TorizonCore.

Attempted Method 2
I see that TorizonCore automatically mounts SD Cards in /media as a sub-folder.
image

So, similarly to Method 1, I tried to add /media to the configuration on VS Code, assuming it could also expose all the sub-folders:
image

By doing so, if I deploy and start this container, I get the following error:

Error (525) - Docker exception: 500 Server Error for http://127.0.0.1:37959/v1.41/containers/a550953a8e9d5e7a65aa8fccec9565cc5901c5105b4d8129c18de153567353d2/start: Internal Server Error ("error gathering device information while adding custom device "/media": not a device node")

I used a similar method as Method 1 to access serial ports and it worked correctly, but not for the case of the SD Card.

I’m not sure if I missed a step or if there’s another method I’m unaware of.

Thanks in advance,
Anthony

2

Hello @anthonyabboud,

I think you are on the right path, but need a few small adjustments.

lsblk command while SSH into the device should give the SD card, and a mountpoint. If there isn’t a mount point you should give it one such as /media/usb. the mount command should work here with the same password as your root user. (not in the container)

Depending on how you are running your docker container you should be passing two important flags. --device and --v

if you are running from the command line: (as example)

docker container run -it --device /dev/sda1 -v /media/usb:/media 2535489c55bb /bin/bash

--device /dev/sda1 : lets the container know about the device

-v /media/usb:/media : links the mount points (/media within the container) to the USB mounted at /media/usb.

These flags can also be set in the docker compose file for the correct container.

-Eric

3

This solution worked! I added /media/SD_Name:/media to my docker-compose file.

Thanks for the quick tip.

1 Like
4

Hi @eric.tx,

I know I’m going back on this topic that was solved a few days ago, but I was wondering if it would be possible to allow the container to manually use mount/unmount commands instead of exposing the mountpoint where TorizonCore automounted?

I’m asking this because of cybersecurity reasons in the MedTech industry. We want to restrict mounting externals drives to only if a Field Service user has accessed the computer’s terminal, which is password protected. That way I can write scripts from within the container to mount → do something → unmount.

Let me know if it’s more appropriate to open a new topic for this.

Thanks,
Anthony

5

Hey @anthonyabboud,

Sorry for the delayed response.
Yes we generally want one issue per ticket, but this is related so its ok.

It’s fairly interesting the question. Because it sort of breaks the idea of why to use containers (at least the separation aspect). Mount/umount on the device side are not suppose to be accessible via inside a container. Even when running in privileged mode (security issue in itself) and I have quickly tested that umount will only unmount the drive from the container, not the drive from the device.

I believe the cut and dry way to do this is to run the container without linking the flash while in operation. And rerun the container with the drive connected when needed. But I don’t think this serves your purpose of an external saved file system. I will ask internally if anyone has ideas on flash drive security.

-Eric

1 Like