Bind mounting custom .htaccess file not allowed / possible

[lfleuren]

In order to configure a Wordpress Multisite setup I have been using docker bind mounts to inject a custom .htaccess file into a container.

docker compose file fragment:

    volumes:
      - type: bind
        source: /opt/custom_htaccess
        target: /var/www/html/.htaccess

Due to moving the .htaccess file to the Dockerfile a new problem arises when starting the service. It is not able to start because the .htaccess untar process fails.

wordpress_multisite.llaz7a57a6id@vps01 | tar: ./.htaccess: Cannot open: File exists
wordpress_multisite.llaz7a57a6id@vps01 | tar: Exiting with failure status due to previous errors

I prefer to use default Wordpress images, so I am wondering what would be the best solution.

[imtbl]

Experiencing the same issue. Wouldn't it be an option to use the --skip-old-files option for tar here? See https://www.gnu.org/software/tar/manual/html_node/Dealing-with-Old-Files.html

For now I'm working around this with

RUN rm -f /usr/src/wordpress/.htaccess

in my Dockerfile (since I've been using my own with the wordpress image as base image anyway).
This way, there won't be a .htaccess in the tar archive that would conflict with the bind-mounted one.

[wglambert]

The entrypoint copies WordPress from /usr/src/wordpress/ to /var/www/html/. You could overwrite the /usr/src/wordpress/.htaccess so it gets copied over

wordpress/latest/php7.4/apache/docker-entrypoint.sh

Lines 58 to 85 in e7f2ca6

	sourceTarArgs=(
	--create
	--file -
	--directory /usr/src/wordpress
	--owner "$user" --group "$group"
	)
	targetTarArgs=(
	--extract
	--file -
	)
	if [ "$user" != '0' ]; then
	# avoid "tar: .: Cannot utime: Operation not permitted" and "tar: .: Cannot change mode to rwxr-xr-x: Operation not permitted"
	targetTarArgs+=( --no-overwrite-dir )
	fi
	# loop over "pluggable" content in the source, and if it already exists in the destination, skip it
	# https://github.com/docker-library/wordpress/issues/506 ("wp-content" persisted, "akismet" updated, WordPress container restarted/recreated, "akismet" downgraded)
	for contentDir in /usr/src/wordpress/wp-content/*/*/; do
	contentDir="${contentDir%/}"
	[ -d "$contentDir" ] || continue
	contentPath="${contentDir#/usr/src/wordpress/}" # "wp-content/plugins/akismet", etc.
	if [ -d "$PWD/$contentPath" ]; then
	echo >&2 "WARNING: '$PWD/$contentPath' exists! (not copying the WordPress version)"
	sourceTarArgs+=( --exclude "./$contentPath" )
	fi
	done
	tar "${sourceTarArgs[@]}" . | tar "${targetTarArgs[@]}"
	echo >&2 "Complete! WordPress has been successfully copied to $PWD"
	fi

[lfleuren]

The entrypoint copies WordPress from /usr/src/wordpress/ to /var/www/html/. You could overwrite the /usr/src/wordpress/.htaccess so it gets copied over

wordpress/latest/php7.4/apache/docker-entrypoint.sh

Lines 58 to 85 in e7f2ca6

	sourceTarArgs=(
	--create
	--file -
	--directory /usr/src/wordpress
	--owner "$user" --group "$group"
	)
	targetTarArgs=(
	--extract
	--file -
	)
	if [ "$user" != '0' ]; then
	# avoid "tar: .: Cannot utime: Operation not permitted" and "tar: .: Cannot change mode to rwxr-xr-x: Operation not permitted"
	targetTarArgs+=( --no-overwrite-dir )
	fi
	# loop over "pluggable" content in the source, and if it already exists in the destination, skip it
	# https://github.com/docker-library/wordpress/issues/506 ("wp-content" persisted, "akismet" updated, WordPress container restarted/recreated, "akismet" downgraded)
	for contentDir in /usr/src/wordpress/wp-content/*/*/; do
	contentDir="${contentDir%/}"
	[ -d "$contentDir" ] || continue
	contentPath="${contentDir#/usr/src/wordpress/}" # "wp-content/plugins/akismet", etc.
	if [ -d "$PWD/$contentPath" ]; then
	echo >&2 "WARNING: '$PWD/$contentPath' exists! (not copying the WordPress version)"
	sourceTarArgs+=( --exclude "./$contentPath" )
	fi
	done
	tar "${sourceTarArgs[@]}" . | tar "${targetTarArgs[@]}"
	echo >&2 "Complete! WordPress has been successfully copied to $PWD"
	fi

Thanks for this suggestion. Indeed this could be a solution to get my multisite setup running initially. But in practise the .htaccess file is modified by plugins during runtime. I want to persist those changes as well. The only practical way to get this done is to have the .htaccess file bind mounted and editable. Therefore the proposed solution will not work completely as intended.

[tianon]

I'm a little confused why you want to persist changes to .htaccess but not to the rest of the WordPress install? (Which will also complicate WordPress automated updates, which are highly recommended for the security of your deployment.)

[lfleuren]

I'm a little confused why you want to persist changes to .htaccess but not to the rest of the WordPress install? (Which will also complicate WordPress automated updates, which are highly recommended for the security of your deployment.)

You are completely right. Of course I am also persisting the wp-content folder to disk so I can easily update my wordpress containers using new images without loosing current content. So basically my requirement is to be able to persist the dynamic parts of my wordpress installation and config.

[iben12]

I'm facing the same problem. I'm using a docker config file to store .htaccess and mount it into the container, otherwise I just persist the wp-content folder on a volume. This recent change does not allow that, because startup fails.

Couldn't we just modify docker-entrypoint.sh to skip .htaccess if it already exists (just with other folders during tar extract)?

[tianon]

Yeah, I think making .htaccess a new special case is the more conservative solution.

[uclaeaslam]

I'm running into the same issue. I was previously using tag 5.5.3-apache, and my switch to 5.6.0-apache failed with similar errors that lfleuren described. My situation is similar in that I have a custom persisted .htaccess and wp-content folder. The custom .htaccess file is to support some security plugins I use as well as SSL redirects since my site is behind a load balancer (in a Kubernetes cluster)

[laurenskling]

I'm using a COPY of a .htaccess in my Dockerfile. This works in FROM wordpress:5.5-php7.4-apache but not in FROM wordpress:5-php7.4-apache (which is now 5.6). Now my htaccess is overwritten by the default wp htaccess

[iben12]

@laurenskling Just put this into your Dockerfile:
RUN rm -f /usr/src/wordpress/.htaccess

[laurenskling]

I changed the COPY from /var/www/html/.htaccess to /usr/src/wordpress/.htaccess and now it works again :) thanks for the help

[lfleuren]

I'm facing the same problem. I'm using a docker config file to store .htaccess and mount it into the container, otherwise I just persist the wp-content folder on a volume. This recent change does not allow that, because startup fails.

Couldn't we just modify docker-entrypoint.sh to skip .htaccess if it already exists (just with other folders during tar extract)?

This would be my proposed solution as well. It leaves room for use of a custom .htaccess and in case not provided fall back to the default configuration. I am still in need of a solution because I believe using default docker images is the prefered way to go in most situations. Are there any arguments against this solution?