Using Docker to run FarmOS on Windows 10

Hello, I got docker all set up on my windows 10 machine. I enabled virtualization in the bios, installed the Windows Subsystem for Linux Update and got the containers running (www1 and db1). Unfortunately when I try to access my localhost I get this message:

Forbidden

You don’t have permission to access this resource.Server unable to read htaccess file, denying access to be safe

I tried the altering .htaccess file permissions (located in www/web) to full control, but that didn’t do it. Here are the logs for the www1 container:

[Thu Mar 24 18:45:07.667337 2022] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.52 (Debian) configured -- resuming normal operations

[Thu Mar 24 18:45:07.667499 2022] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'

[Thu Mar 24 18:45:10.375285 2022] [core:crit] [pid 19] (13)Permission denied: [client 172.18.0.1:58764] AH00529: /var/www/html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/var/www/html/' is executable

[Thu Mar 24 18:45:10.660352 2022] [core:crit] [pid 19] (13)Permission denied: [client 172.18.0.1:58764] AH00529: /var/www/html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/var/www/html/' is executable, referer: http://localhost/

farmOS codebase not detected. Copying from pre-built files in the Docker image.

Attempting: apache2-foreground

172.18.0.1 - - [24/Mar/2022:18:45:10 +0000] "GET / HTTP/1.1" 403 553 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.83 Safari/537.36"

172.18.0.1 - - [24/Mar/2022:18:45:10 +0000] "GET /favicon.ico HTTP/1.1" 403 552 "http://localhost/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.83 Safari/537.36"

What I don’t understand is that it’s referencing the path “/var/www/html/.htaccess” which I cannot find in the codebase that docker downloaded onto my computer anywhere. Was hoping someone had some advice on how to proceed?

Thanks so much!

-Alex

I think a few have had issues with windows docker install.

I don’t have any experience with the Linux subsystem for Windows but the issue looks like file permissions/ownership issue. The .htaccess is a hidden file so if trying to view in windows turn on view hidden files in folder options.

does the Linux Subsystem give you access to a Linux terminal? if so
ls -a (lists all files including hidden).
chown www-data (change ownership of files)
chgrp www-data (change Group)
chmod (change permissions.)

1 Like

Thanks for starting this thread @keylum88! I just want to copy a comment from the other thread because it may still be relevant:

The farmos/farmos:2.x-dev image is specifically for farmOS core development, and it has one important assumption baked into it which may be Linux-specific (since all the core farmOS devs use Linux as their environment). It could be that this is causing issues in Windows environments.

And in general, the 2.x-dev image is going to include other things like XDebug which will slow down your environment. So if you don’t need those development tools then you should use a tagged image like farmos/farmos:2.0.0-beta3 - that is best practice, as described here: Installing farmOS | farmOS

Hello, thank you for the reply! :slight_smile:

After I started the www1 container the logs indicate that the farmos codebase needed to be copied from pre-built files in the Docker image. This takes about 3 minutes and then a “web” folder shows up in my “www” folder. This is where the .htaccess file seems to be located. My question is why does the error message reference an .htaccess file inside “var/www/html” when that’s not the folder structure of the codebase which is “www/web/.htaccess” I have tried to granting full access to these folders and specifically the .htaccess, but with no effect.

Here is a screen shot of my farmos web directory:

Another thing is that originally I got the Drupal system to work. And I actually started the installation and had the db working. What happened was when I was installing the modules it hung up on 9% for 20 minutes which made me think it had failed. So I interrupted the installation, deleted everything and started over. Only after this did the permissions thing start happening. Another weird thing is that I tried to do the exact same thing on a different computer on my network it didn’t work at all and had the permissions problem from the get go. So I am confused hehe :slight_smile:

1 Like

Hello mstenta, I tried doing the whole process using 2.0.0-beta3, but I got the same result. When I try to access localhost it just says:

Forbidden

You don’t have permission to access this resource.Server unable to read htaccess file, denying access to be safe

I’m hoping that it’s just a permissions problem and once that is resolved I can start the install.

If that doesn’t work, however, I was thinking about just following the “web/core/install.txt” directions and setting up apache, nginx, php and postgreSQL manually. Would that be a good idea?

1 Like

Ah…

Its probably an issue with the bind mount then, have you completely removed the folders on the host machine before restarting the process?

You could also try binding to a new folder if unsure.

1 Like

Hello Farmer-Ed, thank you so much for your help! :slight_smile:

So I was able to get it working :slight_smile:

I am pretty sure the problem was that I was restarting the container before it was done (as a troubleshooting method). I didn’t realize that after I ran the command “docker-compose up -d” I still had to wait for a bunch of processes to happen in the background. The “Getting Started” section in the docs seem to imply that you can access localhost immediately after running the command. When in reality it can take up to 10 minutes for everything to happen in order for localhost to show the app. So it’s just a matter of patience :slight_smile:

So it’s installed on my machine and I can access it via my local network. I am happy :slight_smile: now I get to mess around wit it.

Thank you so much for your help :slight_smile: :grin:

3 Likes

Thanks @keylum88 for figuring this out. I was actually trying to do the exact same, getting farmOS running on a windows machine, and running in the the same errors as you. It seems to just take much much longer on a widows machine then it does Linux.

1 Like

Hello, so I have a working farmOS container running through docker desktop, yay :slight_smile:

So the next challenge is how long each page is taking to load. Every time I try to navigate from page to page it takes about 10 seconds to load. What kind of troubleshooting can be done to improve the page load time while running farmOS on my localhost?

I am running Windows 10 on an Intel Core i5-2500k CPU @ c.30Ghz (4 CPUs), ~4.0Ghz with 8192MB of RAM.

Thank you so much for this system! I am excited to get it running smoothly :slight_smile:

1 Like

Wow that is awful @keylum88! (But glad to hear you got it all working otherwise!) :smiley:

I think someone else reported similar performance issues, but on Mac. I haven’t experienced this myself, and I don’t have a Windows box to test on, so I’m not sure how much help I can be, but it does seem to be a common problem for folks using Docker on Windows/Mac. I don’t think it’s the fault of farmOS, but if we can narrow it down to something that we can improve then we should!

My guess is that it is related to the bind-mounted volumes. My hypothesis to test this would be: run the container without any volumes and see if it works better. (You will need to reinstall a new database from scratch for it to work, and of course without volumes you will lose everything after the container is destroyed, so only use this for testing…)

I’ll try to dig up the other forum topic…

EDIT: Hmm can’t seem to find it with a quick search. Maybe someone else remembers the thread I’m thinking of? :sweat_smile:

Hey mstenta, thank you for the reply! :slight_smile:

According to my Docker Desktop, I am running 2 containers: farmos-www1 and farmos-db1 and two images: farmos/farmos and postgres. But when I click on volumes it says I don’t have any running. I am sorry I am still learning docker atm and am not terribly familiar with volumes yet.

1 Like

I did try one thing: I created a file called “index_new.php” in the web directory and put a static html template with some hello world text inside. Then I went to http://localhost/index_new.php and it instantly came up. Doesn’t that mean that the problem lies within the farmOS Drupal?

1 Like

@keylum88 Can you describe the steps you took to set this up?

Did you use either of the guides on farmOS.org?

Are you using Docker Compose? With one of the templates provided?

There are a LOT of ways to set up a farmOS instance in Docker… we provide those as recommended ways to try to guide users in the right direction, but it’s also possible to do it differently, so understanding exactly what you did would help narrow things down.

when I click on volumes it says I don’t have any running. I am sorry I am still learning docker atm and am not terribly familiar with volumes yet.

Docker containers are meant to be “stateless” - meaning they will run an application without saving anything. So if you restart the container you are starting completely fresh. In order to “persist” things you need to mount a volume (basically mapping a directory from outside of the container to a directory inside the container), so that anything in the volume is saved. farmOS requires a volume in order to save (at the very least) the Drupal sites directory, which will contain your settings.php file (which tells Drupal how to connect to the database), and any files you upload to farmOS. Likewise, you need to mount a volume into your PostgreSQL container to save your database. If you aren’t using any volumes you will lose all your data when the container is destroyed (eg: when you upgrade to a new version of farmOS).

I did try one thing: I created a file called “index_new.php” in the web directory and put a static html template with some hello world text inside.

When you say “in the web directory”, where do you mean specifically? Is this a directory in your Windows environment? If so, then it is probably a volume (and might suggest that you used the docker-compose.development.yml template?) Or, did you find your way into the Linux shell environment of the container itself and create that file?

1 Like

Just to add…

Doesn’t that mean that the problem lies within the farmOS Drupal?

Not necessarily. For example, this long-standing issue with Docker volumes on Mac OS is an upstream Docker issue: File access in mounted volumes extremely slow · Issue #77 · docker/for-mac · GitHub

1 Like

Hey mstenta, I installed Docker Desktop which made me install the Windows Subsystem for Linux (for some computers I have to go into the BIOS and enable virtualization). After docker desktop was installed and running I created a folder on my C drive called “Drupal” and then inside of that I created a folder called “farmOS.” Then I used Git Bash to cd into that directory then ran the commands in the getting started link you posted.

After it all gets done I have a “www” folder inside of “farmOS” which contains a “web” folder. This is where the original index.php is and where I created the “index_new.php.”

Docker containers are meant to be “stateless” - meaning they will run an application without saving anything. So if you restart the container you are starting completely fresh.

I am a little bit confused because I have restarted my container many times and I still have the same app with the same data. For example I just had to log into it with my user that I created upon installation a month ago. That user data is persisting, so I am not sure what you referring to. I need to watch some more docker tutorial videos :slight_smile:

1 Like

Thanks @keylum88! It sounds like you set up a development environment.

I don’t know if this is related, but the development image includes tools that you don’t need like XDebug - which certainly adds some overhead to the performance… although normally not 10 seconds worth!

That said, you might have better luck with a non-development image, and in fact I would recommend that you use a specific tagged version so that you can upgrade to new version intentionally (and not accidentally) in the future. So instead of Getting started | farmOS you should refer to Installing farmOS | farmOS

The docker-compose.production.yml template only mounts the sites directory as a volume, rather than the whole webroot. This could also improve your performance greatly, as the whole webroot has LOTS of files, and maybe that causes the volume to slow things down in your context (I’m not sure).

I am a little bit confused because I have restarted my container many times and I still have the same app with the same data.

If you used the docker-compose.development.yml template then you are using volumes. Thus, your data is being persisted.

Also I mispoke a bit…

So if you restart the container you are starting completely fresh.

It woudn’t be on “restart” that you lose data… it would be when the container is destroyed/recreated. That would happen when you try to upgrade farmOS in the future. But it sounds like you are using volumes, so this isn’t an issue.

1 Like

Hey mstenta, OK I will pivot to the other guide and see how far I can get :slight_smile:

Thank you SO MUCH for the support.

1 Like

Sounds good! Feel free to ask questions here if anything is unclear. :slight_smile:

Good idea to test that!

It sounds like that test wouldn’t have involved the database - whereas almost everything in Drupal/farmOS involves at least one database query.

Another hypothesis this suggests is that perhaps all database queries are slow due to something about how the database is interacting with the volumes/filesystem/etc.

You might be able to test this hypothesis by trying a command something like this;

docker-compose exec db psql -U farm --command "SELECT * FROM menu_tree;"

Assuming you are using docker-compose and have named your database container “db”, this should print a bunch of rows related to the menus in Drupal/farmOS. If it completes nearly instantly (as it should) it would go a long way towards demonstrating that the DB requests in general aren’t the source of the excessive latency you were experiencing.

1 Like