that never existed. That was the public address to the old installation, which was in /var/www/owncloud
I will post the config later when I have access to my server
Did you a
sudo -u www-data php /var/www/nextcloud/occ maintenance:update:htaccess
after editing config.php?
yes, exactly as explained in the doc
I’m not shure if .htacess is working with nginx.
ok here’s the host-config for that domain. The listen at Port 82 is coming from the reverse-proxy that directs https-requests to this host.
upstream php-handler {
server unix:/run/php/php7.0-fpm.sock;
}
server {
listen 127.0.0.1:82;
server_name 127.0.0.1;
# Add headers to serve security related headers
# Use 'proxy_set_header' (not 'add_header') as the headers have to be passed through a proxy.
proxy_set_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
proxy_set_header X-Content-Type-Options nosniff;
proxy_set_header X-Frame-Options "SAMEORIGIN";
proxy_set_header X-XSS-Protection "1; mode=block";
proxy_set_header X-Robots-Tag none;
proxy_set_header X-Download-Options noopen;
proxy_set_header X-Permitted-Cross-Domain-Policies none;
# Path to the root of your installation
root /var/www;
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# The following 2 rules are only needed for the user_webfinger app.
# Uncomment it if you're planning to use this app.
#rewrite ^/.well-known/host-meta /owncloud/public.php?service=host-meta last;
#rewrite ^/.well-known/host-meta.json /owncloud/public.php?service=host-meta-json last;
location = /.well-known/carddav { return 301 $scheme://$host/remote.php/dav; }
location = /.well-known/caldav { return 301 $scheme://$host/remote.php/dav; }
location /.well-known/acme-challenge { }
location ^~ / {
# set max upload size
client_max_body_size 1G;
fastcgi_buffers 64 4K;
# Disable gzip to avoid the removal of the ETag header
gzip off;
# Uncomment if your server is build with the ngx_pagespeed module
# This module is currently not supported.
#pagespeed off;
error_page 403 /core/templates/403.php;
error_page 404 /core/templates/404.php;
location / {
rewrite ^ /index.php$uri;
}
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
deny all;
}
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
deny all;
}
location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+|core/templates/40[34])\.php(?:$|/) {
include fastcgi_params;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
# Important: disable HTTPS, otherwise no log in will be possible!
#fastcgi_param HTTPS on;
fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice
fastcgi_param front_controller_active true;
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
# Raise timeout values.
# This is especially important when the ownCloud setup runs into timeouts (504 gateway errors)
fastcgi_read_timeout 300;
fastcgi_send_timeout 300;
fastcgi_connect_timeout 300;
# Pass PHP variables directly to PHP.
# This is usually done in the php.ini. For more flexibility, these variables are configured in the nginx config.
# All the PHP parameters have to be set in one fastcgi_param. When using more 'fastcgi_param PHP_VALUE' directives, the last one will override all the others.
fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/var/owncloud_data:/dev/urandom
upload_max_filesize = 1G
post_max_size = 1G
max_execution_time = 3600";
# Make sure that the real IP of the remote host is passed to PHP.
fastcgi_param REMOTE_ADDR $http_x_real_ip;
}
location ~ ^/(?:updater|ocs-provider)(?:$|/) {
try_files $uri/ =404;
index index.php;
}
# Adding the cache control header for js and css files
# Make sure it is BELOW the PHP block
location ~* \.(?:css|js)$ {
try_files $uri /index.php$uri$is_args$args;
proxy_set_header Cache-Control "public, max-age=7200";
# Add headers to serve security related headers
# Again use 'proxy_set_header' (not 'add_header') as the headers have to be passed through a proxy.
proxy_set_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
proxy_set_header X-Content-Type-Options nosniff;
proxy_set_header X-Frame-Options "SAMEORIGIN";
proxy_set_header X-XSS-Protection "1; mode=block";
proxy_set_header X-Robots-Tag none;
proxy_set_header X-Download-Options noopen;
proxy_set_header X-Permitted-Cross-Domain-Policies none;
# Optional: Don't log access to assets
access_log off;
}
location ~* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ {
try_files $uri /index.php$uri$is_args$args;
# Optional: Don't log access to other assets
access_log off;
}
}
}Hi
in compared with this link:
https://docs.nextcloud.com/server/9/admin_manual/installation/nginx_nextcloud_9x.html#nextcloud-in-a-subdir-of-nginx
Not realy but maybe:
root /var/www/;
Just thinking:
Do it works without proxy?
because could it be, that you call the site twice?
/var/www/ → correct
and also the /kunterbuntcloud.de/owncloud/remote.php → from the proxy? or other way?
My Installation runs with Apache2, but i tryed out without ssl → the client always tries to connect over https:// → you can force (http://) with trying again → Maybe some configuration from your proxy (https://) to your site (http://) could have a wrong way.
Or, if you redirected from http to https
Found something - Nice Subnet 
→ link to https mean Port:443
Same with Nextcloud:
If you have a GUI on your server, pls try the Nextcloud app with your Address 127.0.0.1:82
Hope that can help
That does not exist since the NC is in the main www directory, not in a subdirectory /owncloud. If that’s the URL the client tries to reach my NC that can’t work. In no config file - whether it’s nginx nor NC - I can find that path. So from where does it take that?
Disabling the proxy is a bit more work, I will try that later
Hi
I found something, maybe that can help: Howto change the folder "owncloud" to "nextcloud" after upgrading?
That’s about database table-names, not directory names in the servers file system. Since the Web-Apps inside my NC-account work (and have all my old content in there), I don’t expect a problem in there.
just wanted to inform that the new Mac client (2.3.0.4 RC1) has this issue fixed
Same here, desktop client 2.2 doesn’t work on OSX, but 2.3 rc1 does.
Any clue why? Maybe 2.2 could be patched with a fix since it’s pretty important that OSX users can’t connect to (some) Nextcloud servers.
can somebody provide a Link to 2.3.04 or newer?
the official site still provides 2.2.4.1
https://nextcloud.com/install/#install-clients
as you can see here:
thanks…
I also in a same situation, when I connect MacOSX Sierra to nextcloud (ubuntu 16.04, self certified server), failed to connect with SSL by using 2.3.2beta (build 1).
Hi
The client requires pkcs12 certification and key, I generated pkcs12 key file on the server and copied to Mac client, but client says “cannot connect to https://MYSERVER/status.php”.
(MYSERVER is example)
Web access, Windows client, iOS app could connect MYSERVER properly, so server side seems to be fine.
Experimentally , I use ‘owncloud’ client instead and it works fine.
Does anybody know to generate pkcs12 certification file ?
I generated certificate file in ubuntu server as below.
$ openssl pkcs12 -export -inkey MYSERVER.key -in MYSERVER.crt -out MYSERVER.p12 -name "MYSERVER"
Thanks,
I’m using Letsencrypt without any problems
I changed self certificates to LetsEncrypt certificates and finally succeeded to connect my Nextcloud from Mac.
Thanks a lot!
yep, self signed certificates are a mess nowadays
I’ve got the same issue with OSX 10.12.6, Nexcloud client V2.3.2 (build 1), and Nextcloud 12 server installed.
The connection is over a forced https.
The server is working with webinterface (safari +chrome) and with the nextcloud client for windows7 V2.3.2 build1.
any idea what could be wrong ?
Thanks a lot !!!
and it also works from IOS!
I’ve seen a lot of thread since the original topic, so I want to make the issue I have clear
upon connection attempt of the client, I get
Failed to connect to the secure server address [https://xxx.xxx.xxx.xxx], how do you wish to proceed?
For me this has something to do with the chipers used on your server. The NC client seems to require older ones, which I deactivate on my servers. My tip: Use the Owncloud client, which seems to be less testing and therefore works better. An example of aggravation improvement? Configuring a server worse and less secure is out of the question.
Here are my posts: Secure Connection failed
and in March I’ve written an blog about WebDAV support on Windows. Same sad story there: https://www.facebook.com/notes/jakobssystems/windows-fit-fürs-internet/1431970356867839
point taken !
NextCloud, what do you think ?