Having the same issue with two USB disks: SAMSUNG_SV2042H and Myson_Century__Inc._USB_Mass_Storage_Device_100.
I did some debugging and this is what I came up with:
When you right-click on a USB drive and choose "Safely remove drive", this is what happens in the background:
1. Nautilus calls udisks --umount <device file of USB drive>"
2. udisks contact a background-process named "udisks-daemon".
3. udisks-daemon inturn invokes "/usr/lib/udisks/udisks-helper-drive-detach".
4. udisks-helper-drive-detach calls some sg3-utils to synchronize the cache and stop the device ("sg_ll_sync_cache_10" at line ~184 and "sg_ll_start_stop_unit" at line ~202 in source file "job-drive-detach.c"). Both of these functions return an error message.
You can easily reproduce the error messages caused by sg3-utils by running the sg3-utils manually. In order to reproduce the first error message ("SYNCHRONIZE CACHE: FAILED: No such file or directory"), run this command:
sg_sync --verbose <device file of USB drive>
Example: sg_sync --verbose /dev/sdc
This yields the precise error message returned by the sg3 backend:
synchronize cache(10) cdb: 35 00 00 00 00 00 00 00 00 00
synchronize cache(10): Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid field in cdb
bad field in Synchronize cache command
In order to reproduce the second error message ("STOP UNIT: FAILED: No such file or directory"), run this command:
sg_start --stop --verbose <device file of USB drive>
Example: sg_start --stop --verbose /dev/sdc
Again, this yields a more precise error message than the general "No such file or directory" as shown by the graphical front-end:
Start stop unit command: 1b 00 00 00 00 00
start stop unit: Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid field in cdb
invalid field in cdb
START STOP UNIT command failed
In conclusion, it looks like the sg3-utils send the wrong commands to the SCSI layer or wherever these commands go (I am not that much into low level SCSI programming, my apologies). However, I don't see any adverse effects from these erroneous commands. Even though the sg3-utils functions return an error, udisk-daemon properly continues and cleanly unmounts the USB drive as far as I can tell (it invokes umount, which should sync the cache anyway). To try this out, I removed the two calls to the functions "sg_ll_sync_cache_10" and "sg_ll_start_stop_unit" from the source code of udisks "job-drive-detach.c" and recompiled the thing. Nautilus stopped whining about the failure of these two functions and the drives are unmounted perfectly. :-)
I would have attached a patch, but I do not really have a clue about what these two functions do precisely. In fact, it might have been a bad thing to remove the function calls from "job-drive-detach.c". I cannot say, if this may result in loss of data (someone with some SCSI programming knowledge please explain). Plus, I imagine that for most users it may actually be useful that these functions are called. So it would not really be a patch.
Having the same issue with two USB disks: SAMSUNG_SV2042H and Myson_Century_ _Inc._USB_ Mass_Storage_ Device_ 100.
I did some debugging and this is what I came up with: udisks/ udisks- helper- drive-detach" . helper- drive-detach calls some sg3-utils to synchronize the cache and stop the device ("sg_ll_ sync_cache_ 10" at line ~184 and "sg_ll_ start_stop_ unit" at line ~202 in source file "job-drive- detach. c"). Both of these functions return an error message.
When you right-click on a USB drive and choose "Safely remove drive", this is what happens in the background:
1. Nautilus calls udisks --umount <device file of USB drive>"
2. udisks contact a background-process named "udisks-daemon".
3. udisks-daemon inturn invokes "/usr/lib/
4. udisks-
You can easily reproduce the error messages caused by sg3-utils by running the sg3-utils manually. In order to reproduce the first error message ("SYNCHRONIZE CACHE: FAILED: No such file or directory"), run this command:
sg_sync --verbose <device file of USB drive>
Example: sg_sync --verbose /dev/sdc
This yields the precise error message returned by the sg3 backend:
synchronize cache(10) cdb: 35 00 00 00 00 00 00 00 00 00
synchronize cache(10): Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid field in cdb
bad field in Synchronize cache command
In order to reproduce the second error message ("STOP UNIT: FAILED: No such file or directory"), run this command:
sg_start --stop --verbose <device file of USB drive>
Example: sg_start --stop --verbose /dev/sdc
Again, this yields a more precise error message than the general "No such file or directory" as shown by the graphical front-end:
Start stop unit command: 1b 00 00 00 00 00
start stop unit: Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid field in cdb
invalid field in cdb
START STOP UNIT command failed
In conclusion, it looks like the sg3-utils send the wrong commands to the SCSI layer or wherever these commands go (I am not that much into low level SCSI programming, my apologies). However, I don't see any adverse effects from these erroneous commands. Even though the sg3-utils functions return an error, udisk-daemon properly continues and cleanly unmounts the USB drive as far as I can tell (it invokes umount, which should sync the cache anyway). To try this out, I removed the two calls to the functions "sg_ll_ sync_cache_ 10" and "sg_ll_ start_stop_ unit" from the source code of udisks "job-drive- detach. c" and recompiled the thing. Nautilus stopped whining about the failure of these two functions and the drives are unmounted perfectly. :-)
I would have attached a patch, but I do not really have a clue about what these two functions do precisely. In fact, it might have been a bad thing to remove the function calls from "job-drive- detach. c". I cannot say, if this may result in loss of data (someone with some SCSI programming knowledge please explain). Plus, I imagine that for most users it may actually be useful that these functions are called. So it would not really be a patch.