Bug 37928 - Copying files to USB devices is limited by the size of /run
Copying files to USB devices is limited by the size of /run
Status: CLOSED FIXED
Product: Univention Corporate Client (UCC)
Classification: Unclassified
Component: Terminal services
UCC 1.0
Other Linux
: P5 normal
: UCC 3.0-errata
Assigned To: Felix Botner
Erik Damrose
:
: 20107 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-03-03 13:46 CET by Michael Grandjean
Modified: 2016-10-17 14:28 CEST (History)
4 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
Screenshot of Windows warning (146.02 KB, image/png)
2015-03-03 13:46 CET, Michael Grandjean
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Grandjean univentionstaff 2015-03-03 13:46:31 CET
Created attachment 6733 [details]
Screenshot of Windows warning

The size of a file that can be copied from a Windows Server to a locally attached USB device seems to be limited by the size of the partition '/run'.

For example:
In a XenApp session I tried to copy the file "UCS_Update_4.0-0_-_4.0-1-amd64.iso" which is ~ 473 MB to a 4 GB USB pen drive formatted with FAT32.
About 3,8 GB were still available on the pen drive, but a Windows warning appeared, telling me that additional 272 MB are needed on the target device (see attached screenshot). At that time the local filesystems looked like this:

> root@uccterra:~# df -h
> Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
> overlayfs-root 1008M    5,8M 1002M    1% /
> udev            994M     12K  994M    1% /dev
> tmpfs           202M    796K  201M    1% /run
> /dev/sda3       7,2G    4,0G  2,9G   59% /ucc_root
> tmpfs-root     1008M    5,8M 1002M    1% /root-rw
> /dev/loop0      3,9G    1,9G  1,9G   50% /root-ro
> none            5,0M       0  5,0M    0% /run/lock
> none           1008M    204K 1008M    1% /run/shm
> /dev/sda2        88M     44M   38M   54% /boot
> /dev/sdb1       3,8G    232K  3,8G    1% /run/drives/usbdisk-sdb1

Please note that on '/run' there are 201M available. That corresponds to the Windows warning (473 - 201 = 272).

I tested this with a second UCC image (default thinclient image ucc-1.0-rev3). This time the numbers were different, but the problem stayed the same:
Windows: additional 71 MB are needed
Available on '/run': 403M
-> 473 - 403 = ~ 71 MB (I guess there are some rounding errors)

This applies to Citrix XenApp sessions and might be a limitiation in the Citrix components (copying the file works fine in a RDP session).
I tested only UCC 1.0 with Citrix Receiver 13.1, but I guess that this might also affect other versions.
Comment 1 Michael Grandjean univentionstaff 2015-03-03 13:49:11 CET
This was initially reported via Ticket#2014110321000159
Comment 2 Moritz Muehlenhoff univentionstaff 2015-03-05 15:06:07 CET
This is related to the design of the media mount on thin clients in UCC: 
We're using a tmpfs /var/run/drives. All locally attached storage is mounted below this path by the udev rules. Once the Citrix Receiver attempts to write to that partition the statfs check for free diskspace is emitted for the tmpfs. The Citrix Receiver is unable to detect that the actual target directory is on a different partition.

It would be possible to create a stub library which is LD_PRELOADed to the Citrix Receiver which returns a fake value for statfs->f_bavail, but that would be quite a hack and might have side effects (such as not properly detecting legitimate out-of-disk-space conditions).

As discussed with Michael IMO we should evaluate the options of using storage devices in combination with ctxusb.
Comment 3 Erik Damrose univentionstaff 2016-07-22 14:43:03 CEST
Lets try to direct storage devices to the session directly, see bug #41233 and http://support.citrix.com/article/CTX137939
Comment 4 Felix Botner univentionstaff 2016-07-26 18:05:27 CEST
usb redirection for mass storage devices (failed)

1. required change on UCC
 * allow class=08 in /opt/Citrix/ICAClient/usb.conf
 * disable /lib/udev/rules.d/50-ucc-remote-mount.rules
   (mounting of usb devices)

2. ctxusb - does not work (out of the box)
 * this prog is started by wfica during the session startup and handles the
   detection and redirection of usb devices  
 * as only root has rw access to /dev/bus/usb, ctxusb is installed with
   the setuid bit, unfortunately on UCC 3.0 ctxusb fails to start with

   Jul 18 13:35:16 hp ctxusb[7520]: /proc/7512/exe: parent readlink: Permission 
   denied

   this works on UCC 1.0 but i was unable to find out why no longer on 3.0
 * i tried the following workaround 
   * removed setuid from /opt/Citrix/ICAClient/ctxusb
   * added new udev rule to give my user permission for new devices

     SUBSYSTEM!="usb", GOTO="end_skip_usb"
     ATTRS{idVendor}=="*", ATTRS{idProduct}=="*", GROUP="guest-px77n4"
     LABEL="end_skip_usb"

     systemctl restart udev

   * give permissions to existing devices

     chmod -R 777 /dev/bus/usb

 * now ctxusb can be started by wfica and new devices are redirected to the
   citrix session

3. redirection does not work

 * i have managed to setup usb redirection for mass storage devices, and i can
   see new devices in the windows explorer, BUT

   * data transfer is very slow
   * i can not eject usb devices in windows (says that the device is still in 
     use)
   * i get windows error messages about a non-functional usb device
   * worked only for one of my usb stick's
   * i get this 10x a second in the clients syslog

     Jul 18 14:59:31 hp ctxusb[5661]: OK si_code -4 in SIG_REAP
     Jul 18 14:59:31 hp ctxusb[5661]: Recognised request

   * sometimes the linux kernel resets the usb device number

     kernel: [ 1087.749726] usb 3-2: reset high-speed USB device number 
     9 using xhci_hcd

     and ctxusb gets confused

     hp kernel: [ 1097.769437] usb 3-2: usbfs: process 5634 (ctxusb) did not 
     claim interface 0 before use


But instead of usb redirection, we could use DynamicCDM (dynamic client drive mapping) in /wfclient.ini

Dynamic client drive mapping monitors the directories in which hardware devices such as CD-ROMs, DVDs and USB memory sticks are typically mounted on the user device and any new ones that appear during a session are automatically mapped to the next available drive letter on the server.

 CDMAllowed=On
 DynamicCDM=On
 DynamicCDMDirs=/run/drives
;DrivePathZ=/run/drives
;DriveEnabledZ=Yes
;DriveReadAccessZ=0
;DriveWriteAccessZ=0

Now wfica maps every directory within /run/drives as new letter (devices) in windows.

NOW "Copying files to USB devices is limited by the size of /run" no longer applies. I can copy data to the drive within the session even if /run is at 100%.
Comment 5 Felix Botner univentionstaff 2016-07-27 14:37:41 CEST
*** Bug 20107 has been marked as a duplicate of this bug. ***
Comment 6 Felix Botner univentionstaff 2016-07-27 14:43:56 CEST
added 

 CDMAllowed=On
 DynamicCDM=On
 DynamicCDMDirs=/run/drives
;DrivePathZ=/run/drives
;DriveEnabledZ=Yes
;DriveReadAccessZ=0
;DriveWriteAccessZ=0

to conffiles/usr/share/ucc/citrix-conf/wfclient.ini in univention-ucc-session-xenapp.
Comment 7 Erik Damrose univentionstaff 2016-10-07 15:16:37 CEST
OK: USB devices are available in citrix session if, usb client drive redirection is configured
OK: Not limited by tmpfs size

Already released with UCC 3.0
Comment 8 Erik Damrose univentionstaff 2016-10-17 14:28:07 CEST
(In reply to Erik Damrose from comment #7)
> Already released with UCC 3.0

And now working with updated icaclient http://errata.software-univention.de/ucc/3.0/2.html