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: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.
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?
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.)
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
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.
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
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?
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
So it’s installed on my machine and I can access it via my local network. I am happy now I get to mess around wit it.
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.
Hello, so I have a working farmOS container running through docker desktop, yay
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
Wow that is awful @keylum88! (But glad to hear you got it all working otherwise!)
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?
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.
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?
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?
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
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.
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.
