[Howto] RTL-SDR dongle pass-through to Proxmox LXC container

It took a little bit of searching to work out how to pass through the RTL-SDR dongle through the Proxmox host and into an LXC container. Below is what worked for me on Proxmox 7.4, into an unprivileged LXC container.


  • Proxmox
  • Any RTL-SDR USB dongle

This guide assumes good working knowledge of Proxmox, and an already created and running LXC container.

All actions below are performed on the Proxmox host, not within the container.

Blacklist kernel modules

Follow instructions here: Blacklist Kernel Modules - ADS-B Reception, Decoding & Sharing with Docker

Find USB stick

Plug the RTL-SDR USB dongle into the Proxmox host, find its bus and device ID and set its permissions

root@proxmox:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 007: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

The above indicates Bus 001 and Device 007 for my dongle.

Set permissions on this bus and device, adjusting for your bus/device values.

root@proxmox:~# chmod 0666 /dev/bus/usb/001/007

Check permissions of this bus and device:

root@proxmox:~# ls -l /dev/bus/usb/001/007
crw-rw-rw- 1 root root 189, 6 Aug  8 21:41 /dev/bus/usb/001/007

Adjust LXC configuration

Pass through the dongle from the host to the container. My container ID is 156.

root@proxmox:~# nano /etc/pve/lxc/156.conf

Add the following two lines to the configuration file:

lxc.cgroup2.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/bus/usb/001/007 dev/bus/usb/001/007 none bind,optional,create=file

The 189 should match the 189 when checking the permissions of the bus and device previously. Adjust the bus and device values to suit your setup.

Below is my full LXC configuration file. Note that I have keyctl=1,nesting=1 to allow me to install and use Docker within this container, as I use the ultrafeeder Docker image from ADS-B Enthusiasts.

root@proxmox:~# cat /etc/pve/lxc/156.conf
arch: amd64
cores: 1
features: keyctl=1,nesting=1
hostname: sdr
memory: 512
net0: name=eth0,bridge=vmbr0,firewall=1,gw=,hwaddr=76:E6:C9:E1:E2:D4,ip=,type=veth
ostype: debian
rootfs: local-lvm:vm-156-disk-0,size=4G
swap: 512
unprivileged: 1
lxc.cgroup2.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/bus/usb/001/007 dev/bus/usb/001/007 none bind,optional,create=file

Great! Thanks.

Now let us see if this pass-through is stable enough to allow mlat synchronization of your piaware station with other nearby stations.

I have pass-through of sdr dongle to Debian 11 on Windows 10 running in Oracle VM. The dump1090-fa & piaware data feed works OK. The mlat is enabled, but fails to synchronize with nearby receivers due to imperfect pass-through of dongle.

AIUI LXC is containerization, not full virtualization, so libusb ends up talking directly to the “real” kernel for the USB device, not a virtualization layer. So it’s got a good chance of working OK with mlat.

1 Like

It seems to be working absolutely fine:

1 Like

Maybe this is going off topic somewhat – but what is the advantage of using containers, whether it be Docker or LXC? What problem does the use of containers solve or ameliorate (specifically related to this hobby for example)? Thanks.

For me personally, two main reasons:

  1. I use this computer to run many services, not just related to this hobby. Containerization means all my services are isolated from each other in such a way that if an upgrade of one service was to fail and broke a bunch of dependencies, none of the other services would be affected (as they have their own copies of their required dependencies).

  2. Incredibly simple backup and restore of an entire container. For example yesterday I decided to tinker with tar1090 but before I did I clicked the backup button which created a snapshot of the entire container. As a result, if I screwed something up I could go back and click the restore button and everything would be back to before I started messing around. Both backup and restore take ~15 seconds each on this computer for this ADS-B LXC.

So in short: containers save me from myself! I like to think of them as lots of individual computers, all running an easily restorable service each.

For Proxmox and its LXC containers another useful thing: you assign CPU and RAM per container. So if one service in an LXC starts running away with resource it will be limited, protecting your other services in the other LXCs.

For Docker - it’s just stupid easy to setup new services if a Docker image is available (in addition to the advantage of containerisation). I got the full ADS-B related stack installed (readsb, tar1090, dump1090, feeders into many online services and more) in a matter of minutes which is incredible. I’ve been self hosting services for quite some time, and whilst Docker has its faults it certainly scratches the itch of “I wonder what that service is like” without having to read through reams of documentation, solving conflicts and compiling software - in a few minutes you’ll just be trying the service itself!

Ok, I was thinking of the dependencies issue – some software requiring a different version of a dependency than another piece of software. Good reason to use containers.

As far as backup – I do a backup of the whole SD card occasionally. But it’s very time consuming. Backup of just a container would be faster. I need to learn more about that.

Thanks for your response.

1 Like