Univention Bugzilla – Bug 37858
Be more fault-tolerant while mounting USB devices
Last modified: 2023-06-28 10:32:46 CEST
Created attachment 6708 [details] udevadm info -q env -n sdb1 Because of a recently implemented check in add_fstab_entry, usb devices without a detectable filesystem are ignored: > # ignore disk devices without a filesystem > if [ "$ID_TYPE" = "disk" -a -z "$ID_FS_TYPE" ]; then > echo "univention-ucc-remote-mount: Device $devicename has no filesystem, ignoring" | logger > exit 0 > fi In a customer environment I've seen a certain type of USB pen drives that work fine with Windows but don't get mounted with UCC 2.0. Checking with "udevadm info -q env -n sdb1" reveals that "ID_FS_TYPE" is not given (see attachment) and therefore the device is ignored. Fun fact: the identical USB pen drive works fine with UCC 1.0, because the check above is not implemented there. Maybe it's sufficient to make the execution if the check above configurable via UCR?
(In reply to Michael Grandjean from comment #0) > In a customer environment I've seen a certain type of USB pen drives that > work fine with Windows but don't get mounted with UCC 2.0. Checking with > "udevadm info -q env -n sdb1" reveals that "ID_FS_TYPE" is not given (see > attachment) and therefore the device is ignored. Before considering a workaround with a UCR variable we should investigate why ID_FS_TYPE is missing and how we can fix this in a generic manner. What filesystem is used on the pen drive, I suppose it's using NTFS? It would be useful to know whether a manual mount works without specifying the filesystem type, e.g. "mount /dev/foo /mnt/test"
(In reply to Moritz Muehlenhoff from comment #1) > What filesystem is used on the pen drive, I suppose it's using NTFS? In this case it was FAT32. > It would be useful to know whether a manual mount works without specifying > the filesystem type, e.g. "mount /dev/foo /mnt/test" Unfortunately I always tried WITH specifying the filsystem type ("-t vfat") and don't have access to the customer system right now. But as far as I can see, the command that is finally issued in UCC 1.0 (where everything worked) is: > mountoptions="" > filesystemoptions="" > [...] > [ checks with blkid ] > [...] > mount $mountoptions $filesystemoptions /dev/$devicename ${MOUNTPOINT} Since the device was not listed in "blkid", $filesystemoptions stays empty which leads to: > mount /dev/$devicename ${MOUNTPOINT} So, in theory this should've worked. I will try to check back with the customer.
(In reply to Michael Grandjean from comment #2) > I will try to check back with the customer. As I suspected, the following is successfully executed: > mount /dev/sdb1 /run/drives/usbdisk-sdb1 I'll attach the syslog excerpt.
Created attachment 6729 [details] syslog while mounting affected usb pen drive
(In reply to Moritz Muehlenhoff from comment #1) > (In reply to Michael Grandjean from comment #0) > > In a customer environment I've seen a certain type of USB pen drives that > > work fine with Windows but don't get mounted with UCC 2.0. Checking with > > "udevadm info -q env -n sdb1" reveals that "ID_FS_TYPE" is not given (see > > attachment) and therefore the device is ignored. > > Before considering a workaround with a UCR variable we should investigate > why ID_FS_TYPE is missing and how we can fix this in a generic manner. The VFAT filesystem created by the pen drive manfacturer is indeed malformed, the dmesg also shows status messages on malformed meta data entries. So adding an override UCR variable seems in fact the preferable solution.
UCC 1.x / 2.x is out of maintenance. In case this Bug is still relevant please clone with the correct version.