Drives partitioned via server USB caddy not recognized by workstation eSATA (GPT PMBR size mismatch)
We use a USB 3.0 drive caddy (Sabrent EC-DFFN) connected to our Ubuntu 20.04 server for backups. And we are using several make/model 6TB spin drives in daily rotation (one drive per day). Each drive was partitioned on the server (via the USB 3.0 caddy) with fdisk. A GPT partition was created and then a single EXT4 file system was created. The server is able to mount and use these drives with no problems.
I was asked to restore a file for review - but not to restore it to the server. So I tried to mount the drive via my eSATA on my Ubuntu 20.04 workstation but the drive won't mount. I'm getting a GPT PMBR size mismatch.
Running fdisk on the workstation shows:
GPT PMBR size mismatch (1465130645 != 11721045167) will be corrected by write.
Disk /dev/sde: 5.47 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: ST6000NM0044
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sde1 1 4294967295 4294967295 2T ee GPT
Partition 1 does not start on physical sector boundary.Running parted on the workstation shows:
Error: /dev/sde: unrecognised disk label
Model: ATA ST6000NM0044 (scsi)
Disk /dev/sde: 6001GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags:Running fdisk on the server shows:
Disk /dev/sdb: 5.47 TiB, 6001175126016 bytes, 1465130646 sectors Disk model: Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 33550336 bytes Disklabel type: gpt Disk identifier: B910325B-5CFF-6C46-806A-E95EA72EBFC1 Device Start End Sectors Size Type /dev/sdb1 8191 1465130640 1465122450 5.5T Linux filesystemRunning parted on the server shows:
Model: SABRENT (scsi) Disk /dev/sdb: 6001GB Sector size (logical/physical): 4096B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 33.6MB 6001GB 6001GB ext4Every drive created on the server reports the same GPT PMBR size mismatch issue on my workstation but the server can mount, read, write, in other words, use these drives with no problem.
What am I missing? Is this a eSATA limitation?
EDIT 2021-04-22
Per @oldfred, I checked the fdisk version on both workstation and server and both both are running version 2.34.
Running gdisk on the workstation shows:
GPT fdisk (gdisk) version 1.0.5 Partition table scan: MBR: protective BSD: not present APM: not present GPT: not present Creating new GPT entries in memory. Disk /dev/sde: 11721045168 sectors, 5.5 TiB Model: ST6000NM0044 Sector size (logical/physical): 512/4096 bytes Disk identifier (GUID): FDBF8804-11D0-44B5-9957-03F5F2D68131 Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 11721045134 Partitions will be aligned on 2048-sector boundaries Total free space is 11721045101 sectors (5.5 TiB) Number Start (sector) End (sector) Size Code NameRunning gdisk on the server shows:
GPT fdisk (gdisk) version 1.0.5 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sdb: 1465130646 sectors, 5.5 TiB Model: Sector size (logical/physical): 4096/4096 bytes Disk identifier (GUID): B910325B-5CFF-6C46-806A-E95EA72EBFC1 Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 5 First usable sector is 8191, last usable sector is 1465130640 Partitions will be aligned on 8-sector boundaries Total free space is 0 sectors (0 bytes) Number Start (sector) End (sector) Size Code Name 1 8191 1465130640 5.5 TiB 8300 1 Answer
I’ve had a similar issue in the past. The solution was to run fdisk on it and use w to save the existing partition table without any changes.
GPT disks come with a "Protective MBR" (PMBR) which contains a dummy partition that covers as much of the entire disk as is possible, which can result in the size mismatch issue you are seeing.
This has no effect on data stored on the disk; it is there only to guard against old MBR-only disk partitioning tools.
Hope this helps 👍🏻
