I have a container using a docker image as part of a project that works fine on my other Windows machine (and a few other developers' machines). When upping the project on my secondary Windows machine however the entrypoint file is reported as not found
$ docker-compose logs -f php
Attaching to project-name-php-1
project-name-php-1 | exec /usr/local/bin/docker-entrypoint: no such file or directory
I've confirmed the syntax in the Dockerfile as I had seen comments from people who had used single quotes incorrectly (not that I would expect such an error given it works fine on other machines)
ENTRYPOINT ["docker-entrypoint"]
I have also confirmed that file does actually exist within the image
docker run -it --rm --entrypoint bash theimage/inuse:thetag
root@209618ad969c:/var/www# ls -l /usr/local/bin
-rwxr-xr-x 1 root root 924 Jul 22 12:04 docker-entrypoint
The file isn't set in the container via volume mount or anything I can see, so I am out of ideas as to why the file is not found when permissions etc look correct to me.
Dockerfile
FROM public.ecr.aws/docker/library/php:8.1-fpm-buster as cli
COPY --from=composer-base /usr/bin/composer /usr/bin/composer
RUN apt-get update \
&& apt-get install -y git gnupg wget libzip-dev unzip libcurl4-openssl-dev pkg-config libssl-dev \
&& pecl channel-update pecl.php.net \
&& pecl install mongodb-1.16.1 \
&& docker-php-ext-install pdo_mysql zip
ADD .docker/php/custom.ini /usr/local/etc/php/conf.d
FROM composer-base as composer
RUN --mount=type=cache,target=/tmp/cache,sharing=locked \
--mount=type=bind,source=composer.json,target=/app/composer.json \
--mount=type=bind,source=composer.lock,target=/app/composer.lock \
composer install --no-dev --no-autoloader \
--no-interaction --no-progress --no-scripts --no-plugins --no-ansi
FROM cli as prod
RUN rm -rf /var/www/html && \
chown -R www-data:www-data /var/www
COPY bin /var/www/bin
COPY .docker/php/docker-entrypoint.sh /usr/local/bin/docker-entrypoint
RUN chmod +x /usr/local/bin/docker-entrypoint && \
chmod +x /var/www/bin/notify.sh
COPY --from=composer --chown=www-data:www-data /app/vendor/ /var/www/vendor/
COPY --chown=www-data:www-data config /var/www/config
COPY --chown=www-data:www-data data /var/www/data
COPY --chown=www-data:www-data public /var/www/public
COPY --chown=www-data:www-data src /var/www/src
COPY --chown=www-data:www-data templates /var/www/templates
COPY --chown=www-data:www-data .env /var/www/
RUN --mount=type=bind,source=/usr/bin/composer,target=/usr/local/bin/composer,from=composer \
--mount=type=bind,source=composer.json,target=/var/www/composer.json \
composer --working-dir=/var/www dump-autoload --optimize --no-dev \
--no-plugins --no-scripts --no-ansi && \
chown www-data:www-data -R /var/www/vendor
RUN mkdir -p /var/www/var/cache /var/www/var/log && \
chmod -R a+r,u+w /var/www/var && \
chmod a+x /var/www/var/log /var/www/var/cache && \
chown www-data:www-data -R /var/www/var
ENTRYPOINT ["docker-entrypoint"]
CMD ["php-fpm"]
WORKDIR /var/www
Entrypoint
#!/bin/bash
set -e
echo "Waiting for db to be ready..."
until bin/console doctrine:database:create --if-not-exists > /dev/null 2>&1; do
sleep 1
done
if [ "$MODE" = "PROD" ]; then
migration=$(/var/www/bin/console doctrine:migrations:list)
if [[ $migration =~ .*"not migrated".* ]]; then
echo "Migration has not run. Please ensure the migration has been run before attempting to start again!"
exit 1
fi
else
bin/console doctrine:migrations:sync-metadata-storage --no-interaction
bin/console doctrine:migrations:migrate --no-interaction
fi
exec docker-php-entrypoint "$@"
Entrypoint od Output
0000000 # ! / b i n / s h \n s e t - e
0000020 \n \n i f [ " $ M O D E " !
0000040 = " D E V " ] ; t h e n \n
0000060 i f [ - f " / v a r /
0000100 w w w / . e n v " ] ; t h e
0000120 n \n A P P _ E N V = p r
0000140 o d A P P _ D E B U G = 0 p
0000160 h p b i n / c o n s o l e d
0000200 o t e n v : d u m p \n r
0000220 m / v a r / w w w / . e n v \n
In the end my IDE (PHPStorm) was set to system dependent line endings, and was inserting Windows endings (\r\n) instead of unix line endings (\n), despite the file within the image seeming not to have the resulting issue.
Changing the setting and saving the affected files resulted in the entrypoint functioning correctly.