Ubuntu – GParted claims whole hard drive is unallocated and gives warning about GPT table

gpartedgptunallocated

For months I have been happily using my 3TB hard drive, and I still do. Today I discovered that GParted shows the whole drive (/dev/sdb) as being unallocated. The drive works fine though. Clicking for more information in GParted gives me the following warning text:

The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the backup to the end (and removing the old backup)?

Not all of the space available to /dev/sdb appears to be used, you can fix the GPT to use all of the space (an extra 4294967296 blocks) or continue with the current setting?

Unable to satisfy all constraints on the partition.

On the drive sits one single ext4 partition, filling up presumably the whole drive. I was the one formatting it a long time ago, using GParted, if I remember correctly. I can't remember details of creating a GPT table. The drive is used only for data and does not contain system files or anything. I do mount it automatically with fstab.

In GParted I only have the option of clicking Close. See attached screenshots. I'm not happy to have GParted telling me the drive is unallocated space. What can/should I do to fix this?

The problem I have with experimenting is that I have no other drive that can accommodate my 3TB worth of data, so making backups is an issue. (Before you tell me that I should always backup data, most of the contents on this 3TB drive is my incremental backups from other drives, so I prefer not to lose it.)

enter image description here
enter image description here

Running

sudo gdisk -l /dev/sdb

gives

GPT fdisk (gdisk) version 0.8.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Warning! Secondary partition table overlaps the last partition by
4294966385 blocks!
Try reducing the partition table size by 17179865540 entries.
(Use the 's' item on the experts' menu.)
Disk /dev/sdb: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 04F5DE37-A757-414B-A3E0-F845BD54B767
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1565565838
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      5860532223   2.7 TiB     0700

Best Answer

It looks like something has moved the GPT's backup partition table to roughly the 700GiB mark on the disk. This could cause data corruption (although probably of only one or two files), so you should move it back where it belongs. You can do this in gdisk by using the e option on the gdisk experts' menu (that is, launch gdisk, then type x, then type e, then type w to save your changes). GParted and parted should also offer options to fix this problem, but I'm less familiar with them and don't know what, if any, caveats might apply. (I'm gdisk's author, so I'm very familiar with what it does!)

Chances are this damage was caused by some partitioning tool that was run on the disk from an OS or via a driver that has a built-in 32-bit limitation. Since the disk has more than 2^32 sectors, the result is something like a car's odometer rolling over -- instead of accessing out to the ~2.7TiB mark, the software wrote the backup partition table data at ~0.7TiB (~700GiB). This type of problem is most common with Windows drivers that are older than a year or two old and with external USB enclosures for hard disks.

Related Question