guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Owen <adrian.o...@eesm.com>
Subject RE: wsock32 status / file transfers failing - RESOLVED
Date Wed, 31 Jan 2018 19:44:50 GMT
Hi Nick,

The issue was NGINX Reverse Proxy configuration. We copy and pasted the configuration from
the Proxying Guacamole NGINX Guide and now download works fine.

Moreover it also works from an IE 11 browser on a different computer.


The original computers IE 11 Guacamole session that failed all transfers (where this question
started), is still failing, but that’s now an IE issue not Guacamole.


Many thanks, Adrian

From: Nick Couchman [mailto:vnick@apache.org]
Sent: 31 January 2018 14:42
To: user@guacamole.apache.org
Subject: Re: wsock32 status / file transfers failing

On Wed, Jan 31, 2018 at 9:31 AM, Adrian Owen <adrian.owen@eesm.com<mailto:adrian.owen@eesm.com>>
wrote:
Hi,

OS – Debian Jessie x86
Building Guacamole 0.9.14

When  I ran ./configure during the build it reported wsock32 is missing:

Library status:

     freerdp ............. yes
     pango ............... yes
     libavcodec .......... yes
     libavutil ........... yes
     libssh2 ............. yes
     libssl .............. yes
     libswscale .......... yes
     libtelnet ........... yes
     libVNCServer ........ yes
     libvorbis ........... yes
     libpulse ............ yes
     libwebp ............. yes
     wsock32 ............. no

   Protocol support:

      RDP ....... yes
      SSH ....... yes
      Telnet .... yes
      VNC ....... yes

But Guacamole connections work.

Yes, this is expected on Linux.  wsock32 is the Windows socket support, which will only show
up if you're building on/for Windows.  This has nothing to do with whether or not Guacamole
connects to Windows systems, or if file transfers work or not.


However file transfers fail ?

Heres DEBUG syslog  of a HTTP session desktop file dropped onto the Download folder on G:
drive. Note the File open refused errors:

I only see you attempt two file transfers: fff.txt (which appears to succeed) and desktop.ini
(which appears to fail).  I think using desktop.ini is not the greatest test - this is a "special"
file in Windows, anyway, so Windows is likely placing some restrictions on the transfer of
that file.  Maybe create a few more plain text files, both on the Windows side and the client
side, and try transferring them back and forth and see what works and what doesn't.

-Nick
Mime
View raw message