Hello,
First time using farmOS installed in my own personal computer. Everything in the installation seemed to be ok but when I enter to the dashboard (ar any other page) the default theme is not applied:
But when I put the site into maintenance mode, the theme is correctly applied.
Any hint of what could be going on?
It could caused by a number of issues.
Things to check:
Itās worth looking through this page, if you havenāt already Installing farmOS | farmOS
And remember to clear caches after trying any fixes.
Hi Ed, thanks for answering.
chmod 777. I had tried 775 but it was not sufficient to pass all the errors in the Requirements page prior installation. Is there any other directory I should check permissions?Checking the Installing farmOS page:
@bejuco Can you describe your setup in a little more detail? Are you hosting in Docker? Is the host OS Linux/Mac/Windows?
Of course. I have a Linux machine (kernel v.6.6.37 LTS) using EndevourOS. Iām using apache (2.4.61), php (8.3.9) and mariadb (11.4.2).
/srv/http directory) using a packaged release tarball (v3.2.2).<VirtualHost 127.0.0.1:85>
ServerName goyita-farmos.com
DocumentRoot "/srv/http/farmOS/web"
<Directory "/srv/http/farmOS/web">
Options FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
Require all granted
</Directory>
</VirtualHost>
I did try to create a development environment but whenever I ran docker compose up -d and opened http://localhost, the broser had a āConnection was resetā error page. So I stopped trying. I think there is a conflict between the docker-proxy service and apache.
@bejuco Thanks!
Thatās interesting that it works when you are in maintenance mode. It may be that maintenance mode disables āCSS/JS aggregationā, which I suspect is whatās causing your problem. You can test that yourself by going to /admin/config/development/performance and unchecking both boxes in the āBandwidth optimizationā section. (This is also where you can manually clear caches via the button at the top.)
If turning off CSS/JS aggregation fixes the problem, then that indicates that Drupal is unable to write CSS and JS files to your public files directory for some reason (usually permissions). So I would double check that. This looks like it describes what the permissions should be succinctly (and links to the much longer Drupal docs page for more details): 7 - What are the recommended directory permissions? - Drupal Answers
I wouldnāt recommend leaving CSS/JS aggregation turned off as a permanent solution. It indicates that thereās a deeper issue with Drupalās ability to write files to the directories it needs to, which means other issues may arise besides this one.
You can also go to /admin/config/media/file-system to see how your public/private/temporary files directories are configured. That page may provide a warning/error if they are not correctā¦ I forget.
Hope that helps!
Yep, the CSS/JS aggregation was it. I turned them off and and the theme is applied correctly. However, when I change the permissions of the different directories to the values recommended on the link you shared I get new problems.
I canāt toggle ON the CSS/JS Aggregation options. I get a Set up the optimized assets file system path to make these optimizations available message. I can only get rid of the message if I set 777 both on the /default and /default/files directories.
I donāt see any warnings or errors on the file-system page nor the status report page related to file paths.
@bejuco Who is the owner and group of the directories? The important thing is that they are writeable by the same user that Apache uses (often www-data).
@mstenta root in both cases. Apache is using the user/group http. So I guess I have to set permissions to that user/group?
Checking the status report page again I get a Configuration files error: The directory sites/default is not protected from modifications and poses a security risk. You must change the directoryās permissions to be non-writable.
Iām sorry but is a little bit confusing for me. Directories should be writable only by the owners and the user Apache uses right?
OK if the user and group of sites/default/files is root, and the permissions are 755, that means that only the root user is allowed to write to it.
One option would be for you to change the owner and group of sites/default/files to http (if thatās the user that Apache is running its workers under).
This error would be shown if you use 777 permissions. This means that ALL USERS are able to write to that directory, which is a security risk.
Correct. So you can either make the sites/default/files directory owned by http and give it 755 permissions, or you can make it owned by root (or some other user) with a group of http and 775 permissions. I prefer to just make it owned by www-data in my case (http in yours).
@mstenta Just configured the folders to be owned by root and with a group of http with 775 permissions. Still no luck. When I toggle ON the CSS/JS Aggregates, the theme is not applied. Maybe is something that must be done prior the installation process?
What other issues could arise if I left the aggregates turned off?
@bejuco Are you 100% sure that Apacheās workers are running as the http user? Is it possible that it is actually www-data (this is most common in my experience, but can vary based on distro, and Iām not familiar with EndeavorOS). Iām not sure what else could cause the problem.
Nope. Iāve helped people debug this problem many times. It is almost always a permissions issue (or something weird because of Windows hosts related to permissions), and once the permissions are corrected it works. You do not need to reinstall.
BUTā¦ you may need to clear the cache! And by that I mean Drupalās cache, which I pointed to in a previous comment. There is a button in the Performance configuration page to do so. After you change the permissions make sure you clear the cache and then turn on aggregation.
What other issues could arise if I left the aggregates turned off?
Aggregation turned off isnāt a big issue by itself. It will reduce your performance because youāll be loading potentially dozens of separate CSS+JS files with each request, instead of 1 or 2.
The bigger issue is that Drupal canāt write files. This means you canāt upload anything to farmOS. No photos, documents, CSV imports, etcā¦ There may be other important things that Drupal needs to write other than that, Iām not sure.
If your site is not publicly exposed to the internet, then maybe you donāt need to worry about setting perms to 777. But I prefer to do things correctly and understand āwhyā something is or isnāt working properly, so it can be fixed properly.
Hi @mstenta. Iām sure. The httpd.conf has
User http
Group http
and this is the output of ps aux | grep -E '(apache|httpd)':
root 721 0.0 0.1 397680 28832 ? Ss 16:39 0:00 /usr/bin/httpd -k start -DFOREGROUND
http 786 0.0 0.2 400360 34740 ? S 16:39 0:00 /usr/bin/httpd -k start -DFOREGROUND
http 787 0.1 0.2 404676 46980 ? S 16:39 0:00 /usr/bin/httpd -k start -DFOREGROUND
http 788 0.0 0.2 402312 36504 ? S 16:39 0:00 /usr/bin/httpd -k start -DFOREGROUND
http 789 0.0 0.2 400264 34680 ? S 16:39 0:00 /usr/bin/httpd -k start -DFOREGROUND
http 790 0.0 0.2 402312 36664 ? S 16:39 0:00 /usr/bin/httpd -k start -DFOREGROUND
http 3002 0.0 0.2 402312 36616 ? S 16:40 0:00 /usr/bin/httpd -k start -DFOREGROUND
http 3051 0.0 0.0 397924 10404 ? S 16:40 0:00 /usr/bin/httpd -k start -DFOREGROUND
http 3052 0.0 0.0 397924 10404 ? S 16:40 0:00 /usr/bin/httpd -k start -DFOREGROUND
http 3053 0.0 0.0 397924 10404 ? S 16:40 0:00 /usr/bin/httpd -k start -DFOREGROUND
http 3054 0.0 0.0 397924 10404 ? S 16:40 0:00 /usr/bin/httpd -k start -DFOREGROUND
pierre 3305 0.0 0.0 9024 2288 pts/0 S+ 16:42 0:00 grep --color=auto -E (apache|httpd)
I did clear the Drupalās cache. Every time I change chmod I restart apache, clear browser chache and Drupalās cache with that button.
But I have been able to upload files in farmOS. I did it with various .geojson for land assets and a .jpeg for a plant type. They are in the /sites/default/private/files/farm directory 
I was thinking about that. Itās gonna be a local project so Itās not that bad. But I agree with you, Iād prefer to know everything is correctly set.
Huh! Well Iām stumped then. I assumed that file uploads didnāt work too.
Could it be that the sites/default/files/css and js directories specifically have the wrong owner/permissions? Those are where Drupal writes the aggregated files so they can be loaded quickly.
Well, those directories donāt exist! In the sites/default/files directory thereās only a config_zQvXnUZ... folder and a php folder. Maybe thatās the problem?
Oh. Wellā¦ Drupal should create those directories itself, on-demand I believe. And as long as Apache can write to the parent directory it should be able to do that. You could try creating them yourself (and make them writable by Apache) and see if that allows you to turn on aggregation. Still curious why it didnāt create them itself thoughā¦
I tried creating the directories but when I clear Drupalās cache, they are deleted, both with CSS/JS aggregate on and off.
Hmm OK. Iām skimming through an issue on Drupal.org that might help, starting with this comment:
https://www.drupal.org/project/drupal/issues/3381293#comment-15206160
There are a few comments that follow from there that might be worth trying in your environment.
Someone describes an issue (in their case it was Nginx, not Apache), where Nginx was sending the requests directly to the filesystem for the aggregated files, rather than letting Drupal process them, thus Drupal never got the chance to create them. Not sure if the same thing is happening in your case.
Please let me know if you figure it out. It might be helpful to add something to farmOS docs if itās a missing configuration.
Thanks for all your help @mstenta. Iāll let you know any workaround.
Iām having the same issue with a fresh install of FarmOS 3.2.2 on Ubuntu 24.04. Do install, do the initial configuration, and the webapp renders with just text as shown above. I also didnāt have the /var/www/html/farmOS/web/sites/default/css or /var/www/html/farmOS/web/sites/default/js directories. I created them and chown/chmod to match the default dir. Did the drush cr and restarted apache2. No love.
Looking at the access log, all the GET calls for css and js files return a 404.
Whatās also odd is that none of the links workā¦ on the page. All return 404.