I set up OpenSSH for Windows by advice of Erik Berndt and connected succesfully, but I am not able to upload files, only download.
Here is the error I get
And here is what I see in log
Nobody ever faced such error?
Is the SFTP server set to allow passive or active transfers?
Are you able to upload files or view directories with an ftp client? If not, It may be a firewall issue on the RDP host.
On Friday, June 16, 2017, Suncatcher16 <[hidden email]> wrote:
> Nobody ever faced such error?
> View this message in context: http://apache-guacamole-incubating-users.2363388.n4.nabble.com/SFTP-error-unable-to-open-file-XXX-on-Win8-RDP-host-tp1155p1169.html
> Sent from the Apache Guacamole (incubating) - Users mailing list archive at Nabble.com.
Erik Berndt / Systems Administrator
5551 Wellington Rd, Gainesville, VA 20155
703.631.0004 x520 (Phone) / 703.257.1725 (Fax)
Need to open an IT support ticket?
http://FixIT.superiorpaving.net/portal or [hidden email]
How to check that?
I tried WinSCP client and it both downloads and uploads files like a charm. I investigated Passive/Active setting and wasn't able to change it, as it stated here, Passive mode is relevant only for FTP, whilst SFTP connection is always active.
And if it is firewall issue, then WinSCP client will be blocked too. Any other suggeestions?
The same error is throwing on Win7 RDP host. It looks like some (mis)configuration of the server, when it tries to open with wrong slash (like in Linux) or so-so.
Nobody have meet this?
Could anybody help? The problem is still unsolved. It affects both on Win8 and Win7.
Upload/download via linux scp goes fine, WInSCP also goes OK. The reason is in Guacamole.
Maybe it is related to https://issues.apache.org/jira/plugins/servlet/mobile#issue/GUACAMOLE-222. The file was remaining locked after download and no operation on this file were possible any more.
On Wed, 12 Jul 2017, 18:50 Suncatcher16, <[hidden email]> wrote:
Could anybody help? The problem is still unsolved. It affects both on Win8
Another possibility is https://issues.apache.org/jira/browse/GUACAMOLE-303, which was recently merged. Guacamole's SFTP implementation assumes "/" exists and is listable, which is not necessarily the case, particularly on Windows.
On Jul 12, 2017 10:49, "Marko Nikolić" <[hidden email]> wrote:
In reply to this post by Marko Nikolić
I download and upload different files, so it's probably not an issue.
Even when I specify /C:/Users/UserXXX as a root folder, it gives me in the log
Jul 13 08:38:00 ip-172-31-21-9 guacd: Unable to open file "//Sketch.png"
When I forward to specific directory (not root) it gives as usual
Jul 13 08:35:52 ip-172-31-21-9 guacd: Unable to open file "/C:/64/Sketch.png"
Jul 13 08:37:41 ip-172-31-21-9 guacd: Unable to close file
When you're uploading the file, are you uploading by dragging the file into the browser window, or through clicking the upload button in Guacamole's file browser?
On Thu, Jul 13, 2017 at 1:22 AM, Suncatcher16 <[hidden email]> wrote:
Marko Nikolić wrote
It doesn't work either way.
On Thu, Jul 13, 2017 at 7:48 AM, Suncatcher16 <[hidden email]> wrote:
>> When you're uploading the file, are you uploading by dragging the file
>> the browser window, or through clicking the upload button in Guacamole's
>> file browser?
> It doesn't work either way.
Understood, but it's not clear to me which method you're using in each
case, and some of the specifics of the log messages don't match up
with what would be expected.
From what you posted previously:
> Even when I specify */C:/Users/UserXXX* as a root folder, it gives me in
> the log
> *Jul 13 08:38:00 ip-172-31-21-9 guacd: Unable to open
> file "//Sketch.png"*
This is odd, as specifying the root folder as "/C:/Users/UserXXX"
would result in uploads via the file browser going to that directory,
or subdirectories of that directory, like
"/C:/Users/UserXXX/Sketch.png". It shouldn't be "//Sketch.png".
If uploaded via dragging the file into the window, which would use the
default upload directory (which is independent of the file browser
root), this would be possible, and it would make sense that it fails
(as "//" is no doubt non-existent).
> When I forward to specific directory (not root) it gives as usual
> *Jul 13 08:35:52 ip-172-31-21-9 guacd: Unable to open file
I'm not sure exactly what you're saying here. What do you mean by
"forward to a specific directory (not root)"? Is this different from
what you were doing previously when specifying a specific folder like
"/C:/Users/UserXXX" for the root?
Is the "/C:/64/" folder writable by the account being used for SFTP?
Does the SSH server list any errors in its logs when these operations fail?
Forward to specific directory means "changing directory in built-in browser dir explorer". In my understanding when I specify dir in this built-in browser, the upload should go into this particular directory.
For example, this picture denotes that upload will go into the root of C folder.
Am i right?
Here is table of tests I made just now. Two sets of tests were made: w/ set default dir in connection and w/o. Terms:
Current directory is C:\64. This is directory specified in the opened inline file browser, default upload directory in connection settings is empty in this case.
Default directory is also /C:/64, it is a default upload directory in connection settings, built-in file browser is not opened in this case.
Current directory drag'n'drop:
Current directory button upload:
Default directory drag-n-drop:
Default directory button upload:
As you noticed, specifying directory gives nothing and upload goes into root folder anyway.
So yes, this is odd for me too.
On Fri, Jul 14, 2017 at 9:08 AM, Suncatcher16 <[hidden email]> wrote:
>> I'm not sure exactly what you're saying here. What do you mean by
>> "forward to a specific directory (not root)"?
> Forward to specific directory means "changing directory in built-in browser
> dir explorer". In my understanding when I specify dir in this built-in
> browser, the upload should go into this particular directory.
> For example, this picture denotes that upload will go into the root of C
> Am i right?
Yes, that's correct.
>> but it's not clear to me which method you're using in each
>> case, and some of the specifics of the log messages don't match up
>> with what would be expected.
> Here is table of tests I made just now. Two sets of tests were made: w/ set
> default dir in connection and w/o. Terms:
> *Current directory* is *C:\64*. This is directory specified in the opened
> inline file browser, default upload directory in connection settings is
> empty in this case.
> *Default directory* is also */C:/64*, it is a default upload directory in
> connection settings, built-in file browser is not opened in this case.
> Current directory drag'n'drop:
>> Jul 14 16:12:00 ip-172-31-21-9 guacd: Unable to open file
> Current directory button upload:
>> Jul 14 16:13:07 ip-172-31-21-9 guacd: Unable to close file
>> Jul 14 16:13:07 ip-172-31-21-9 guacd: Unable to open file
As the path is correct in these cases, there must be something else
preventing the upload from succeeding. My first guess would be
permissions, but the SSH server logs may have specifics on what is
> As you noticed, specifying directory gives nothing and upload goes into root
> folder anyway.
>> This is odd, as specifying the root
> So yes, this is odd for me too.
Is it possible that you're only using a recent build of
guacamole-client, and not guacamole-server, thus the new SFTP root
directory parameter is being ignored?
What do you mean by guacamole-server? WAR-file?
My guacd is
And my Tomcat app is 0.9.12 too.
sshd server log contains no SFTP-related strings at all. It looks like this:
If this is a permissions issue on server, why do all other clients work fine? For me it's clearly guacamole issue, as empty server log tells use that SFTP requests from Guacamole are not even reached the server.
On Fri, Jul 14, 2017 at 11:10 AM, Suncatcher16 <[hidden email]> wrote:
>> Is it possible that you're only using a recent build of
>> guacamole-client, and not guacamole-server, thus the new SFTP root
>> directory parameter is being ignored?
> What do you mean by /guacamole-server/? WAR-file?
I mean the body of code which builds guacd, libguac, the various
supported protocols, etc.:
The WAR file (part of guacamole-client) is somewhat relevant, too, as
only an up-to-date web application would have the definition of the
new "sftp-root-directory" parameter, but that would only make defining
a connection which uses that parameter more difficult for users of the
database authentication. The key piece which determines whether the
parameter works is guacamole-server. If too old, the
"sftp-root-directory" parameter will not exist for the protocol
plugins loaded by guacd, and specifying it will have no effect.
> My guacd is
>> Starting guacd: guacd: INFO: Guacamole proxy daemon (guacd)
>> version 0.9.12-incubating started
> And my Tomcat app is 0.9.12 too.
Ah, OK - that definitely would not have the necessary parameter then.
The changes from GUACAMOLE-303 were merged in after the version
numbers were bumped to 0.9.13-incubating in anticipation of the first
RC. To be able to use the new parameter, you will need to build from
The new "sftp-root-directory" parameter only affects the directories
displayed in the file browser, however. If you are already able to
navigate through the file browser without error, then that isn't the
I agree that if the only SFTP client that fails in your case is
Guacamole, then that suggests the problem is within Guacamole. It is
unlikely that the SFTP requests are not reaching your SSH server at
all - if the SFTP connection had failed, then Guacamole would have
aborted the connection entirely.
When testing Guacamole vs. other SFTP clients, are you using the same
user account on the RDP server in all cases?
I built them, guacd and guacamole-server at the same time, so they definitely match each other.
So what I steps I can take further to narrow the problem?
This post was updated on .
I have been running into this issue. In my case it is an incompatibility
between libssh2 and openssh (Win32 ). To get around this I downloaded the
libssh2 code from Github and made the following changes:
around line 1060 in sftp_open in sftp.c
attrs.permissions = mode |
(open_file ? LIBSSH2_SFTP_ATTR_PFILETYPE_FILE :
attrs.permissions = mode;
Run automke tools, run configure, make libssh2, make install libssh2. Then
recompile guacamole server from source against this modified libssh2
library, install guacamole server, restart guacamole client and everything
worked. Issue is current libssh2 performing this OR with
LIBSSH2_SFTP_ATTR_PFILETYPE_FILE makes the permissions something like
0100755 instead of 0755 and the Win32 OpenSSH server can't cope. Turn on
logs in Win32 OpenSSH to see what the sftp server is doing. Add l VERBOSE to
the sftp-server command line args in sshd_config.
You may also need to change Windows permission on the sftp-server.log file
if anyone other than Administrator or NTSERVICE\sshd is performing the file
transfer. Ironically, the OpenSSH sftp client works.
Sent from: http://apache-guacamole-incubating-users.2363388.n4.nabble.com/
|Free forum by Nabble||Edit this page|