What you are experiencing is the classic behavior of a standard, non-clustered filesystem (like ext4, Btrfs, or XFS) on shared raw block storage. Standard filesystems assume they have exclusive control over the drive—they cache disk structures in RAM, so when Machine B modifies or deletes partitions on the disk, Machine A's kernel has no idea the disk structure changed and corrupts its memory cache or throws read errors.
To stop two machines from accessing the same LUN at the same time, you have two primary ways to fix this: Target-Side Access Control (The Correct Fix) or Initiator/Cluster-Side Locking.
The safest and most reliable place to prevent concurrent access is at the iSCSI Target (the storage server or SAN exporting the LUN).
iSCSI uses IQNs (iSCSI Qualified Names) to identify every client machine (Initiator). You must configure your target storage to explicitly restrict the LUN mapping.
- Unmap the LUN from Machine B: Modify your LUN Masking/Target configuration so that the LUN is assigned only to Machine A's IQN (e.g.,
iqn.2006-04.com.example:machineA). - Use Exclusive LUN Masking: Ensure the target does not expose the LUN to a shared initiator group unless you specifically intend to use clustered software.
If you are using Linux (targetcli / LIO) as your iSCSI target:
- Navigate to your target's Node ACLs (
/iscsi/iqn.../tpg1/acls). - Ensure the target LUN is mapped under only one initiator IQN folder, rather than sharing the mapped LUN across multiple ACL entries.
If both machines must stay connected to the target for failover/High-Availability (HA) purposes, but only one machine should access it at a time, use SCSI-3 Persistent Reservations (PR).
With SCSI PR, Machine A places a write/exclusive reservation lock on the LUN. If Machine B attempts to read or modify partition tables while Machine A holds the reservation, the iSCSI target will reject Machine B's SCSI commands at the hardware layer with a Reservation Conflict error.
You can manage this from Linux using sg_persist:
# Register Machine A's key on the device
sudo sg_persist --out --register --param-rk=0 --param-sark=0x1111 /dev/sdb
# Reserve exclusive access for Machine A
sudo sg_persist --out --reserve --param-rk=0x1111 --prout-type=6 /dev/sdb
(When Machine B attempts to write to /dev/sdb, its commands will instantly fail without corrupting Machine A's view).
If your goal is to actually allow both machines to legitimately use the same LUN at the same time, a standard block device setup will always fail. You must use software built specifically for concurrent multi-host access:
- Clustered Logical Volume Manager (CLVM / LVM2 with
lvmlockd): Prevents one host from modifying or deleting logical volumes while another host is using them. - Cluster Filesystems: Filesystems like OCFS2 (Oracle Cluster File System v2) or GFS2 (Global File System 2) coordinate reads/writes across multiple servers over the network so partition/file metadata changes on Machine B are instantly synchronized to Machine A.
- High Availability (Pacemaker / Corosync): A cluster resource manager ensures the iSCSI LUN is only mounted on one machine at a time, handling automatic failover to Machine B only if Machine A crashes.
- If Machine B shouldn't see the disk at all: Change the LUN Masking / ACLs on your iSCSI Target array.
- If you want active-passive failover: Use SCSI-3 Persistent Reservations or a Pacemaker HA cluster.
- If both machines must read/write simultaneously: Format the LUN with a clustered filesystem like OCFS2 or GFS2.