I've done the Linux VM solution like yours for years on multiple platforms. But different, and depending on the specific use case, much better. (I've tried your method as well. Too many problems, particularly with USB passthrough.)
Here's what I do, roughly, using VirtualBox (not a step-by-step guide but should be enough to get you going):
- I don't attach the external volume via USB intercept; I create a raw VMDK of the external drive first. This requires some script magic: You have to 1) Make sure VM is powered off. 2) Delete the VMDK metadata file. 3) Detach the virtual storage controller dedicated to the USB drive. 4) Create a new raw VMDK file for the USB drive [this part is challenging since the physical location changes; I use a script parameter to pass it in to the script]. 5) Create a new virtual storage controller for the VM. 6) Attach the raw VMDK to the new storage controller. 7) Start the VM. The drawback to this approach of course, is that the USB drive and the VM are tied together for the entire session of the VM. If you unplug the USB drive while the VM is running, it will never be valid again (until you shut the VM down and run the script again). But the benefits are huge: A) It works flawlessly, unlike buggy USB intercept. And B) The performance is near-native [since the host is handling the low-level device I/O], which you can't get with USB intercept.
- I set the VM up with two network adapters: 1) NAT with DHCP for regular internet access from within the VM, and 2) Host-only with static IP for host-to-VM access. You could also just have one bridged adapter, but I've found that this approach is more ideal, as VM internet access is not tied to any one adapter.
- I set the VM up to share folders via SMB. In my case, these are encfs mounted folders.
- I then mount folders on the host, mapped via SMB to the guest.
The performance is pretty decent. SMB over gigabit ethernet between real hardware has a theoretical maximum of something like 120 MB/s (there is a specific number max but that's close enough for this discussion). You probably won't get that high in host-to-vm SMB traffic, even using virtio adapter with no bandwidth limit. On my fastest hardware, I've seen at best around 70 MB/s sustained. But my hardware isn't super fast, you might do better. (Although the USB and spinning disk in your solution will be the limiting factors.)
I would not bother with sshfs. The overhead is severe and throughput terrible. The only benefit to sshfs is when mounting over an unsecured network. Host-to-vm exists completely within your own computer and is therefore as secure as it gets, you don't need encryption, and the lightest-weight network protocol you can get is ideal. (SMB isn't exactly lightweight but it and virtually all hosts support all the remote file actions you could need.)
The solution I've outlined seems complex - and is. But if you document the successful process, it's trivially easy the second time. I have all this scripted in both the host and VM, so it's nearly automagic for every session, and easily set up for new hosts and/or VMs. And it's a very nice and seamless solution for daily use.
Hope this helps.