[X2Go-User] USB forwarding documentation

Stefan Baur X2Go-ML-1 at baur-itcs.de
Wed Nov 8 00:39:25 CET 2017


Am 07.11.2017 um 23:56 schrieb Seth Galitzer:
> On 11/07/2017 03:49 PM, Stefan Baur wrote:
>> Am 07.11.2017 um 21:41 schrieb Seth Galitzer:
>>> I'm calling xfreerdp from TCE to connect directly to the RDP server.
>>> I've been trying to find the right cli options for xfreerdp to use for
>>> this, but documentation is pretty light on this and I have yet to find
>>> something that works.
>>>
>>> If I run dmesg on the thin client device from within the TCE desktop, I
>>> can see that my flash drive is recognized, but it's not getting mounted.
>>> That sounds like a udev issue within debian, but I was hoping somebody
>>> on the list had already solved this problem.
>>
>> So your actually have two problems:
>> 1) getting the automounter to mount your flash drive.
> 
> I've found two ways to do this so far:
> A) Install usbmount package (https://usbmount.alioth.debian.org/). I've
> tested this and it works, but needs some tweaking to produce a
> reliable/duplicatable mount point. This claims to work for vfat, ext*
> and hfs.
> 
> B) Configure udev to use pmount when a USB storage device is detected
> (https://unix.stackexchange.com/a/124060). I haven't tested this yet,
> but if the above option works, I'm guessing this is the manual
> implementation of it, so it should work.

Neither of these options is going to make it into an official TCE build,
I'm afraid.  The thing is, we *have* an automounter, it does more than
just mounting the drive, and it does things in certain ways X2GoClient
expects them to be.  So teaching ours to handle additional filesystem
types is going to be easier than ripping it out, replacing it with
usbmount/pmount, and then adding all those bells and whistles again that
we need for supporting mounts in an X2Go session.
And if you install any of those in parallel to our automounter, there's
no guarantee where your mounts will end up.

What the current X2Go-TCE automounter does is, it uses the information from
/sys/block/<partitiondevice>/device/vendor
and
/sys/block/<partitiondevice>/device/model

to define the name of the mount point under /media, e.g.:
/media/Generic_Flash_Disk/sda1
       vendor  model      partitiondevice

In case of "superfloppy" partitionless flash media, it will be e.g. sda
instead of sda1.

Spaces in vendor or model name are replaced by underscores.

What you could do is add a script that parses the output of "lsblk
--list", for example, and uses that information to add a symlink to the
real mountpoint.

The actual problem with mounting ext* is file/directory ownerships and
access rights. The user account on the thin client is a local user with
uid and gid 1000. If the files on your flash drive are ext*, owned by a
user with any other uid/gid, and have strict permissions, the TC user
can't access them, as, according to the mount man page, enforcing a uid
or gid at mount time is not supported for ext* (it is for VFAT and hfs).


>> 2) getting xfreerdp to forward that mountpoint to the RDP server.
> 
> This is proving difficult if not impossible. Supposedly, some invocation
> of the /drive option should work, but I have not found good
> documentation on syntax, nor have suggestions I found so far worked. Use
> of the /usb option is not recommended as supposedly this is for
> redirecting devices, such as printers or HID. There is even much
> discussion among freerdp devs and users on how to properly implement
> this functionality.

My understanding is that you need to specify a share name along with the
local path, so something like

/drive:flashmedia,/media/Generic_Flash_Disk/sda1 /drive:home,/home/user

should result in \\TSCLIENT\flashmedia and \\TSCLIENT\home becoming
available inside the RDP session.

Kind Regards,
Stefan Baur

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x2go.org/pipermail/x2go-user/attachments/20171108/b6a35e2e/attachment-0001.sig>


More information about the x2go-user mailing list