Lock and Release Removable SCSI Media with sg_prevent

You will use sg_prevent to send a SCSI PREVENT ALLOW MEDIUM REMOVAL command to a removable drive, then verify and undo the state safely. The default invocation prevents removal; --allow releases an ordinary lock. Allow about ten minutes, plus time to identify the correct device. The command changes hardware state, so do not experiment against a drive that is being used by another process.

1. Check the installed utility and target

This guide uses the installed sg3-utils package. On this machine the package is version 1.46-3ubuntu4, while the executable reports utility version 1.12 20180627. The local manual page is labelled sg3_utils 1.35 from November 2012. That combination matters: use the output from your installed command when writing scripts, and do not assume that a newer package has identical diagnostics.

Find the executable and inspect the device names before sending anything. A SCSI generic path such as /dev/sg3 is only an example; replace it with the path belonging to your drive.

$ command -v sg_prevent
/usr/bin/sg_prevent
$ sg_prevent --version
sg_prevent: version: 1.12 20180627
$ ls -l /dev/sg3 /dev/sr0
crw-rw---- 1 root cdrom ... /dev/sg3
brw-rw---- 1 root cdrom ... /dev/sr0

Do not infer the target from a convenient number. Correlate it with your enclosure, tape drive or optical drive using your normal inventory tools. You need read and write access to the device, so the final command may require sudo. Elevated privileges change who can reach the device; they do not make an incorrectly chosen device safe.

2. Check whether the drive is in use

Before changing the lock state, stop any application that may be reading, writing or ejecting the medium. For an optical or removable block device, check mounts and open users:

$ findmnt --source /dev/sr0
$ sudo fuser -v /dev/sr0

An empty result is a useful checkpoint, not a guarantee that no other host or initiator is using the device. SCSI devices can be shared, and persistent prevent codes explicitly affect other initiators. If this is a shared enclosure or storage fabric, coordinate the change before continuing.

3. Prevent ordinary removal

Run the command with no option to send prevent code 1, the default. This normally makes the drive ignore the eject button and SCSI START STOP UNIT requests that would remove the medium.

$ sudo sg_prevent /dev/sg3
$ printf 'exit status: %s\n' "$?"
exit status: 0

The command prints no success message in its normal mode. Exit status 0 means the device accepted the command. It does not prove that every application will behave differently, or that the target path was the device you intended. Test the physical or application-level behaviour only after confirming the target.

Checkpoint: the medium should now resist ordinary removal. Keep the device path and time in your change record so the next operator can reverse the action.

4. Allow ordinary removal again

Use --allow when you have finished the protected operation. The manual defines it as equivalent to prevent code 2, allowing medium removal.

$ sudo sg_prevent --allow /dev/sg3
$ printf 'exit status: %s\n' "$?"
exit status: 0

This is the recovery command for the ordinary lock created in step 3. Run it before disconnecting the drive or handing the device to another operator. If the command fails, leave the medium in place and keep the device powered while you investigate the error. Check permissions, the device path and kernel or SCSI error messages; do not repeatedly send commands to an uncertain target.

5. Choose an explicit prevent code when scripting

The --prevent=PC option makes the requested state visible in a script. The local utility recognises these codes:

For an ordinary, reviewable lock, use code 1:

$ sudo sg_prevent --prevent=1 /dev/sg3
$ sudo sg_prevent --prevent=0 /dev/sg3

Do not combine --allow with --prevent=PC. Choose one form. The short forms are -a and -p PC; long options are clearer in operational scripts.

6. Treat persistent prevention as a shared-device change

Code 3 is not just a stronger local lock. It prevents other initiators or ports from allowing removal until the owner sends code 2, the logical unit is reset or powered off, or a relevant persistent-reservation operation clears it. That can disrupt another host's workflow and may leave an operator unable to eject media from a different path.

Use it only when you understand the device's initiators and have a recovery route. If you deliberately set it, record the owning path and reverse it from that same owner:

$ sudo sg_prevent --prevent=3 /dev/sg3
# Later, from the owning initiator:
$ sudo sg_prevent --prevent=2 /dev/sg3

A power cycle is not a convenient undo step: it can interrupt services and may not be acceptable for the enclosure. Prefer the documented owner recovery command.

7. Diagnose failures without guessing

If sg_prevent exits non-zero, the SCSI command was not confirmed as successful. Recheck that the device supports this command, that the medium and drive are ready, and that your account can open the device. Add --verbose for diagnostic output:

$ sudo sg_prevent --verbose --allow /dev/sg3

Some devices do not implement all prevent-code semantics in the same way. The manual notes that prevent-code definitions differ between disks, tapes and CD/DVD drives, and its detailed code descriptions are based on MMC-5. Treat a successful status as evidence that the target accepted the command, not as a universal guarantee about the front-panel button or every attached path.