[ OK ] DietPi-Services | avahi-daemon active (running) since Tue 2024-02-20 21:46:39 GMT; 17min ago
[ OK ] DietPi-Services | proftpd active (running) since Tue 2024-02-20 21:46:47 GMT; 17min ago
[ OK ] DietPi-Services | nmbd active (running) since Tue 2024-02-20 21:46:47 GMT; 17min ago
[ OK ] DietPi-Services | smbd active (running) since Tue 2024-02-20 21:46:48 GMT; 17min ago
[ OK ] DietPi-Services | redis-server active (running) since Tue 2024-02-20 21:46:47 GMT; 17min ago
[ OK ] DietPi-Services | mariadb active (running) since Tue 2024-02-20 21:46:48 GMT; 17min ago
[ OK ] DietPi-Services | php8.2-fpm active (running) since Tue 2024-02-20 21:46:50 GMT; 17min ago
[ OK ] DietPi-Services | nginx active (running) since Tue 2024-02-20 22:03:38 GMT; 19s ago
[ OK ] DietPi-Services | docker active (running) since Tue 2024-02-20 21:46:47 GMT; 17min ago
[ OK ] DietPi-Services | cron active (running) since Tue 2024-02-20 21:46:48 GMT; 17min ago
[ OK ] DietPi-Services | dropbear active (running) since Tue 2024-02-20 21:46:46 GMT; 17min ago
[ INFO ] DietPi-Services | dietpi-vpn inactive (dead)
[ INFO ] DietPi-Services | dietpi-cloudshell inactive (dead)
[ OK ] DietPi-Services | dietpi-dashboard active (running) since Tue 2024-02-20 21:46:46 GMT; 17min ago
[ OK ] DietPi-Services | dietpi-ramlog active (exited) since Tue 2024-02-20 21:46:39 GMT; 17min ago
[ OK ] DietPi-Services | dietpi-preboot active (exited) since Tue 2024-02-20 21:46:39 GMT; 17min ago
[ OK ] DietPi-Services | dietpi-postboot active (exited) since Tue 2024-02-20 21:46:46 GMT; 17min ago
[ INFO ] DietPi-Services | dietpi-wifi-monitor inactive (dead)
Error log visible in google chrome developer tools console
Refused to apply style from '<URL>' because its MIME type ('application/octet-stream') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
dashboard/:1 Refused to apply style from 'https://cloud.xx.com/nextcloud/apps/dashboard/css/dashboard.css?v=30c53bef-4' because its MIME type ('application/octet-stream') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
dashboard/:1 Refused to apply style from 'https://cloud.xx.com/nextcloud/apps/user_status/css/user-status-menu.css?v=5dbcc382-4' because its MIME type ('application/octet-stream') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
dashboard/:1 Refused to apply style from 'https://cloud.xx.com/nextcloud/core/css/server.css?v=6647f0bf-4' because its MIME type ('application/octet-stream') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
dashboard/:1 Refused to apply style from 'https://cloud.xx.com/nextcloud/apps/activity/css/style.css?v=2e275d50-4' because its MIME type ('application/octet-stream') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
dashboard/:1 Refused to apply style from 'https://cloud.xx.com/nextcloud/apps/dashboard/css/dashboard.css?v=30c53bef-4' because its MIME type ('application/octet-stream') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
dashboard/:1 Refused to apply style from 'https://cloud.xx.com/nextcloud/apps/user_status/css/user-status-menu.css?v=5dbcc382-4' because its MIME type ('application/octet-stream') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
dashboard/:1 Refused to apply style from 'https://cloud.xx.com/nextcloud/core/css/server.css?v=6647f0bf-4' because its MIME type ('application/octet-stream') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
dashboard/:1 Refused to apply style from 'https://cloud.xx.com/nextcloud/apps/activity/css/style.css?v=2e275d50-4' because its MIME type ('application/octet-stream') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
What Webserver do you use? ah I see, also nginx but on an ARM64 system.
My nextcloud running on lighttpd didn’t break after the update.
Other users instance on nginx and x86 system also broke.
I’ve tried from different browsers and mobile browser and it doesn’t seem to be related to that. The following error log caught my attention. Somehow the server must not be able to read the css files.
Hmm, the MIME type is not set as expected. Let me check, probably types blocks within location blocks overwrite any parent block MIME type definitions. That would be one of these typical nasty Nginx behaviours for why I always prefer Apache.
Jep that’s it. Pure stupidity IMO, as if someone would want to have ALL MIME types for ALL file extensions busted when defining it for a single additional file extension within a location or server block. While for add_header, the same nasty behaviour is at least documented, for types I could not find a single hint about it, instead I even find lots of guides who do exactly this: define a single MIME type within a location block. And whatever I search for regarding location and/or server blocks overwriting parent types, I do not find a single matching entry, docs, blog of forum post about this …
Since we must serve mjs as JavaScript type for Nextcloud to function, we must additionally include the whole default types file above this block, while it is already included in the http block of /etc/nginx/nginx.conf …
sed -i '/types {/i\\tinclude mime.types;' /etc/nginx/sites-dietpi/dietpi-nextcloud.conf
systemctl restart nginx
You need to do an active (F5) of forced (CTRL+F5) page reload for the change to become effective.
I really can’t understand why Nginx behaves like this. This is so totally non-intuitive to me and means a lot of doubled definitions. We also need to add all security headers 3 times: In the default/parent config, within the Nextcloud location block and again within the sub-location block for Nextcloud assets, only because those have additionally a Cache-Control header set. Nextcloud’s official/documented Nginx config provided in their docs tapped into the same trap and served all assets without any security/privacy header for 2 years, until I found this recently when updating our Nginx config and fixed it. So it is not only me but I find this all the time in various documented Nginx configs across various software projects. This is not only an unnecessary additional maintenance and coding burden, but a security issue as well. Enough for this rant for today …
I’ll set up a live patch to have this fixed for everyone.