Seems there is something wrong with te latest part?
remove that folowing small location / block
And pls, don’t change anything else inside /etc/nginx/sites-dietpi/dietpi-nextcloud.conf except removing the nextcloud sub folder. On my demo system, following is working. Simply delete the whole content of your file and replace it fully with:
# Based on: https://github.com/nextcloud/documentation/blob/master/admin_manual/installation/nginx-subdir.conf.sample
# Redirect webfinger and nodeinfo requests to Nextcloud endpoint
location /.well-known/webfinger { return 301 /index.php$request_uri; }
location /.well-known/nodeinfo { return 301 /index.php$request_uri; }
location ^~ / {
# Omit Nginx version on error response
server_tokens off;
# Set max upload size
client_max_body_size 1048576M;
fastcgi_buffers 64 4K;
# Enable gzip but do not remove ETag headers
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
# HTTP response headers borrowed from Nextcloud `.htaccess`
#add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;
add_header Referrer-Policy "no-referrer" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Download-Options "noopen" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Permitted-Cross-Domain-Policies "none" always;
add_header X-Robots-Tag "none" always;
add_header X-XSS-Protection "1; mode=block" always;
# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;
# Specify how to handle directories -- specifying `/nextcloud/index.php$request_uri`
# here as the fallback means that Nginx always exhibits the desired behaviour
# when a client requests a path that corresponds to a directory that exists
# on the server. In particular, if that directory contains an index.php file,
# that file is correctly served; if it doesn't, then the request is passed to
# the front-end controller. This consistent behaviour means that we don't need
# to specify custom rules for certain paths (e.g. images and other assets,
# `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
# `try_files $uri $uri/ /nextcloud/index.php$request_uri`
# always provides the desired behaviour.
index index.php index.html /index.php$request_uri;
# Rule borrowed from `.htaccess` to handle Microsoft DAV clients
location = / {
if ( $http_user_agent ~ ^DavClnt ) {
return 302 /remote.php/webdav/$is_args$args;
}
}
# Rules borrowed from `.htaccess` to hide certain paths from clients
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/) { return 404; }
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) { return 404; }
# Ensure this block, which passes PHP files to the PHP process, is above the blocks
# which handle static assets (as seen below). If this block is not declared first,
# then Nginx will encounter an infinite rewriting loop when it prepends
# `/nextcloud/index.php` to the URI, resulting in a HTTP 500 error response.
location ~ \.php(?:$|/) {
fastcgi_split_path_info ^(.+?\.php)(/.*|)$;
set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param HTTPS $https;
fastcgi_param modHeadersAvailable true; # Avoid sending the security headers twice
fastcgi_param front_controller_active true; # Enable pretty URLs without /index.php/
fastcgi_pass php;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
fastcgi_max_temp_file_size 0; # Allow downloads > 1 GiB: https://github.com/nextcloud/documentation/pull/7979
}
location ~ \.(?:css|js|svg|gif|png|jpg|ico|wasm|tflite|map)$ {
try_files $uri /index.php$request_uri;
expires 6M; # Cache-Control policy borrowed from `.htaccess`
access_log off; # Optional: Don't log access to assets
}
location ~ \.woff2?$ {
try_files $uri /index.php$request_uri;
expires 7d; # Cache-Control policy borrowed from `.htaccess`
access_log off; # Optional: Don't log access to assets
}
# Rule borrowed from `.htaccess`
location /remote {
return 301 /remote.php$request_uri;
}
location / {
try_files $uri $uri/ /index.php$request_uri;
}
}
1 Like
The idea with the dedicated file was so that Nextcloud reinstalls won’t overwrite them. But at least the Cal/CardDAV redirects would conflict anyway without adjusting the original file.
Sadly I get this error with your file
root@DietPi:~# nano /etc/nginx/sites-dietpi/dietpi-nextcloud.conf
root@DietPi:~# systemctl restart nginx
Job for nginx.service failed because the control process exited with error code.
See “systemctl status nginx.service” and “journalctl -xe” for details.
root@DietPi:~# systemctl status nginx.service
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2023-01-08 13:30:18 CET; 1min 20s ago
Docs: man:nginx(8)
Process: 23109 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)
CPU: 33msJan 08 13:30:18 DietPi systemd[1]: Starting A high performance web server and a reverse proxy server…
Jan 08 13:30:18 DietPi nginx[23109]: nginx: [emerg] duplicate location “/” in /etc/nginx/sites-enabled/default:11
Jan 08 13:30:18 DietPi nginx[23109]: nginx: configuration file /etc/nginx/nginx.conf test failed
Jan 08 13:30:18 DietPi systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Jan 08 13:30:18 DietPi systemd[1]: nginx.service: Failed with result ‘exit-code’.
Jan 08 13:30:18 DietPi systemd[1]: Failed to start A high performance web server and a reverse proxy server.
root@DietPi:~#
root@DietPi:~# journalctl -xe
Jan 08 13:09:01 DietPi systemd[1]: Starting Clean php session files…
░░ Subject: A start job for unit phpsessionclean.service has begun execution
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ A start job for unit phpsessionclean.service has begun execution.
░░
░░ The job identifier is 7010.
Jan 08 13:09:01 DietPi systemd[1]: phpsessionclean.service: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ The unit phpsessionclean.service has successfully entered the ‘dead’ state.
Jan 08 13:09:01 DietPi systemd[1]: Finished Clean php session files.
░░ Subject: A start job for unit phpsessionclean.service has finished successfully
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ A start job for unit phpsessionclean.service has finished successfully.
░░
░░ The job identifier is 7010.
Jan 08 13:10:01 DietPi CRON[22713]: pam_unix(cron:session): session opened for user www-data(uid=33) by (uid=0)
Jan 08 13:10:01 DietPi CRON[22714]: (www-data) CMD (php /var/www/nextcloud/cron.php)
Jan 08 13:10:07 DietPi CRON[22713]: pam_unix(cron:session): session closed for user www-data
Jan 08 13:15:01 DietPi CRON[22821]: pam_unix(cron:session): session opened for user www-data(uid=33) by (uid=0)
Jan 08 13:15:01 DietPi CRON[22822]: (www-data) CMD (php /var/www/nextcloud/cron.php)
Jan 08 13:15:09 DietPi CRON[22821]: pam_unix(cron:session): session closed for user www-data
Jan 08 13:17:01 DietPi CRON[22827]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Jan 08 13:17:01 DietPi CRON[22828]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Jan 08 13:17:01 DietPi CRON[22827]: pam_unix(cron:session): session closed for user root
Jan 08 13:20:01 DietPi CRON[22871]: pam_unix(cron:session): session opened for user www-data(uid=33) by (uid=0)
Jan 08 13:20:01 DietPi CRON[22872]: (www-data) CMD (php /var/www/nextcloud/cron.php)
Jan 08 13:20:07 DietPi CRON[22871]: pam_unix(cron:session): session closed for user www-data
Jan 08 13:25:01 DietPi CRON[22979]: pam_unix(cron:session): session opened for user www-data(uid=33) by (uid=0)
Jan 08 13:25:01 DietPi CRON[22980]: (www-data) CMD (php /var/www/nextcloud/cron.php)
Jan 08 13:25:08 DietPi CRON[22979]: pam_unix(cron:session): session closed for user www-data
Jan 08 13:28:52 DietPi dhclient[537]: DHCPREQUEST for 192.168.2.5 on eth0 to 192.168.2.1 port 67
Jan 08 13:28:52 DietPi dhclient[537]: DHCPACK of 192.168.2.5 from 192.168.2.1
Jan 08 13:28:53 DietPi dhclient[537]: bound to 192.168.2.5 – renewal in 1400 seconds.
Jan 08 13:30:01 DietPi CRON[23100]: pam_unix(cron:session): session opened for user www-data(uid=33) by (uid=0)
Jan 08 13:30:01 DietPi CRON[23101]: (www-data) CMD (php /var/www/nextcloud/cron.php)
Jan 08 13:30:12 DietPi CRON[23100]: pam_unix(cron:session): session closed for user www-data
Jan 08 13:30:18 DietPi systemd[1]: Stopping A high performance web server and a reverse proxy server…
░░ Subject: A stop job for unit nginx.service has begun execution
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ A stop job for unit nginx.service has begun execution.
░░
░░ The job identifier is 7068.
Jan 08 13:30:18 DietPi systemd[1]: nginx.service: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ The unit nginx.service has successfully entered the ‘dead’ state.
Jan 08 13:30:18 DietPi systemd[1]: Stopped A high performance web server and a reverse proxy server.
░░ Subject: A stop job for unit nginx.service has finished
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ A stop job for unit nginx.service has finished.
░░
░░ The job identifier is 7068 and the job result is done.
Jan 08 13:30:18 DietPi systemd[1]: nginx.service: Consumed 31.117s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ The unit nginx.service completed and consumed the indicated resources.
Jan 08 13:30:18 DietPi systemd[1]: Starting A high performance web server and a reverse proxy server…
░░ Subject: A start job for unit nginx.service has begun execution
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ A start job for unit nginx.service has begun execution.
░░
░░ The job identifier is 7068.
Jan 08 13:30:18 DietPi nginx[23109]: nginx: [emerg] duplicate location “/” in /etc/nginx/sites-enabled/default:11
Jan 08 13:30:18 DietPi nginx[23109]: nginx: configuration file /etc/nginx/nginx.conf test failed
Jan 08 13:30:18 DietPi systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ An ExecStartPre= process belonging to unit nginx.service has exited.
░░
░░ The process’ exit code is ‘exited’ and its exit status is 1.
Jan 08 13:30:18 DietPi systemd[1]: nginx.service: Failed with result ‘exit-code’.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ The unit nginx.service has entered the ‘failed’ state with result ‘exit-code’.
Jan 08 13:30:18 DietPi systemd[1]: Failed to start A high performance web server and a reverse proxy server.
░░ Subject: A start job for unit nginx.service has failed
░░ Defined-By: systemd
░░ Support: Debian -- User Support
░░
░░ A start job for unit nginx.service has finished with a failure.
░░
░░ The job identifier is 7068 and the job result is failed.
root@DietPi:~#
With the following NC is working
/etc/nginx/sites-dietpi/dietpi-nextcloud.conf
Based on: documentation/admin_manual/installation/nginx-subdir.conf.sample at master · nextcloud/documentation · GitHub
Redirect webfinger and nodeinfo requests to Nextcloud endpoint
location /.well-known/webfinger { return 301 /nextcloud/index.php$request_uri; }
location /.well-known/nodeinfo { return 301 /nextcloud/index.php$request_uri; }location ^~ /nextcloud {
# Omit Nginx version on error response server_tokens off; # Set max upload size client_max_body_size 1048576M; fastcgi_buffers 64 4K; # Enable gzip but do not remove ETag headers gzip on; gzip_vary on; gzip_comp_level 4; gzip_min_length 256; gzip_proxied expired no-cache no-store private no_last_modified no_etag auth; gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml app> # HTTP response headers borrowed from Nextcloud `.htaccess` add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always; add_header Referrer-Policy "no-referrer" always; add_header X-Content-Type-Options "nosniff" always; add_header X-Download-Options "noopen" always; add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Permitted-Cross-Domain-Policies "none" always; add_header X-Robots-Tag "none" always; add_header X-XSS-Protection "1; mode=block" always; # Remove X-Powered-By, which is an information leak fastcgi_hide_header X-Powered-By; # Specify how to handle directories -- specifying `/nextcloud/index.php$request_uri` # here as the fallback means that Nginx always exhibits the desired behaviour # when a client requests a path that corresponds to a directory that exists # on the server. In particular, if that directory contains an index.php file, # that file is correctly served; if it doesn't, then the request is passed to # the front-end controller. This consistent behaviour means that we don't need # to specify custom rules for certain paths (e.g. images and other assets, # `/updater`, `/ocm-provider`, `/ocs-provider`), and thus # `try_files $uri $uri/ /nextcloud/index.php$request_uri` # always provides the desired behaviour. index index.php index.html /nextcloud/index.php$request_uri; # Rule borrowed from `.htaccess` to handle Microsoft DAV clients location = /nextcloud { if ( $http_user_agent ~ ^DavClnt ) { return 302 /nextcloud/remote.php/webdav/$is_args$args; } } # Rules borrowed from `.htaccess` to hide certain paths from clients location ~ ^/nextcloud/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/) { return 404; } location ~ ^/nextcloud/(?:\.|autotest|occ|issue|indie|db_|console) { return 404; } # Ensure this block, which passes PHP files to the PHP process, is above the blocks # which handle static assets (as seen below). If this block is not declared first, # then Nginx will encounter an infinite rewriting loop when it prepends # `/nextcloud/index.php` to the URI, resulting in a HTTP 500 error response. location ~ \.php(?:$|/) { fastcgi_split_path_info ^(.+?\.php)(/.*|)$; set $path_info $fastcgi_path_info; try_files $fastcgi_script_name =404; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param HTTPS $https; fastcgi_param modHeadersAvailable true; # Avoid sending the security headers twice fastcgi_param front_controller_active true; # Enable pretty URLs without /index.php/ fastcgi_pass php; fastcgi_intercept_errors on; fastcgi_request_buffering off; fastcgi_max_temp_file_size 0; # Allow downloads > 1 GiB: https://github.com/nextcloud/documentation/pull/7979 } location ~ \.(?:css|js|svg|gif|png|jpg|ico|wasm|tflite|map)$ { try_files $uri /nextcloud/index.php$request_uri; expires 6M; # Cache-Control policy borrowed from `.htaccess` access_log off; # Optional: Don't log access to assets } location ~ \.woff2?$ { try_files $uri /nextcloud/index.php$request_uri; expires 7d; # Cache-Control policy borrowed from `.htaccess` access_log off; # Optional: Don't log access to assets } # Rule borrowed from `.htaccess` location /nextcloud/remote { return 301 /nextcloud/remote.php$request_uri; } location /nextcloud { try_files $uri $uri/ /nextcloud/index.php$request_uri; }}
But having these warnings
There are some warnings regarding your setup.
- Your web server is not properly set up to resolve “/.well-known/webfinger”. Further information can be found in the documentation
.
- Your web server is not properly set up to resolve “/.well-known/nodeinfo”. Further information can be found in the documentation
You did not remove the default location block from default configuration file as I stated above. Therefore you have a duplicate root directory configured.
Strange, probably forgot to save the file after editing
Edited default , saved it, edited the config file with your version , restart NC
we are getting there
There are some warnings regarding your setup.
The “Strict-Transport-Security” HTTP header is not set to at least “15552000” seconds. For enhanced security, it is recommended to enable HSTS as described in the security tips
‘default’ contains
add_header Strict-Transport-Security “max-age=31536000” always; # managed by Certbot
and is missing the 'includeSubDomains" 'option
‘config’ contains
#add_header Strict-Transport-Security “max-age=15768000; includeSubDomains” always;
Brute-force protection
The information on the DietPi website can be updated
The separate app “Brute-force settings” is no longer needed with Nextcloud 25, because it’s already included. The “Brute-force IP Whitelist settings” can be found under “Administration Settings” → “Security”.
lhttps://help.nextcloud.com/t/nextcloud-25-0-1-is-there-bruteforce-app-is-not-compatible/149693
App is now released alongside with Nextcloud core, thus this page is deprecated.
any idea how to fix this as it is enabled in the ‘default’ file?
can the DietPi Wiki be updated with the above info?
Just remove the # and it will be overwrite the default config.
So the ‘default’ and the ‘config’ files do not work together?
Which has priority for the options?
just to avoid a misunderstanding. What config file you mean exactly
the one we are editing for two weeks allready 
/etc/nginx/sites-available/default
and
nano /etc/nginx/sites-dietpi/dietpi-nextcloud.conf
I think he means /etc/nginx/sites-available/default as default and /etc/nginx/sites-dietpi/dietpi-nextcloud.conf as config.
And in the nextcloud.conf the line is commented?!
#add_header Strict-Transport-Security “max-age=15768000; includeSubDomain
the file
/etc/nginx/sites-available/default
contains
add_header Strict-Transport-Security “max-age=31536000” always; # managed by Certbot
and is missing the 'includeSubDomains" 'option
the file
/etc/nginx/sites-dietpi/dietpi-nextcloud.conf
contains
#add_header Strict-Transport-Security “max-age=15768000; includeSubDomains” always;
and disabled
so “max-age=31536000” is set ON and enabled inside ‘default’
still I get the warning:
There are some warnings regarding your setup.
The “Strict-Transport-Security” HTTP header is not set to at least “15552000” seconds. For enhanced security, it is recommended to enable HSTS as described in the security tips
Why is > add_header Strict-Transport-Security “max-age=31536000” always; # managed by Certbot
in ‘default’ not recognized and used?
I’m lost in your configuration files. Not sure what you do. I did again a test install and for me values correctly set inside dietpi-nextcloud.conf. The value is not commented by a #
root@DietPiR5S:~# cat /etc/nginx/sites-dietpi/dietpi-nextcloud.conf | grep Strict-Transport-Security
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;
root@DietPiR5S:~#
As well, the setting is clearly done by our tool dietpi-letsencrypt at the end of creating certificates.
...
[ OK ] DietPi-LetsEncrypt | Comment in /etc/nginx/sites-dietpi/dietpi-nextcloud.conf converted to setting: add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;
[ OK ] DietPi-LetsEncrypt | systemctl restart nginx
Means, I don’t have these warnings. All looking correct inside NC.
I think he used this https://dietpi.com/forum/t/nextcloud-problems-questions/15415/82?u=jappe as template, where the HSTS line is commented out.
Because in your nextcloud-conf you have a locationsection which handles all the configs for your /nextcloud, while the default config handles everything else, whch should be nothing in your case?
Maybe you run certbot before you set up the subdomain and changed the webroot? So certbot added the line to the default config? Just a guess.
Doesn’t matter, on a default system it is working correctly. As the topic is 2 weeks old now, thinks might have mixed. He should simply remove the # manually inside dietpi-nextcloud.conf. Done.