Service Discovery Setup

[alexknop]

Same thing as nextcloud/server#42018 but truly the problem is in the instructions.

I have followed the steps at https://docs.nextcloud.com/server/27/go.php?to=admin-setup-well-known-URL.
My server URL is https://192.168.1.2/nextcloud and my DocumentRoot is /var/www/html/

Redirects don't work. If I go to https://192.168.1.2/.well-known/caldav it doesn't redirect and shows a page with "Not Found
The requested URL was not found on this server."

In my Setup Warnings, I have the 4:
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]
Your web server is not properly set up to resolve "/.well-known/caldav". Further information can be found in the [documentation]
Your web server is not properly set up to resolve "/.well-known/carddav". Further information can be found in the [documentation]

I created the following file to try to enable redirects:

$ cat /var/www/html/.htaccess 
<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteRule ^\.well-known/carddav /nextcloud/remote.php/dav [R=301,L]
  RewriteRule ^\.well-known/caldav /nextcloud/remote.php/dav [R=301,L]
  RewriteRule ^\.well-known/webfinger /nextcloud/index.php/.well-known/webfinger [R=301,L]
  RewriteRule ^\.well-known/nodeinfo /nextcloud/index.php/.well-known/nodeinfo [R=301,L]
</IfModule>

Steps to reproduce

1.Setup local instance of Nextcloud Server in a sub-folder (var/www/nextcloud)
2.Setup redirects at https://docs.nextcloud.com/server/27/go.php?to=admin-setup-well-known-URL
3.Attempt to visit redirects

Expected behavior

Expect to see a redirect based on the URL https://192.168.1.2/.well-known/caldav to go to https://192.168.1.2/nextcloud/remote.php/dav

Possible Root Cause

A problem with this setup is the .htaccess file being in your DocumentRoot needs to be granted various permissions from the AllowOverride Directive (https://httpd.apache.org/docs/current/howto/htaccess.html). This directive can only be applied to Directory configurations (https://httpd.apache.org/docs/current/mod/core.html#allowoverride), but by default Apache has configured a DocumentRoot of /var/www/html and a configuration for /var/www/html that is a VirtualHost, not Directory.

cat /etc/apache2/sites-available/000-default.conf | grep -ve "^\s#"
<VirtualHost *:80>
	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

So trying to use an .htaccess file with this default doesn't work.
Is there an alternative then to .htaccess?

[joshtrichards]

Is there an alternative then to .htaccess?

As stated on the referenced documentation page under the .htaccess approach:

If you put the above directives directly into an Apache configuration file (usually within /etc/apache2/) instead of .htaccess, you need to prepend the first argument of each RewriteRule option with a forward slash /, for example ^/.well-known/carddav. This is because Apache normalizes paths for the use in .htaccess files by dropping any number of leading slashes, but it does not do so for the use in its main configuration files.

Though to your root cause:

A problem with this setup is the .htaccess file being in your DocumentRoot needs to be granted various permissions from the AllowOverride Directive (https://httpd.apache.org/docs/current/howto/htaccess.html). This directive can only be applied to Directory configurations (https://httpd.apache.org/docs/current/mod/core.html#allowoverride), but by default Apache has configured a DocumentRoot of /var/www/html and a configuration for /var/www/html that is a VirtualHost, not Directory.

Directory parameters can be used inside of VirtualHost sections. They can also be used at the global (server config) level.

All of the above assumes you're not using a Reverse Proxy. The config snippet you provided is non-HTTPS so I only mention that because if you're using an RP, the Service Discovery redirects generally goes on the RP.

Hopefully you find the above helpful. If you have specific suggested modifications to the documentation, feel free to submit them as a suggested modification by clicking the "Edit on GitHub" link at the upper right of any documentation page.

Otherwise I'd encourage any follow-ups over at the Nextcloud Help Forum - https://help.nextcloud.com

[kesselb]

Creating an issue in a different repository when you were asked to go to https://help.nextcloud.com/ is not cool.

[alexknop]

@kesselb why would I go to a forum when I can engage with the people responsible for publishing the instructions for this product. I am not trying to be "cool" and I did not create this here to spite you, I am trying to make sure the Nextcloud instructions can be made clear for all users so they can be of use. As of now there are missing instructions.
I thought this was an open source community. Have some decency, it was wrong of you to get in between what Josh and I were getting at.

[kesselb]

I'm not stopping you and Josh from debugging here.
Looking forward to your pull request to improve our service discovery section for subdirectory installations.

[joshtrichards]

Good morning @alexknop. I took @kesselb's suggestion more as: "Debug this in the Help Forum first."

Usually when one of us nudges a reporter towards the Help Forum it's because we can tell that the crux of the issue is almost certainly a misunderstanding or misconfiguration that needs to be troubleshooted further (which isn't what these repos are for).

After troubleshooting within the forum, if you turn up something that should be clarified in the docs then by all means: submit that as an enhancement idea, bug report, or as an outright change proposal via a pull request.

Obviously others are using Nextcloud without this problem, so it's probable that others have found solutions. Chances are interacting on the Help Forum will not only find a solution, but the process will generate a better idea of what improvements might need to be made in the documentation or in the software.

We're all super busy (volunteers and non-volunteers) - as you may be as well - so sometimes we don't have time/energy to provide a lengthy explanation or to troubleshoot something one-on-one (when we do, we can often be found in the Help Forum ready and waiting).

Everyone involved in this project is merely trying to bring a little order to the chaos, to make things a bit better every time we jump in, and to keep things flowing. Sounds like you are as well so thank you for that. :-)

I am trying to make sure the Nextcloud instructions can be made clear for all users so they can be of use. As of now there are missing instructions.

I appreciate that - and I'm fairly certain @kesselb does too. Once you have a working setup - or have tried hard to get one via the Help Forum - I encourage you to submit your improvements / improvement ideas. When you do so, you can (and should) link to the Forum discussion since it'll provide great context to inform any improvements.

There is lots of room for improvement in the documentation. I look forward to seeing you get involved.