aos mapping network drives on windows

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
stevem
Member II

aos mapping network drives on windows

Hi All

I've deployed alfresco community 6.0.7.ga as a docker container with nginx as a reverse proxy and configured for SSL

I am able to access both the webdav UI and the aos UI from a browser, for instance the URL's would be the following format:

https://<alfresco server dns>/alfresco/webdav

https://<alfresco server dns>/alfresco/aos

But I am unable to map a windows network drive to either the webdav or aos server URL's, trying to do so always results in an error.

If I try to enter the URL into the Folder area I get :

Network Error

Windows cannot access https://<alfresco server dns>/alfresco/aos

And If I select 

Connect to a website that you can use to store documents and photos

I always end up with the error 

Add Network Location

The folder you entered does not appear to be valid. Please choose another.

Are there any special ports I need to expose and or configure in alfresco-global.properties ?

Are there any special URL patterns I need to proxy in my nginx configuration to make this work ?

Any help here would be most appreciated.

Regards

Steve

6 Replies
fedorow
Established Member II

Re: aos mapping network drives on windows

I think it's some Windows problems.

Troubleshooting WebDAV | Alfresco Documentation 

heiko_robert
Established Member II

Re: aos mapping network drives on windows

there are lot's of possible causes. you may start with:

  • aos seems not to respect the x-forwarded-by header but webdav relies on the url send in the body which may be the containers host name. When using a reverse proxy like nginx you need to set aos.baseUrlOverwrite in your alfresco-global. e.g.
    aos.baseUrlOverwrite=https://alfresco.mycompany.com/alfresco/aos

  • Are you sure your nginx is compiled with webdav support?

  • Windows only connects to trusted and validated urls, so you need to use certs in your nginx which are trusted by your windows box

  • Is your WebClient service running on your Windows box?
  • finally I use syntax \\hostname@SSL\alfresco\aos on win7-win10 to connect instead of https:/...
stevem
Member II

Re: aos mapping network drives on windows

Hi Heiko

Thanks for responding.

Firstly, the aos.baseUrlOverwrite option is set correctly to https://<alfresco server dns>/alfresco/aos in the alfresco-global.properties file

With respect to your other questions...

1. The version of nginx we are running is "openresty/1.13.6.2" and it is compiled with the "--with-http_dav_module" flag and is verified by running nginx -V

2. Commercial certs for our domains are installed and configured within the nginx config on each of our domains "prod", "uat" and "dev"and all are trusted by all Windows machines on our network.

All http traffic is automatically redirected to https at the nginx reverse proxy and is then proxied on to the correct service endpoints i.e. http://alfresco:8080

3. All components of the Alfresco installation, alfresco, share, solr6, nginx etc are all running inside independent docker containers started with a docker-compose.yml file running on ubuntu 16.04 VM's. So the alfresco web client is not running on a windows box and alfresco itself has been deployed along with the aos amp file.

All SSO auth is done via Kerberos and users are automatically logged into their Share UI when selecting an "Internet Explorer shortcut" from their desktop once logged in.

4. I have tried setting up a mapped drive with both the https:// and a UNC options, like you stated. All options return the same Windows errors I stated in my original post.

For the UNC options I have tried

\\<alfresco server dns>@SSL\alfresco\aos - The DNS of the server running the Alfresco docker images ad defined in the SSL certs

\\<hostname>@SSL\alfresco\aos - The hostname of the Ubunto 16.04 VM running the Alfresco docker image

\\<IP>@SSL\alfresco\aos - The IP address of the Ubunto 16,04 VM running the Alfresco docker images

Regards

Steve

heiko_robert
Established Member II

Re: aos mapping network drives on windows

1. Set in tomcat's server.xml your proxyPort="443" and either RemoteIpValve (remapping the requests host name using e.g. x-forwarded-for, x-forwarded-proto set in your nginx location definition) or proxyName (Apache Tomcat 8 (8.0.53) - Proxy Support HOW-TO ) in the Connector definition nginx is connecting to.

3. was related to your windows client. Windows still uses IE redirector running as windows service "Web Client" to connect to a WebDAV/SP server. So please check if the service is running.

To make debugging easier you may allow windows to connect to non ssl servers, disable the redirect in nginx and try to connect from windows explorer without @SSL

stevem
Member II

Re: aos mapping network drives on windows

Thanks again Heiko

1. The Tomcat server.xml has already been set and configured with the proxyPort and the nginx config already sets the x-forwarded-for and x-forwarded-proto headers for requests.

Secondly, I realized after I sent the last reply that the WebClient Service you mentioned refers to a Windows specific service for WebDAV.

This is currently being setup by the network team as the users Windows machines are actually served over Citrix and these are currently locked down without that service running meaning that drives cannot currently be mapped to WebDAV sources.

Once the network team has made the required changes I'll test this out and let you know the outcome.

Thanks for your input on this it was most helpful in first confirming I had set the Alfresco server side components up correctly and secondly pointing out that the WebClient service needs to be running on the Windows machines.

I had somehow interpreted WebClient to mean the Alfresco/Share UI that users mostly interact with. I'm not a Windows person Smiley Happy

Regards

Steve

stevem
Member II

Re: aos mapping network drives on windows

Hi Heiko

As promised.

After getting the Citrix clients to enable the WebClient service by default the drive mapping to AOS worked fine.

Thanks again for your input here it was most helpful.

Regards

Steve