2

I have a 4TB hard drive /dev/sdb, which has a formatted NTFS filesystem occupying the whole drive. It apparently has no partition table of any kind, or if it does, it is out of date or corrupted.

fdisk -l shows this:

Disk /dev/sdb: 4000.8 GB, 4000787030016 bytes
255 heads, 63 sectors/track, 486401 cylinders, total 7814037168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x2052474d

This doesn't look like a partition table
Probably you selected the wrong device.

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   ?     6579571  1924427647   958924038+  70  DiskSecure Multi-Boot
Partition 1 does not start on physical sector boundary.
/dev/sdb2   ?  1953251627  3771827541   909287957+  43  Unknown
Partition 2 does not start on physical sector boundary.
/dev/sdb3   ?   225735265   225735274           5   72  Unknown
Partition 3 does not start on physical sector boundary.
/dev/sdb4      2642411520  2642463409       25945    0  Empty

Partition table entries are not in disk order

gdisk -l says only an MBR partition table is present.

The drive works fine when running under Linux; I can mount /dev/sdb without issues. But I want to load the drive using an hard drive enclosure on a windows machine so that I can run chkdsk on it. Windows however sees this MBR as shown in fdisk, and shows 4 partitions, none of which are usable (none are even marked as NTFS).

Is it possible to simply write a partition table to this drive without changing the contents of the NTFS filesystem, so that Windows 7 can access it as a single partition occupying the whole drive? If so, how?

Edit: If it's not possible to simply write a partition table, is there some non-destructive method to accomplish the same goal of using the drive under Windows, perhaps by downsizing the file system by a few kilobytes and then writing a partition table? (ie, with gparted).

7
  • You have cloned the drive I presume?
    – Ramhound
    Commented Apr 16, 2017 at 5:41
  • @Ramhound - No I just removed it from the linux machine and put it in an enclosure to use on a windows machine.
    – jtbr
    Commented Apr 16, 2017 at 5:48
  • 1
  • The fdisk output looks exactly like the answer to Windows does not mount USB NTFS superfloppy as suggested by @KamilMaciorowski , same names, start, end, blocks, Id... would be a duplicate except it doesn't create a new MBR/GPT - Kamil it looks like there might be room to write a regular MBR over the superflopy's VBR (both 512 bytes), is there, and it wouldn't harm the filesystem?
    – Xen2050
    Commented Apr 16, 2017 at 6:27
  • @Xen2050 I think it would harm the filesystem. As far as I know NTFS stores some metadata in VBR. You could change the partition table fragment only and it would interfere with NTFS bootstrap code (and I guess one could live with that because there are text strings there, check my answer to the linked question). The problem is the disk here is 4 TB and it probably needs GPT; and GPT requires (I think) one full sector as a legacy MBR and 33*512 bytes just after, and also a similar space at the end of the disk. Commented Apr 16, 2017 at 6:41

2 Answers 2

4

In this particular situation you can't write MBR to this drive because you will loose all the data on it. The best way would be to copy all the data elsewhere and then partition the drive on Windows with diskmgmt.msc.

3
  • +1. I can think of a solution (untested) that uses ntfsresize, ddrescue --reverse and e.g. gdisk. Before performing any such a trick one is advised to backup the data. Then, having my backup anyway, I would choose your solution which is so much simpler. Commented Apr 16, 2017 at 6:07
  • There is possibility that GParted would make what you want, but I am not sure, you would have to try. Moving partition 1MB ahead at its beginning and using testdisk to write MBR should be good enough.
    – pbies
    Commented Apr 16, 2017 at 6:44
  • I do have the data backed up various places, but not cloned, and I don't have a spare 4TB drive lying around to clone it (plus that's a lot of data to copy). The reason I'm trying to do this in the first place is because I'm concerned about filesystem corruption, and so copying might not work anyway. Given the risks then, I guess I'll just leave things be. It seems the lesson is to always, always partition, just in case.
    – jtbr
    Commented Apr 16, 2017 at 20:07
0

In principle, you could do something like this:

  1. Use ntfsresize to shrink the existing filesystem by a small amount (in theory, 2081 sectors should be enough, but I'd do at least 2 MiB just to be safe).
  2. Shift the filesystem "into" the disk by some fixed amount. 1 MiB should be optimal. This is the tricky part, since you'd be reading from and writing to the same device, and it's imperative that this be done in a way that does not overwrite data before it's copied. In other words, you'd have to copy starting from the end of the filesystem, rather than the more common approach of doing it from the start. Offhand, I don't know of a tool that will do this, aside from partition-resizing tools like GParted -- and AFAIK, those tools all require that a partition table be present. A script that uses dd to do this would be possible, and not very hard to write, but it would require careful testing.
  3. Create a partition table on the disk along with a single partition that begins at the new start point for the filesystem and that ends where the filesystem ends.

Unless you can find a tool that will do step #2 with something resembling safety, copying the data off the disk, creating partitions, and then restoring the data, as pbies suggests, is likely to be the best solution. This may even be faster than trying to shift the whole filesystem, too, particularly if the filesystem is mostly empty. Even if you find a tool to do step #2 (or the whole procedure) in one go, I would strongly recommend creating a backup before proceeding, since the procedure I've outlined here is quite dangerous.

As a side comment, it sounds like you've been using this NTFS disk exclusively in Linux. You've discovered one compelling reason to not do this: Linux's NTFS maintenance tools are rudimentary at best. If you plan to access the data exclusively from Linux, I recommend you back up, create partition(s), create Linux-native filesystem(s), and restore the data to the new Linux-native filesystem(s). This will give you a better ability to repair filesystem damage from within Linux, without involving Windows.

3
  • Thanks. The reason I'm using NTFS is it's the least common denominator between Linux and MacOS, which I dual boot. The perils of working cross-platform...
    – jtbr
    Commented Apr 17, 2017 at 21:43
  • For a Linux/macOS dual-boot, I recommend HFS+. That's the Mac's native filesystem, and Linux provides much better HFS+ support than NTFS support. The one complication of this approach over NTFS is permissions, which is, ironically, simpler with NTFS because it's less compatible with both the OSes you're using. See this Askubuntu question and my answer to it for details on how to get it to work.
    – Rod Smith
    Commented Apr 18, 2017 at 13:13
  • I finally got a replacement drive and wanted to see if I could get this to work on the old one (my plan was to use ddrescue --reverse for step 2). Unfortunately it failed in step 1 because ntfsresize found file consistency problems that ntfsfix cannot fix (it says to use chkdisk /f, which is the whole reason I wanted to move it to a partition in the first place. Lesson learned. Use partitions, not raw drives, and avoid NTFS if possible.
    – jtbr
    Commented Nov 26, 2017 at 3:21

You must log in to answer this question.

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