M1 Macbook says it's running but can't access WP Homepage

UPDATE: This issue has been resolved through continues Docker updates and Great suggestions from other devs.

Hello, Im not sure if I should report this as a bug or not because I’m aware of the differences in architecture for the new Apple Silicon and that the available docker installation it’s currently a Preview and not official. However I decided to do so because I really enjoy 10updocker and hope other developers may find this useful.

Describe the bug

I have manage to successfully get all the containers in the 10updocker configuration running on the M1 macbook without modifying the docker-compose files. The installation logs state that the site has been successfully created and it adds the local domain to /etc/hosts file. But when try goin to the domain.test. the browser is unable to find the page. all of the containers are running, including phpmyadmin, nginx:latest, 10up/wp-php-fpm-dev, memcached, mysql, andyshinn/dnsmasq, mailcatcher. Im able to access phpmyadmin by going to 127.0.0.1:8092 and i can create/update databases. however for some reason the WP page isn’t available. i tried domain.test, 127.0.0.1 and nothing.
Steps to Reproduce

To reproduce these steps its a little involved. the Stock Big Sur/M1 configuration utilizes Port 53 for mDNSResponder for Bonjour. So if you try creating a 10updocker environment youll run into errors that port 53 is already in use. so you need to disable mDNSResponder by doing the following:

1. Disable System Integrity Protection (SIP) by starting your Mac in recovery mode, accessing the terminal and running csutil disable 2. boot into your profile, start a terminal and type sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist this will disable mDNSResponder and kill the current process BUT it will break access to your terminal’s internet connection. So you must re-enable it with sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist 3. Now that the mDNSResponder process is not running, make sure no other containers or brew services are running that use the same ports. then create a 10updocker environment with 10updocker create foo.test and follow intallation steps.

1. With the latest version of Docker for M1 (March Release Candidate), create a 10updocker environment with 10updocker create foo.test and follow intallation steps
2. The installation will conclude and say its successful, giving you the domain to visit. running docker ps will display the active running containers. Expected behavior

when visiting the domain.test, the default WP homepage should appear. Screenshots

Environment information

• Device: M1 Macbook Air
• OS: Big Sur 11.2.3
• Browser and version: Brave, Firefox, Safari
• WordPress version: default install

Additional context I dont recomment you disable System Integrity Protection or mDNSResponder for long periods of time. I just tested this to get 10updocker running on the default compose file since i kept getting errors when trying to create a wp environment. reenable System Integrity Protection (SIP) entering recovery mode, accessing the terminal and running csutil enable Im not sure why mDNSResponder needs to be taking up port 53 but i find it annoying. As previosly stated, Not sure if i should report this or not. but the fact that 10updocker initializes all the containers with the default configuration and not be able to access the WP homepage is weird. Any comments or suggestions are welcomed.

UPDATE: I upgrade Docker to the latest Release for M1 macs and no longer have a port 53 error, all the containers start up However the issue of no being able to access the WP home page remains.

[jeremiahbratton]

I was able to get 10updocker running on my M1 Mac Mini today after the update to nginx-proxy went up. I want to recount the steps I took to get it running. This is not fully official but, if like me, you need your tools back… any port in a storm.

1. Run 10updocker stop all and make sure all docker containers that are part of wp-local-docker global servers are destroyed (check docker ps -a).
2. Edit the ~/.wplocaldocker/global/docker-compose.yml file and update the image entry for the gateway from 10up/nginx-proxy to 10up/nginx-proxy:multiarch
3. Change image: mysql:5 to image: mariadb
4. If you had previous put platform: linux/x86_64 under your mysql settings remove it.
5. start or create an environment

Notes:

• I had a few conflicts getting this running at first. I had the mysql and nginx-proxy containers misfire. If you get port conflicts or docker is getting crashy I recommend opening up the dashboard for docker desktop and deleting the global_mysql_1 and global_gateway_1 container manually. After they are clear run 10updocker stop all and then attempt another start or create
• The mysql to mariaDB image switch is not the official path forward. This is a recommendation that I got from others. I was able to get it up and working. Its an in the moment patch, results may vary. Just remember that you made the change if things stop working in the near future.

[nicoladj77]

@jeremiahbratton so the workaround for now seems to be (tested by others):

In ~/.wplocaldocker/global/docker-compose.yml:

1. change mysql image from mysql to mariadb
2. change dns gateway image from 10up/nginx-proxy to nginxproxy/nginx-prox