On Fri, Feb 10, 2023, 12:50 AM Christopher Klinge <[email protected]> wrote:
> ... > > Downloading however does not appear to work reliably at all. It starts > with me being unable to move files into the "Download" directory on the VM. > To the user it looks like nothing is happening at all. The same behaviour > can be observed when moving files onto the share using Powershell. The > guacd log contains limited additional information: > > guacd[184]: ERROR: File open refused (-2): "\Download\test" > > Interestingly I am able to create empty files in the Download directory by > right clicking and using the context menu. These empty files do show up in > the Guacamole sidebar and I can download them. > The "Download" directory of the emulated filesystem is handled differently by guacd. Normal filesystem operations that otherwise would be transformed into local filesystem changes within the drive storage on the server are instead intercepted and used to download the file. If you attempt to create a file within that location, that signals guacd to start a download. If you write to that file (while it is still open), that streams a block of data via the in-progress download. If you close the file, the download is completed and the underlying file within "Download" is removed. If nothing described above sounds like it would interfere with what you're trying to do, things should be working. The only known cases where this cannot work are: * Applications that create files by first creating a temporary file, closing that file, reopening it, etc. until it's fully written, and then finally renaming the file to its final name when complete. For example, saving a file directly within "Download" from some browsers or from MS Office applications can fail for this reason. * The underlying filesystem on the Guacamole server prevents these operations (this does not appear to be happening here). The error you've noted above may actually just be due to Windows attempting to reread the properties of a file it's expecting to exist, and may not be related to the lack of a download at all. Trying to add content to the files via the VM fails with the previous error > message. When I go back into the guacd container, the files do exist in ` > /tmp/drive/Download`. I can add content to them this way, but once I have > done that, I can no longer download them. > > guacd@node$ echo "test1234" > /tmp/drive/Download/testfile.txt > Any file within this directory will cease to exist once it is closed, unless the server lacks permission to remove that file (unlikely). Lastly I have checked the browser for error messages too, but could not > find any. The console doesn't show any output and the network history > contains no failed requests. > Do you have anything on the network in front of the Guacamole server that might be blocking requests? When the file move/copy to "Download" occurs, is this happening from within the RDP session (this should work)? Or are you attempting to perform this move outside the session (this won't work)? When moving/copying the file to "Download", was the destination already opened in a previous RDP session? If so, this will not work, as the drive that the Windows application is referencing no longer exists - the RDP server within Windows ensures that each new RDP connection gets a fresh, isolated drive, and that the previous drive ceases to be valid. For example, if you have a copy of Windows Explorer open and the "Download" directory shown, that particular path doesn't exist any longer because the RDP server has cleaned up resources. You would need to re-navigate to the drive and its "Download" directory to have the correct and valid path. - Mike
