Inspect files in container from host volume

I have a “visibility/access”/ issue with shared volumes.

I do not really know how to name it so let me describe what I am doing and not seeing:

I created mapped volumes in my docker-compose.yml file for an Nginx web server (but also for other containers with the same issue)

Figure 1 in the below Screen dumps shows the lines in the docker-compose.yml file:

In the host folder ./nginx/conf.d I have a file called site.conf

See Figure 2 in the Screen dumps file

Here is the issue: If I now browse the container using bash I do not see the file site.conf listed. So my initial deduction was that it is not loaded.

See Figure 3 in the Screen dumps file

But I then add configuration detail (incorrectly) and it is reported in the error.log file.

Here is what I added (See Figure 4 in the Screen dumps file ):

This is what is reported in the error log (See Figure 5 in the Screen dumps file :

So the error message confirms that my volume mapping was successful and that the “site.conf” file is loaded. The issue is that I cannot see it in the container when browsing with bash.

I have the same issue with the root folder. The root folder mapping is working and if I make changes to an HTML file on the host it is directly visible when refreshing the page in a web browser, but the root folder is not visible when I try to list its contents using bash in the container.

Is this known behaviour and what must I do to make it visible for me to inspect in the container. It seems like nobody else has ever reported a similar issue.

The last thing, I mentioned that I could see that the site.conf is loaded because it generated an error. The mapping for the logs does expose the error log contents in my Windows host folder. But, I tested by manually adding a file to that directory, and this is also not visible in the container when I list its contents using bash.

My configuration is as follows:

I am working on a Windows 10 PC (build 18363.900)
My Docker Desktop version is 2.3.0.3 (45519)

(Oh, and I saw that other people had access issues with volumes (not same as my issue) and they reported that a windows password without special characters solved their problem, so I also tried it by changing the windows password to a more simple password - but it did not solve the issue).