Another option, particularly if you are concerned about file permissions,
is to utilize the SFTP support in Guacamole.  If you're using the
${GUAC_USERNAME} and ${GUAC_PASSWORD} parameters, and you have a SFTP
server that integrates with your Windows (AD) authentication, you can do
this transparently such that the SFTP connection is established using the
same credentials as Windows and happens at connection time.  This does
require maintaining a SFTP server, so it isn't quite as low-maintenance as
just using the RDP file sharing, but just another possibility.

-Nick

On Wed, Mar 25, 2020 at 6:21 AM Stefan Bogdan Cimpeanu <bog...@cimpeanu.org>
wrote:

> Hi Chris,
>
> Perfectly valid, but then we’d have to maintain a NAS (or two) too
> (resources, maintenance, backups, etc.) :)
> Also, the scenario here is a bit more complex too, where we’d need to have
> different data locations for different countries, due to legal requirements.
>
> The most elegant way would’ve been user affinity, but I suppose that’s not
> really possible.
>
> Thanks,
> Bogdan
>
> On 25 Mar 2020, at 12:14, Chris Lee <chris...@centurycity.com.hk> wrote:
>
> Hi Bogdan,
>
> How about multiple severs mount the same NAS shared folder?
>
> /mnt/nas/guaca/${GUAC_USERNAME}
>
> Regards,
> Chris
>
> *From:* Stefan Bogdan Cimpeanu <bog...@cimpeanu.org>
> *Sent:* Wednesday, March 25, 2020 5:02 PM
> *To:* user@guacamole.apache.org
> *Subject:* Re: Best Settings for RDP virtual disk drive
>
> This is a good topic though… we’ve also set up using
> /some/path/${GUAC_USERNAME} but facing the following issue: given we’ve
> multiple guacamole servers behind load balancers, users don’t always hit
> the same instance, hence their data is not available.
> Any way to set some sort of affinity at user level?
>
> The alternative would be to use network mounts for the users directories,
> but we’d want to avoid that.
>
> Regards,
> Bogdan
>
>
> On 25 Mar 2020, at 07:25, Sebastian Männling <
> sebastian.maennl...@qubestack.org> wrote:
>
> Hi,
>
> you can use ${GUAC_USERNAME}
>
>
> See
> https://guacamole.apache.org/doc/gug/configuring-guacamole.html#parameter-tokens
>
> Regarding the /tmp directory, keep in mind that there are automatic
> cleanup jobs and usually iirc /tmp is tmpfs (ram) in fedora.
> Sent from my iPhone
>
>
> On 25. Mar 2020, at 03:50, Chris Lee <chris...@centurycity.com.hk> wrote:
>
> 
> Hi All,
>
> I am setup the Apache Guacamole 1.1.0 on Fedora Linux with AD Auth against
> with MS AD which using MySQL database as backend.
>
> For RDP Virtual Disk Drive setting, any recommendation for setup Drive
> Path for all AD users without share the same path?
>
> <image001.png>
>
>
> For example:
>
> AD user ID           Drive Path:
>
> David                     /tmp/share-drive/david
> Peter                     /tmp/share-drive/peter
>
> Also, it is safe to set it on /tmp folder or other folder?
>
> Many thanks in advance.
>
> Regards,
> Chris
>
>
>
> This message and its attachment (if any) are strictly confidential and
> sent to the designated recipient(s) only. If you are not the intended
> recipient, please notify the sender by e-mail and delete this message and
> its attachment (if any) from your computer system immediately . Century
> City International Holdings Limited, Paliburg Holdings Limited, Regal
> Hotels International Holdings Limited, its respective related subsidiaries,
> associated companies and affiliates do not guarantee this message and its
> attachment (if any) are free of computer virus and would not accept any
> liability whatsoever arising from Internet transmission.
>
>
>
>
> This message and its attachment (if any) are strictly confidential and
> sent to the designated recipient(s) only. If you are not the intended
> recipient, please notify the sender by e-mail and delete this message and
> its attachment (if any) from your computer system immediately . Century
> City International Holdings Limited, Paliburg Holdings Limited, Regal
> Hotels International Holdings Limited, its respective related subsidiaries,
> associated companies and affiliates do not guarantee this message and its
> attachment (if any) are free of computer virus and would not accept any
> liability whatsoever arising from Internet transmission.
>
>
>

Reply via email to