Odd issue: `artisan` not foound in container

[judgej]

I have build the 7.3 and 7.4 containers, and both behave the same.

When I run the container with a mounted project drive, the artisan command simply cannot be seen in the container. It is there on my host (Windows) directory. I can see it in the container if I rename it, but any file called artisan is simply invisible.

Any idea what could be causing that? From Powershell it looks like this:

PS C:\Users\jason> docker run --rm --name my-app -v C:\Projects\my-app:/var/www/html -w /var/www/html --publish 8000:8000 laravel-7.4 ls -las
ls: ./.env: No such file or directory
ls: ./.env.example: No such file or directory
ls: ./artisan: No such file or directory
ls: ./artisan-orig: No such file or directory
ls: ./composer.json: No such file or directory
total 4
     0 drwxrwxrwx    1 root     root          8192 Apr 14 19:36 .
     4 drwxr-xr-x    3 root     root          4096 Mar 24 01:18 ..
     0 -rwxr-xr-x    1 root     root           220 Apr 14 19:01 .editorconfig
     0 -rwxr-xr-x    1 root     root           111 Apr 14 19:01 .gitattributes
     0 -rwxr-xr-x    1 root     root           163 Apr 14 19:01 .gitignore
     0 -rwxr-xr-x    1 root     root           174 Apr 14 19:01 .styleci.yml
     0 -rwxr-xr-x    1 root     root          4497 Apr 14 19:01 README.md
     0 drwxrwxrwx    1 root     root          4096 Apr 14 19:01 app
     0 drwxrwxrwx    1 root     root             0 Apr 14 19:01 bootstrap
     0 -rwxr-xr-x    1 root     root        200585 Apr 14 19:16 composer.lock
     0 drwxrwxrwx    1 root     root          4096 Apr 14 19:01 config
     0 drwxrwxrwx    1 root     root          4096 Apr 14 19:01 database
     0 -rwxr-xr-x    1 root     root          1013 Apr 14 19:01 package.json
     0 -rwxr-xr-x    1 root     root          1139 Apr 14 19:01 phpunit.xml
     0 drwxrwxrwx    1 root     root          4096 Apr 14 19:01 public
     0 drwxrwxrwx    1 root     root             0 Apr 14 19:01 resources
     0 drwxrwxrwx    1 root     root             0 Apr 14 19:01 routes
     0 -rwxr-xr-x    1 root     root           563 Apr 14 19:01 server.php
     0 drwxrwxrwx    1 root     root             0 Apr 14 19:01 storage
     0 drwxrwxrwx    1 root     root             0 Apr 14 19:01 tests
     0 drwxrwxrwx    1 root     root          8192 Apr 14 19:16 vendor
     0 -rwxr-xr-x    1 root     root           538 Apr 14 19:01 webpack.mix.js
PS C:\Users\jason>

Notice the "no such file or directory" errors. The entire laravel install was done from within the container on the mounted directory, and I can see all those files from the host directory.

[judgej]

I've not customised the image in any way. My intention is to use this as a simple development environment, using artisan serve to serve up the pages. It looks great because it supports PHP 7.4 and has everything laravel needs, but does not come with bunch of other containers that force assumptions about what I am going to need. (so thanks :-)

I'm going to guess this is a file permission problem rather than a file overlay problem, given those "file not found" messages (it knows the files are there, but cannot read them).

Doing an ls -lasR in the container, it turns out many of the files cannot be found. Possibly these are the files created in some parts of the install command:

docker run --rm --name print-trail-geo-app -v C:\Projects\my-app:/var/www/html -w /var/www/html laravel-7.4 composer create-project --prefer-dist laravel/laravel .

From a bash shell within the container:

bash-5.0# ls -las artisan
ls: artisan: No such file or directory

The auto-complete worked for that, so bash new the file was there.

This works fine:

touch xxx

I can see and access the file both within the container and on the host filesystem.

[judgej]

Stranger and stranger. Just went into container bash, did ls -las and got the missing file errors as usual. Then did ls -lasR to list all files - a big list including the vendor directory. Then ls -las again, and now the missing files are visible and usable. Most odd, didn't touch anything else.

I'll close this issue as it seems to be fixed, butI suspect this is a mystery I won't be getting to the bottom of.