Add etc-fstab.mount overlay for persistent automount of external drive

Running Home Assistant OS, I have a use case where I’d like to have the /data partition split across two separate drives. Specifically an NVMe drive (which also contains HassOS partitions) and an SSD (or large HDD). I’d like to keep most of my add-ons on the NVMe but would like to use the second drive for add-ons such as InfluxDB and motioneye for instance. As such, I’d rather not use datactl to move everything to the 2nd drive. My intent is to mount the 2nd drive to /mnt/data/supervisor/share/data2 for instance such that the volume will be visible to Docker containers. I’d like to stick with HassOS rather than migrating to Debian and HASupervised and this is the one roadblock I haven’t found a way around yet.

My suggestion / request:
The overlay partition stores a bit of OS specific configurations that are read-write and isolated (+ persistent) during OS updates. ex: timesyncd, hostname, authorized_keys modules and udev rules. From what I understand, adding a etc-fstab.mount config file in /user/lib/systemd/system as part of buildroot a user could modify fstab in the overlay partition similar to the above examples. Short of that, my only other options are to unsquash the root image, edit fstab and re-squash, or fork the operating-system repo and add the mount file. Seems fairly low risk to me, fstab would remain default (/empty) unless an experienced user adds their own within the overlay partition.

As an aside, there are a number of other threads looking for similar functionality or trying other round-about means of adding persistent mount points at the OS layer.

If you use HAOS install the ssh and web terminal addon and use the init_commands option to run your mount command

Option: init_commands

Customize your shell environment even more with the init_commands option. Add one or more shell commands to the list, and they will be executed every single time this add-on starts.

I had seen a post suggesting similar, however I thought since the add-on is a container, and the container can’t see /dev/sda1 unless already exposed (mounted and added as a volume in Docker) it couldn’t mount the drive within the add-on.

Trying the mount command within the terminal (and with init_command) errors out as well:

mount: permission denied (are you root?)
[03:52:52] FATAL: Failed executing init command: mount /dev/sda1 /share/ssd

I have protection mode disabled as well. Am I missing something else?

Also, in this approach the mount is performed as add-ons are starting at boot… if I intend to have the mount alive for other add-ons - isn’t there a dependency on the order of which add-ons are started such that the mount is ready as influxDB or motioneye starts?