Hoping for some help here. As noted in the subject, I am running on an Ubuntu 22.04 machine (an LXD Container) and have gotten Nextcloud running (several times now:) ) just fine.
At first I tried the built in Office CODE module and failed so I went to the separate package installer of Collabora CODE.
When I configure my Nextcloud App and try to access the collabora admin console they both work without error.
But creating documents fails with the dreaded āDocument loading failed - Failed to load Nextcloud Office - please try again laterā error.
I think the problem is the way I have my Nextcloud and Collabora apache2 virtual hosts defined on my ubuntu container AND SEPARATELY my nginx revers proxy.
On my Nextcloud/Collabora Server I have a virtual host block for my nextcloud installation. The expectation is the reverse proxy will be doing the ssl so I am listening on 80
<VirtualHost *:80>
ServerName nextcloud.my_domain.orgServerAdmin info@my_domain.org DocumentRoot /var/www/nextcloud Protocols h2 h2c http/1.1 <IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains" </IfModule> <Directory /var/www/nextcloud/> Require all granted AllowOverride All Options FollowSymLinks MultiViews <IfModule mod_dav.c> Dav off </IfModule> </Directory> <FilesMatch ".php$"> SetHandler "proxy:unix:/var/run/php/php8.1-fpm.sock|fcgi://localhost/" </FilesMatch> ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combinedvim: syntax=apache ts=4 sw=4 sts=4 sr noet
And on my nginx reverse proxy with Letās Encrypt certs I have the main Nextcloud server block
server {
server_name nextcloud.my_domain.org;
listen [::]:443 ssl http2; # managed by Certbot
listen 443 ssl http2; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/nextcloud.my_domain.org/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/nextcloud.my_domain.org/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbotclient_max_body_size 0; underscores_in_headers on; # max-age=15552000 # max-age=31536000 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; root /var/www/html; index index.html index.htm index.nginx-debian.html; location /.well-known/carddav { return 301 $scheme://$host/remote.php/dav; } location /.well-known/caldav { return 301 $scheme://$host/remote.php/dav; } location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; add_header Front-End-Https on; proxy_headers_hash_max_size 512; proxy_headers_hash_bucket_size 64; proxy_buffering off; proxy_redirect off; proxy_max_temp_file_size 0; add_header 'Content-Security-Policy' 'upgrade-insecure-requests'; proxy_pass http://10.187.15.197:80; }}
So my Nginx Reverse Proxy is running in the LXD protected subnet and gets its http and https connections requests at the main server and passes them into the LXD cloud to the reverse proxy.
HOLD ON A MINUTEā¦ maybe I never passed the 8890 port through into the LXD cloudā¦ let me check on thatā¦
