I ran WSL2 + Storage Space from August 2019 to March 2020. It works well. I ended up switching from Storage Space to DrivePool because it's really hard to diagnose Storage Space when it misbehaves. And when it does fail (and it will), it does so in spectacular fashion. I was bummed out about losing parity functionality but DrivePool + Snapraid is fine for my use case.
Anyway, I was able to use DrivePool with WSL2 (Docker) by mounting cifs volumes (windows shares). Here's an example:
version: '3.7'
services:
sonarr:
build: .
container_name: sonarr
volumes:
- type: bind
source: C:\AppData\sonarr\config
target: /config
- downloads:/downloads
cap_add:
- SYS_ADMIN
- DAC_READ_SEARCH
volumes:
downloads:
driver_opts:
type: cifs
o: username=user,password=somethingsecure,iocharset=utf8,rw,nounix,file_mode=0777,dir_mode=0777
device: \\IP\H$$\Downloads
Note that I'm building the image. This is because I need to inject cifs-utils into it. Here's the dockerfile:
FROM linuxserver/sonarr
RUN \
apt update && \
apt install -y cifs-utils && \
apt-get clean
There are security considerations with this solution:
1. Adding SYS_ADMIN capability to the docker container is dangerous
2. You need to expose your drive/folders on the network. Depending on how your windows shares are configured, this may be less than ideal.
Hope this helps!
Hi im using Windows 10 2004 with WSL2.
I have 3x drives: C:\ (SSD), E:\ (NVME), D:\ (Drivepool of 2x 4TB HDD)
When the drives are mounted on Ubuntu, I can run ls -al and it shows all the files and folders on C and E drives. This is not possible on D
When I run ls -al on D, it returns 0 results. But I can cd into the directories in D stragely enough.
Is this an issue with drivepool being mounted? Seems like it is the only logical difference (aside from it being mechanical) between the other drives. They are all NTFS.