-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
9.1.1 - Windows webclient (WebDAV) service not starting when connecting over HTTPS #26350
Comments
No idea, is this an ownCloud bug ? Is OC returning something that the WebClient service doesn't like when starting automatically ? |
did it work with previous OC versions ? (just to be sure it's not a regression) |
Yes it did work with previous versions (both HTTP and HTTPS). |
There was a PR for the nginx documentation recently also reporting this " (0x80070043 The Network Name Cannot Be Found)": owncloud-archive/documentation#2668 The PR also contains additional info |
This seems to fix the issue. Added this to the site configuration.
|
I'm using ownCloud scince version 8.0.2 (March 2015) in HTTPS-only mode and all this time I had this problem. |
Hmm same here too using oC 8.2! |
Made a clean install of oC 9.0.5 and it works without the fix
Goin to test this with 9.0 and 8.2 |
Ahhh, that might be a good starting point. In newer oC Versions the "index.php-less" URLs are not enabled by default. Could be the difference here. |
I just tested a modified .htaccess and it works with Windows 7.
|
What kind of certificate are you using? |
Wildcard from https://www.ssls.com/ |
same behaviour here, but i found a temp solution in windows7: try to connect your webdav url by IP address instead of the servername. this fails too (with another error) but before it asks your credentials. after this the webdav can be mounted with the name and it works until the next reboot. maybe helpful for somebody. UPDATE - the IP based mount just starts the "WebClient" in windows. UPDATE2 [solved]: we have a reverse proxy in front of the owncloud apache. this proxy server answers on the first windows-explorer-webdav request ( / OPTIONS) with a 302 redirect instead of the expected 200. now i rewrite on the reverse proxy this and the problem dissappears. if answer is a 200, then Webclient on windows will start.
|
My clients are running windows 10. I started experiencing this behavior when I upgraded to ownCloud 9.1.1. From the advice above, I checked my WebClient service settings. I changed my startup type from "Manual" to "Automatic" and I can now connect after a fresh reboot without the "The Network Name Cannot Be Found" failure. I tried the rewrite rule's detailed in the previous posts, but I removed them after I changed my WebClient service startup setting. |
I had the same problem since updating to 9.1 (and 9.1.1 and 9.1.2) after my "RewriteEngine On" entrys worked perfectly well. can somebody pull that fix to upstream? |
@techatdd I don't think there is a need to push this to everyone out there by default. This would risk breaking other stuff and clients for people don't need that workaround for buggy 3rdparty clients. The known workaround was already found by you in owncloud-archive/documentation#2717 so that documentation there should be more then enough. Ref. to the documentation containing the fix: https://doc.owncloud.org/server/9.2/user_manual/files/access_webdav.html#known-problems |
the fix in the documentation needs a administratior configuration change for every client using windows buid-in webdav (tested in win7/8/10). this is not a fix, because most of ouer oc users have systems not mainteined be me. the simple fix in .htaccess from AndrinS changed thinks back to work for all users at a time. Since AndrinS tested it with a fresh image, i think most (or all) oc users have this regression. sure it have to be testetd that it dont break other thinks, but a manual client configuration change is not solution... |
@techatdd So if you need that change then just deploy it to your .htaccess file (might be redone during an update) or to your global webserver config (will survive updates).
Pushing a fragile workaround like this to all users is also no solution... It also won't work if it is added to oCs .htaccess and oC is installed in a subdir. The best thing what should be done here is to also document the .htaccess / webserver config to the documentation / documentation wiki. |
I already did and you are right, i dont overview what it could break. At leat the documentation should mention this fix. because the solution with change the service start type in windows is at least a workaround for small installations. |
@techatdd I'm happy this workarround works for you. @RealRancor keep in mind that you need administrative rights to modify the Windows services. This could be difficult in some cases. And also as mentioned: It worked in 9.0.x without any workarrounds! |
why not mach simpler? RewriteEngine On |
If this is possible to fix via rewrite rules maybe some one can just create a pull request to the .htaccess of ownCloud to workaround this from ownCloud side? |
Already did: owncloud-archive/documentation#2668 |
@adduxa But if it can be included directly into https://github.com/owncloud/core/blob/v9.1.4/.htaccess#L51-L62 its IMHO the better way as far less people will read the documentation. |
@kdslkdsaldsal I agree, but PR was closed |
@adduxa Yes, but from what i can see owncloud-archive/documentation#2668 was about nginx and you closed it on your own. A .htaccess file is also not used at all by nginx, this is something apache specific. |
3 lines are enough too RewriteEngine On But user have to type password two times. It would be good to find right response code, which would kick off Windows "DavClnt" P.S. It must work with subdir installations too |
@kdslkdsaldsal Hmm, oh that's right... Because it turned out that this is more Windows bug, then ownCloud. |
One more interesting thing. After reboot wenn Windows beginns negotioaion with Apache's own WebDav Server (permanently mounted network drive), it begins with "right" "Microsoft-WebDav-MiniRedir" Client. How Windows know that Apache WebDav Server will not accept "DavClnt"? |
See original issue comment: owncloud/core#26350 (comment) Just a "typo" but needs to be fixed.
See original issue comment: owncloud/core#26350 (comment) Just a "typo" but needs to be fixed.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Steps to reproduce
Optional:
Use the official ownCloud virtual machine image (e.g http://download.owncloud.org/community/production/vm/Ubuntu_14.04-owncloud-9.1.1-1.1-201609201317.qcow2.zip)
Expected behaviour
The WebClient service should start as usual (9.0.5 and below) and it should promt for the credentials.
Actual behaviour
The WebClient service won't start and the connection fails. (0x80070043 The Network Name Cannot Be Found)
Server configuration
Operating system: Ubuntu 14.04.5 LTS 64bit
Web server: Apache/2.4.7
Database: MySQL Ver 14.14 Distrib 5.5.52
PHP version: PHP 5.5.9-1ubuntu4.20
ownCloud version: 9.1.1.3
Updated from an older ownCloud or fresh install: fresh install
Where did you install ownCloud from: http://download.owncloud.org/community/production/vm/Ubuntu_14.04-owncloud-9.1.1-1.1-201609201317.qcow2.zip
Signing status (ownCloud 9.0 and above): ?
List of activated apps:
The content of config/config.php:
The content of config/config.php: Its basically the by default generated config from the installer
Are you using external storage: no
Are you using encryption: no
Are you using an external user-backend, if yes which one: no
Client configuration
Browser: Used default Windows (File) Explorer (not IE) to add a new network share
Operating system:
Windows 7 64 bit SP1
Logs
Web server error log
ownCloud log (data/owncloud.log)
Browser log
Workarround
When the WebClient Service is started manually everything works fine. Other WebDAV clients also seem to work fine as well.
Connecting without HTTPS also works and starts the WebClient service automatically.
The text was updated successfully, but these errors were encountered: