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


sudo gdisk -l /dev/sdb


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  
  • What does this show? sudo gdisk -l /dev/sdb And more info: rodsbooks.com/gdisk/repairing.html Before doing anything use gdisk to backup the current partition table.
    – oldfred
    Commented Apr 12, 2014 at 20:55
  • I've updated my question to reflect the output from gdisk.
    – DustByte
    Commented Apr 12, 2014 at 21:04
  • If is is overlapping by that much then it must be somewhere in the middle of the drive. I do not know enough to really suggest a solution without having good backups just in case. But it does look like you may have room after partition for partition table. GPT (partitioning schema) on the hard disk drive is located in first 34 and last 33 sectors
    – oldfred
    Commented Apr 12, 2014 at 22:01

2 Answers 2


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.

  • I'm guessing that the OP is running 12.04. More recent versions of gparted properly show a pop up window with such errors offering the choice to fix it. Command line parted would also do this, even in 12.04.
    – psusi
    Commented Apr 13, 2014 at 2:33
  • Yes, I am running 12.04. Forgot to say that.
    – DustByte
    Commented Apr 14, 2014 at 2:34
  • I used gdisk as advised and it seems to have help. Thanks a lot for the help. I have no idea what could have caused this; I have a 64-bit computer and haven't used the drive with any other computer or operating system. I do have Windows 7 dual boot, but hardly ever boot into it and have never accessed this drive (partition is ext4 to begin with) from it.
    – DustByte
    Commented Apr 14, 2014 at 2:41
  • And yes, I am running Ubuntu 12.04, 64-bit.
    – DustByte
    Commented Apr 14, 2014 at 11:46
  • 1
    Some Windows drivers, even on 64-bit versions of Windows, have this bug. Accessing the filesystem is irrelevant; it's whether any disk utility (or conceivably even the OS itself) would have written the partition table. My hunch is you were bitten by a buggy driver.
    – Rod Smith
    Commented Apr 14, 2014 at 12:10

I cannot add a comment to Rod Smith's great answer, but I would like to add that I have done the procedure suggested and it's ok.

At the end gdisk said to me:

Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.

As with fdisk.

Using partprobe (included in the parted package) avoids the reboot. This way the added disk space appeared in cfdisk (that I have used to create the partition ;))

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .