Samsung Portable SSD T3 not recognized in some Linux distros

(for future reference)
My Samsung Portable SSD T3 USB 3.0 external drive mounts fine in many operating systems but not in all Linux operating systems.

When the drive is attached through a USB 2 hub, it is recognized and mounts as a normal usb storage device. However, using USB 3, uas (USB Attached SCSI) tries to handle the drive, and fails with errors. dmesg reports the following:

[   79.365649] usb 3-2: USB disconnect, device number 3
[   95.986879] usb 3-2: new SuperSpeed USB device number 5 using xhci_hcd
[   96.008915] usb 3-2: New USB device found, idVendor=04e8, idProduct=61f3
[   96.008917] usb 3-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[   96.008918] usb 3-2: Product: Portable SSD T3
[   96.008918] usb 3-2: Manufacturer: Samsung
[   96.008919] usb 3-2: SerialNumber: [REDACTED]     
[   96.024373] scsi host3: uas
[   96.034588] usb 3-2: stat urb: status -32
[   96.034633] scsi 3:0:0:0: tag#0 data cmplt err -32 uas-tag 1 inflight: CMD 
[   96.034636] scsi 3:0:0:0: tag#0 CDB: Inquiry 12 00 00 00 24 00
[  116.976075] scsi 3:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD 
[  116.976082] scsi 3:0:0:0: tag#0 CDB: Inquiry 12 00 00 00 24 00
[  116.976099] scsi host3: uas_eh_bus_reset_handler start
[  117.104269] usb 3-2: reset SuperSpeed USB device number 5 using xhci_hcd
[  117.142580] scsi host3: uas_eh_bus_reset_handler success
[  117.144741] scsi 3:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD 
[  117.144748] scsi 3:0:0:0: tag#0 CDB: Test Unit Ready 00 00 00 00 00 00
[  117.144753] scsi host3: uas_eh_bus_reset_handler start
[  117.381185] usb 3-2: reset SuperSpeed USB device number 5 using xhci_hcd
[  117.419021] scsi host3: uas_eh_bus_reset_handler success
[  117.419032] scsi 3:0:0:0: Device offlined - not ready after error recovery

Others have encounted a similar problem, including:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1584557
https://bbs.archlinux.org/viewtopic.php?id=204256
https://unix.stackexchange.com/questions/332390/trying-read-a-sata-usb-3-0-kali-linux-light

To address this, first I unplugged the USB drive. Then I created a file named uas-quirks.conf in /etc/modprobe.d. In this file I placed these lines:

blacklist uas
usb-storage quirks=04e8:061f3:u

The quirks parameter refers to the USB vendor and product ID, seen in the dmesg output.

Then I removed the uas and usb-storage modules:

# rmmod uas usb-storage

Then I reinserted the drive. dmesg shows the successful recognition and mounting of the drive:

[  440.997304] usb 3-2: USB disconnect, device number 7
[  444.483537] usb 3-2: new SuperSpeed USB device number 8 using xhci_hcd
[  444.508678] usb 3-2: New USB device found, idVendor=04e8, idProduct=61f3
[  444.508683] usb 3-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[  444.508686] usb 3-2: Product: Portable SSD T3
[  444.508688] usb 3-2: Manufacturer: Samsung
[  444.508690] usb 3-2: SerialNumber: [REDACTED]    
[  444.548376] usb 3-2: UAS is blacklisted for this device, using usb-storage instead
[  444.548379] usb-storage 3-2:1.0: USB Mass Storage device detected
[  444.552347] usb-storage 3-2:1.0: Quirks match for vid 04e8 pid 61f3: 800000
[  444.552392] scsi host3: usb-storage 3-2:1.0
[  444.552589] usbcore: registered new interface driver usb-storage
[  445.575738] scsi 3:0:0:0: Direct-Access     Samsung  Portable SSD T3  0    PQ: 0 ANSI: 6
[  445.578869] sd 3:0:0:0: Attached scsi generic sg5 type 0
[  445.583770] sd 3:0:0:0: [sde] 488397168 512-byte logical blocks: (250 GB/233 GiB)
[  445.586010] sd 3:0:0:0: [sde] Write Protect is off
[  445.586019] sd 3:0:0:0: [sde] Mode Sense: 43 00 00 00
[  445.591757] sd 3:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  445.610612]  sde: sde1
[  445.621442] sd 3:0:0:0: [sde] Attached SCSI disk
[  445.924981] EXT4-fs (sde1): mounted filesystem with ordered data mode. Opts: (null) 

This is lost after a reboot, though removing the uab and usb-storage modules again (via the rmmod command, above) and reinserting the drive fixes this.

To make this stick through a reboot, the initial ramdisk must be regenerated. This is mentioned for Arch linux in post 12, here: https://bbs.archlinux.org/viewtopic.php?id=183190. For Debian-based distros, we must use

# update-initramfs -u

as described in https://unix.stackexchange.com/questions/268903/what-is-the-equivalent-of-mkinitcpio-conf-on-debian

Reboot, and the drive should become available at boot.