There’s more explanation here than there are changes to the docs! But, in the interest of fully explaining *why*:
I had a frustrating and time-consuming experience attempting to *unsuccessfully* get macOS 10.11.x-10.13.x to mount WebDAV shares. The opening “Note” of “Accessing files using macOS” re Finder’s “series of implementation problems” is valuable. While my rewrite does *not* employ stronger language to *dissuade* Mac users from wrestling Finder, I’m convinced it should. I understand that docs maintainers probably want to avoid negative commentary re product manufacturers for many reasons, but the alternative to tight-lipped disclosure is user disillusionment. The opening warning would serve Apple folk better if it more-plainly warned of the high likelihood of Finder failure and more-thoroughly offered, even recommended, alternative apps to successfully achieve WebDAV access. Though Cyberduck instructions follow *later* in the article, it benefits the Mac user *here* (and other users in their respective sections) as they will likely seek out and focus specifically, perhaps *only*, on these instructions which are so clearly titled for and targeted at them: “Accessing files using **macOS**.” Unfortunately — even though these steps *should* work — they probably will *not*. Readers, exacerbated, may only find the Cyberduck info later, after returning to the instructions for further illumination, feeling slighted it wasn’t there to begin with. Recommending the open source Cyberduck as a candidate to replace Finder’s failures is helpful. Understandably, there may be resistance to mentioning commercial apps at the risk of perceived endorsement, but I have. I also added another open source app. Arming readers with more knowledge, more details, and more tools *up front* secures a higher rate of informed execution and success.
Nuts and bolts: I offer minor reordering of graphics and text to hopefully present a clearer flow of the existing steps. That includes changing example.com/nextcloud to cloud.nextcloud.com as most people who have registered domains can easily add subdomains. Subdomains can also efficiently by reverse proxied to internal servers *without* opening external ports visible to hackers. Call it subliminal security reinforcement.
I optimized the original “osx_webdav1.png,” compressing it from 381K to 94K, with negligible visual loss. And I created a new screenshot to replace the existing osx_webdav2.png “Connect to Server” image which graphically matches the sample text URL. (The existing sample URL and its screenshot don’t match.) Finally, the original osx_webdav2.png dialog box had been reduced in size, introducing minor but visible blur. The new optimized version is actual-size-crisp and only 16K, vs the original’s 66K. (I don’t see where to attach these new graphics. I’m new to pull requests, and hope in subsequent steps I can.)
After following two different tutorials on Internet, I have encountered login loop after fresh install. It had taken me some time to fix this problem, so I am proposing this troubleshooting part here.
signed-off-by Bernhard Ostertag <bernio.github@gmx.de>
After upgrading to 15.0.5 this is shown in the Admin-panel:
```
Your web server is not properly set up to resolve “/ocm-provider/”. This is most likely related to a web server configuration that was not updated to deliver this folder directly. Please compare your configuration against the shipped rewrite rules in “.htaccess” for Apache or the provided one in the documentation for Nginx at it’s documentation page 1. On Nginx those are typically the lines starting with “location ~” that need an update.
Your web server is not properly set up to resolve “/ocs-provider/”. This is most likely related to a web server configuration that was not updated to deliver this folder directly. Please compare your configuration against the shipped rewrite rules in “.htaccess” for Apache or the provided one in the documentation for Nginx at it’s documentation page 1. On Nginx those are typically the lines starting with “location ~” that need an update.
```
I think for runnning nextcloud in a subdirectory of webroot, this rewrite has to be added to the nignx configuration when running nextcloud in a subdirectory of webroot
signed-off-by Bernhard Ostertag <bernieo.github@gmx.de>
After upgrading to 15.0.5 this is shown in the Admin-panel:
```
Your web server is not properly set up to resolve “/ocm-provider/”. This is most likely related to a web server configuration that was not updated to deliver this folder directly. Please compare your configuration against the shipped rewrite rules in “.htaccess” for Apache or the provided one in the documentation for Nginx at it’s documentation page 1. On Nginx those are typically the lines starting with “location ~” that need an update.
Your web server is not properly set up to resolve “/ocs-provider/”. This is most likely related to a web server configuration that was not updated to deliver this folder directly. Please compare your configuration against the shipped rewrite rules in “.htaccess” for Apache or the provided one in the documentation for Nginx at it’s documentation page 1. On Nginx those are typically the lines starting with “location ~” that need an update.
```
I think for runnning nextcloud in a subdirectory of webroot, this rewrite has to be added to the nignx configuration when running nextcloud in a subdirectory of webroot
After upgrading to 15.0.5 this is shown in the Admin-panel:
```
Your web server is not properly set up to resolve “/ocm-provider/”. This is most likely related to a web server configuration that was not updated to deliver this folder directly. Please compare your configuration against the shipped rewrite rules in “.htaccess” for Apache or the provided one in the documentation for Nginx at it’s documentation page 1. On Nginx those are typically the lines starting with “location ~” that need an update.
```
I think for runnning nextcloud in a subdirectory of webroot, this redirect has to be added to the configuration
signed-off by bernieo.github@gmx.de
