Vaguely remember a problem when people used usbmount first causing some conflicts.
After you mount the storage, check the real mount options used - the mount command will show those for all mounted storage.
Using fsck on Linux to fix broken FAT32 is not likely to actually work. Connect to Windows and run chkdsk or/and scandisk to fix FAT32 or exFAT or NTFS issues. Don't use Linux to fix Windows file systems. The most we can hope for from Linux is that once a device stops working, that Linux will allow access to the files to get the data off, maybe.
Similarly, for Linux file systems, don't use Windows tools to try an fix stuff. It won't.
I haven't used vfat in some time - perhaps a year - but my last working autofs configuration was this:
Code:
/etc/auto.misc:/misc/16G -nodev,nosuid,timeout=2,fstype=vfat,uid=1000,gid=1000 LABEL=16G
That would turn into a mount command like this:
Code:
sudo mount -t vfat -o nodev,nosuid,timeout=2,uid=1000,gid=1000 LABEL=16G /misc/16G
My umask is 0002, so that would be picked up by the mount command. For temporary storage, I prefer to mount using the LABEL option, not UUID or device. As a human, I remember labels better, though with autofs, I actually don't need to know any of that once it is setup. Just plug the flash drive in, wait 5 seconds for the OS via udev to see the new storage connection, then simply access the storage ....
cd /misc/16G/ and use as normal. autofs will automatically remove the mount when all files become unused on it for a few minutes. I use df -Th to verify the mount it gone before pulling the usb device out.
But whether we use LABEL, UUID or the device partition with the file system, shouldn't matter at all.
What may matter is which OS release are you running? My systems with USB ports are all 16.04.6 The problem could be release or kernel specific.
Bookmarks