In case you haven’t realized, the user and pass in the docker compose are for setting the user/pass that you will enter on windows to access the share. It doesn’t have to be the same as the Linux server user account - though mine is the same because it’s easier to remember.

Hmm, well it doesn’t seem to be any problem with the docker compose then as best as I can tell. I picked a random ext4 flash drive and replicated your setup with the UID and GID set and it seems to work fine:

# /etc/fstab
/dev/sda1       /home/<me>/mount/ext_hdd_01  ext4    defaults 0 2

~/mount % ls -an
total 12
drwxr-xr-x  3 1000 1000 4096 Mar 27 16:22 .
drwx------ 86 1000 1000 4096 Mar 27 16:31 ..
drwxrwxrwx  3    0    0 4096 Mar 27 16:26 ext_hdd_01

~/mount/ext_hdd_01 % ls -an
total 6521728
drwxrwxrwx 3    0    0       4096 Mar 27 16:26 .
drwxr-xr-x 3 1000 1000       4096 Mar 27 16:22 ..
-rw-r--r-- 1 1000 1000 6678214224 May  5  2024 PXL_20240504_233345242.mp4
drwxrwxrwx 2    0    0      16384 May  5  2024 lost+found
-rwxr--r-- 1 1000 1000          5 Mar 27 16:27 test.txt

# ~/samba/docker-compose.yml
services:
  samba:
    image: dockurr/samba
    container_name: samba
    environment:
      NAME: "Data"
      USER: "user"
      PASS: "pass"
      UID: "1000"
      GID: "1000"
    ports:
      - 445:445
    volumes:
      - /home/<me>/mount:/storage
    restart: always

I was able to play the PXL.mp4 video from my desktop and write back the test.txt file

Have you checked the logs with docker logs -f samba to see if there’s anything there?

Also you could try to access the HD from within the container, using docker exec -it samba bash and then cd into /storage and see what happens.

I would suggest adding “UID” and “GID” environment variables to the container, and set them to the numeric values for user and group numbers that show in place of your name when you use “ls -an” inside of the “mount” folder (they will probably be the same number).

For example, if inside your mount folder you see:

ls -an
total 12
drwx------ 2 1001 1001 4096 Mar 27 13:54 .
drwxr-xr-x 3 1000 1000 4096 Mar 27 13:51 ..
-rwx------ 1 1001 1001    0 Mar 27 13:54 hello.txt
-rwx------ 1 1001 1001    4 Mar 27 13:54 test.txt

Then set UID: 1001 and GID: 1001

I get the same error as you when I copy your docker-compose and try to access a folder owned by my user. When I add the UID and GID of my user id to the docker-compose (1001 for me), the error goes away.

I’m pretty sure if you rip CDs directly to FLAC, it’s a perfect copy assuming you’re using good software. PCM isn’t lossy or lossless because it’s not a compressed format, it’s an uncompressed bitstream. Think of it like the original data. If it was burned to a CD as digital MP3 data and then ripped that to FLAC, then yes you’d be going from lossy compressed to lossless, which would hide the fact that quality was lost when it went to MP3 in the first place.

Just as an example, you can rip a CD directly to FLAC (you should also find and use the correct sample offset for your CD drive), rip the cue sheet for track alignment, then burn the FLAC back to a new CD using the cuesheet (and the correct write offset configuration), and you’ll get a CD with the exact bit for bit pattern of “pits” burned into the data layer.

You can then rip both CDs to a raw uncompressed wav file (wav is basically just a container for PCM data) and then you’ll be able to MD5sum both wav files and see that they are identical.

This is how I test my FLAC rips to make sure I’m preserving everything. This is also how CD checksum databases (like CDDB) work - people across the globe can rip to wav or flac and because it’s the same master of the CD, they’ll get identical checksums, and even after converting the PCM/wav into a flac you are still able to checksum and verify it’s identical bit for bit.