I have a server running NextCloud as a VirtulHost on apache2/Ubuntu server.
Recently I wanted to add a second virtual host on the same server to host a different service alongside NextCloud. I have now spend almost a month trying to make this work but no matter how I configure my virtual hosts and domains, as soon as I try to access another VirtualHost, NextCloud gives me a Access through untrusted domain page.
So basically, no matter what I do, nextcloud is always the one getting the URL request regardless of the domain name I use. If I use my actual NextCloud domain, I access my NextCloud server perfectly, but if I use any other VirtualHost domain, NextCloud still takes over instead of letting Apache2 serve the correct VirtualHost.
LetsEncrypt can see all the VirtualHosts I have setup under Apache.
Is there a setting in NextCloud that I’m missing?
I have spent over a month now searching on here, on google, on youtube. I have reconfigured the apache server countless times, and I just can’t get nextcloud to not take over the web server request.
If you don’t have the * in <VirtualHost *:80> or <VirtualHost *:443>, then it might be just for a specific IP, and it might not work or work differently when you access through a public IP or private IP in you local network, just in case it is in you local network.
What might go wrong as well, if you have defined the same ServerName in different virtual hosts. I don’t know if it then takes the first or last appearance.
Like this, it is hard to be more specific without you sharing more details about the configuration.
Did you configure a (different) ServerNameandDocumentRoot directive in that VirtualHost?
Did you add it to the same config file as the Nextcloud VirtualHost, or did you create a new file under /etc/apache2/sites-available/?
If you created a new file, did you enable it using:
a2ensite site.conf
Did you restart Apache after adding/enabling the new VirtualHost
systemctl restart apache2
If that doesn’t help, please describe your setup in more detail and post your configuration files, otherwise this will continue to be a guessing game.
No, I don’t think so. Apache decides which VirtualHost to serve based on the ServerName, and which directory to serve based on the DocumentRoot directive, not Nextcloud.
Thank you for your replies. Below are my VirualHost configs. Each virtual host is a separate conf file and all have been enabled with a2ensite and apache restarted.
I have used XXXXX to censor sensitive information but in my conf files, these are qualified domains.
Just confirming cloud.XXXX is my Nextcloud and works perfectly. crm.XXXX is the second virtual host and all calls to that are answered by Nextcloud
<VirtualHost *:80>
DocumentRoot "/data/www/cloud.XXXXXX"
ServerAlias cloud.XXXXXX
<Directory "/data/www/cloud.XXXXXX/">
Options MultiViews FollowSymlinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
TransferLog /var/log/apache2/cloud.XXXXXX_access.log
ErrorLog /var/log/apache2/cloud.XXXXXX_error.log
RewriteEngine on
RewriteCond %{SERVER_NAME} =cloud.XXXXXX
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
------------------------------------
<IfModule mod_ssl.c>
<VirtualHost *:443>
DocumentRoot "/data/www/cloud.XXXXXX"
ServerName cloud.XXXXXX
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
</IfModule>
<Directory "/data/www/cloud.XXXXXX/">
Options MultiViews FollowSymlinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
TransferLog /var/log/apache2/cloud.XXXXXX_access.log
ErrorLog /var/log/apache2/cloud.XXXXXX_error.log
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/cloud.XXXXXX/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/cloud.XXXXXX/privkey.pem
</VirtualHost>
</IfModule>
-----------------------
<VirtualHost *:80>
DocumentRoot /data/www/crm.XXXXXX
ServerAlias crm.XXXXXX
<Directory /data/www/crm.XXXXXX>
Options FollowSymLinks
AllowOverride All
</Directory>
ErrorLog /var/log/apache2/XXXXXX-error.log
CustomLog /var/log/apache2/XXXXXX-access.log common
RewriteEngine on
RewriteCond %{SERVER_NAME} =crm.XXXXXX
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
------------------
<VirtualHost *:443>
DocumentRoot "/data/www/crm.XXXXXX"
ServerName crm.XXXXXX
<Directory "/data/www/crm.XXXXXX/">
Options MultiViews FollowSymlinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
TransferLog /var/log/apache2/crm.XXXXXX_access.log
ErrorLog /var/log/apache2/crm.XXXXXX_error.log
SSLCertificateFile /etc/letsencrypt/live/crm.XXXXXX/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/crm.XXXXXX/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
Just to be clear, the calls aren’t answered by Nextcloud per se; they’re answered by whatever Apache decides is your default VirtualHost entry if there’s no match. That is generally the first VirtualHost listed after parsing your full configuration (aside: you can create a _default_ VirtualHost entry in Apache to control this a bit better, but that’s a matter you can refer to Apache’s docs for).
The first thing that stands out to me is that both your *:80 entries lack a ServerName. That means Apache uses fallback behavior to try to guess the intended ServerName values for those VirtualHost entries. The way that works in Apache, both those entries will likely end up with the same ServerName (typically something derived from your system hostname or reverse DNS on one of your system interfaces; unlikely to be what you want).
Even though @jtr is right that Apache defaults to the server name in the first config file, and if you don’t provide one, it may even default to the server’s hostname, I don’t think using ServerAlias in your HTTP vhosts is the actual issue here. However I’d still recommend to change those to ServerName.
I ran a few tests and couldn’t reproduce the issue, even when I changed the ServerName directives to ServerAlias in my HTTP vhosts. Also, my rewrite rules to HTTPS are exactly the same as yours, and I’m not experiencing this issue.
So I’d say there must be something else in your Apache configuration that deviates from the default on Ubuntu/Debian, perhaps in apache2.conf or ports.conf…?
Maybe you could post these files here as well, and maybe also the output of apachectl -S.
A more radical option would be to apt purge apache2, then remove /etc/apache2 in case it’s still there, reinstall Apache, and create only those four VirtualHost configurations, enable them and restart the service. This would rule out the possibility that some other config file is deviating from the defaults.
I changed the hostname, restarted the server and everything is now working as intended. I didn’t make any changes to the .conf files however I will change ServerAlias to ServerName per your recommendation.
Thank you again for all your help on this one. Really appreciate everyone’s time.
I still find it a bit strange that this happened, because I tried to reproduce it, and couldn’t. In my /etc/hostname I only have cloud, not cloud.mydomain.tld. However, I do have both cloud and cloud.domain.tld in my /etc/hosts file, maybe that makes a difference.
To be honest, I never fully understood how Apache interacts with the system regarding hostnames. For example, (not sure if that’s releated, though) every few hours I get messages in Nextcloud about Collabora (hosting/capabilitiesresulted in a502 Proxy Error` response) and, more recently:
Could not check for WASM loading support. Please check manually if your web server serves .wasm files. To allow this check to run you have to make sure that your web server can connect to itself. Therefore it must be able to resolve and connect to at least one of its trusted_domains or the overwrite.cli.url.
But I’ve learned to ignore the first one, since everything works fine and the errors only appear sporadically every few hours. And the second one also seems to work, Nextcloud just claims it can’t verify it.
Maybe this behavior is related to systemd-resolved in newer distro versions, or to how the checks themselves are implemented. I think I’ve seen the WASM warning come and go before, and now in 32.0.2 it’s back again.
curl resolves everything (Collabora and Nextcloud) correctly when I run it on the host, and everything works, so no idea what’s going on.
