The current document does not mention that "/nextcloud" path is only optional, and not needed if the installation is present at the root directory of the domain. Also, the wording was quite off, cleaned it up a bit.
Signed-off-by: Vignesh Kumar <xxvignesh@gmail.com>
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.)
The Knowledge Base KB841215 article is not available anymore. Yet the issue itself is not so difficult, so we can just exchange the outdated link with a brief description of the solution directly.
