docker-compose error if code on NAS (not local disk): can't open file X [Errno 2] No such file or directory

Question

On Windows I get error on docker-compose up, eg:

python: can't open file '/code/manage.py': [Errno 2] No such file or directory

This actually happens on many projects trying to deploy them into Docker, so I don't think it's related to python, django or even path locations - it seems a remote file system mapping problem.

I can fix it by simply moving project to the local disk (not even WSL, just normal Windows folder), not the wifi connected (Linux Western Digital MyCloudX2Ultra) NAS where all project files are currently stored. But this is not viable, as the local disk is small SSD, and not a big code repo - naturally a common setup.

So it seems Windows Docker struggles to mount the volumes when code is on NAS:

Dockerfile:

# Pull base image
FROM python:3.10.4-slim-bullseye

# Set environment variables
ENV PIP_DISABLE_PIP_VERSION_CHECK 1
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1

# Set work directory
WORKDIR /code

# Install dependencies
COPY ./requirements.txt .
RUN pip install -r requirements.txt

# Copy project
COPY . .

Docker-compose.yml:

version: "3.9"
services:
  web:
    build: .
    ports:
      - "8000:8000"
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - .:/code  

There's quite a few posts about this "[Errno 2] No such file or directory" but all seem rabbit holes (I may stand corrected) as I've verified this seems related only to NAS source location, so some kind of mapping and/or permissions problem (no surprise between Windows and Linux).

Am using same folder owner and admin user to run both from NAS and locally, but maybe a problem mapping the NAS path - possibly because it's a Windows mapped drive "N:..." when in reality of course the drive is "\\<local IP>\...". Shouldn't be a problem... but it is somewhere! Maybe it's possible to hard-code the path in the docker files (not ideal of course), but not sure of best way.

Answer 1

Ok, so it's nothing to do with the NAS. It is to do with the code re-location. Fixed this by modifying the docker-compose.yml on new location:

volumes:
      - .:/code/subfolder_app

Bingo! So I now realise that the period "." dot on build and inside the Dockerfile and docker-compose.yml subtly depends on the overarching parent folder - even when the virtual environment .venv is in the subfolder itself (hence why I thought "." would pick it up as just ":/code") and where all CLI is run. It may be a Visual Studio Code thing, but probably not - just a combination.

When I moved the project to local disk, it didn't have the same higher level folder, but I thought it all looked self-contained. Obvious in retrospect.

Apologies to any hard core Dockers, but at least us poor Devs (as opposed to more experienced DevOps) don't have to abandon containers due to immutability - providing docker-compose (actually V1 deprecated for new V2 "docker compose" Difference between "docker compose" and "docker-compose" which oddly I couldn't get to work in same way) continues the greatness.