s...@stix.id.au (Paul Ripke) writes: >I guess I'm a little surprised by this error? >Nor does read(2) list EROFS as a possible return, which seems sensible.
The errors listed with system calls are rarely complete, in particular for errors you rarely observe or here for operations on something else than regular files. >Looking at the code, I'm guessing the drive is returning >SKEY_DATA_PROTECT for some reason, so this is likely not a bug, but >interesting behaviour. >Jun 27 16:19:40 slave /netbsd: [ 3710565.0174648] sd0(umass0:0:0:0): Check >Condition on CDB: 0x28 00 2a 44 2f 68 00 00 08 00 >Jun 27 16:19:40 slave /netbsd: [ 3710565.0174648] SENSE KEY: Write >Protected >Jun 27 16:19:40 slave /netbsd: [ 3710565.0174648] ASC/ASCQ: Logical Unit >Access Not Authorized >Jun 27 16:19:40 slave /netbsd: [ 3710565.0174648] sd0d: error reading fsbn >709111656 of 709111656-709111663 (sd0 bn 709111656; cn 346245 tn 59 sn 8) It's still a READ_10 command. The translation from SKEY_DATA_PROTECT to "Write Protected" isn't always correct, but the choices are limited. The more detailed SCSI status "Logical Unit Access Not Authorized" usually refers to the drive being password locked. Now find out if that reflects reality or if the USB enclosure just tries to interpret some other condition and reports this code for lack of something more specific.
