Is there something I can do to avoid losing the data?
Yes. You can access the data after mounting like this:
mount -o ro,offset=((256*4096)) /dev/sda /path/to/mountpoint
ro just in case; if files look right, you can remount with
This answer explains what happened:
The enclosure exposes the drive to the computer as an Advanced Format 4Kn device, allowing the use of MBR for compatibility with Windows XP systems. When the drive is removed from the enclosure, the change in logical sector format results in an invalid partition table.
Your drive now reports the capacity of 7814037168 logical sectors of 512 bytes each. When in the enclosure, it was 976754646 logical sectors of 4096 bytes each.
The current partition entry was valid in terms of 4096-byte sectors. It says the partition spans from the sector number 256 to 976754645, which was the last sector (keep in mind sectors are numbered from 0; N sectors take numbers from 0 to N-1).
And I can tell this is a MBR (DOS) partition table. GPT needs few sectors at the end of the device for its backup table. You had no unused sectors there, so MBR
But now any tool sees the device with 512-byte logical sectors. The partition table again says the only partition spans from the sector number 256 to 976754645 and this is wrong.
The proper values now are:
- 256*8 = 2048
- (976754645+1)*8-1 = 7814037167
Note the latter is the very last sector (your
fdisk says there are 7814037168 sectors).
You cannot fix the MBR partition table because now it should take too many sectors. Compare what Wiki says:
Since block addresses and sizes are stored in the partition table of an MBR using 32 bits, the maximal size, as well as the highest start address, of a partition using drives that have 512-byte sectors (actual or emulated) cannot exceed 2 TiB−512 bytes (2,199,023,255,040 bytes or 4,294,967,295 sectors × 512 bytes per sector). Alleviating this capacity limitation was one of the prime motivations for the development of the GPT.
It would not be easy to fully convert to GPT, because you have no room for the secondary (backup) partition table at the end of the device. MBR lives at the beginning of the device only; GPT requires room at the beginning and at the end.
Still you can tell
mount at what offset the filesystem starts, this is what my command does. The offset is 256*4096 bytes (or 2048*512 bytes, it's the same number). The command given above uses the shell to calculate the offset. The offset counts from the beginning of the entire device, therefore the command uses
My tests indicate ext4 doesn't rely on the logical sector size of the underlying device, so you should be OK mounting this way.
Now it should be clear that "shipping it back, starting over, and shipping it back once again" wouldn't help. The enclosure would translate the logical sector size again and you would be surprised the filesystem mounts. On the other hand if you clear the disk now, create a GPT partition table and a filesystem anew, and then ship the drive, it won't mount in the data centre, if they connect it via the same enclosure.
If you need to ship the disk back and forth, consider a superfloppy, i.e. a filesystem on the entire device, without any partition table (e.g.
mkfs.ext4 /dev/sda). You mount such filesystem with
mount /dev/sda /path/to/mountpoint regardless of whether there is an enclosure that interferes or not.