1

I'm having a hard time getting a 4TB external USB drive to work on both LINUX (Ubuntu 14.04) as well as on my Mac OSX.

The problems seem to be with inconsistent ability to read/write the USB drive.

In the end, I just erased the drive and formatted it to a so called "FAT" (MS-DOS) format.

This seems to have "fixed" my issue, in that I can now read/write with it on both LINUX and Max OSX, however it's gone from 4TB to 1.74 TB now.

I am wondering why that is, and what can be done to remedy it? Ultimately however, I would like the drive to be able to be used on both LINUX and Max OSX.

EDIT:

In the comments, the suggestions thus far say that I should try to format to exfat, or to GPT. However, as seen from this screen shot of gparted, I do not have the GPT option, and the exfat option seems to be greyed out. Not sure how to proceed... thanks.

enter image description here

13
  • 1
    use exfat, or install ext4 driver on osx. Jan 11 '17 at 8:10
  • 1
    How is the disk partitioned? The old MBR partitioning scheme has a 2 TB limit. For bigger disks you should use GPT. Jan 11 '17 at 8:16
  • @JohanMyréen Thanks, so then my questions are, 1) What tool should I use to format with "GPT", and 2) would this allow me to use it seamlessly across LINUX and Mac OSX? Thanks!
    – Spacey
    Jan 11 '17 at 17:04
  • @JohanMyréen Also, I do not believe I have any partitions on it, just one partition.
    – Spacey
    Jan 11 '17 at 17:13
  • @IporSircer I have edited the question.
    – Spacey
    Jan 11 '17 at 17:43
2

exfat

Your exfat option is almost certainly grayed out because you don't have the required packages installed to use exfat:

apt-get update && apt-get install exfat-utils exfat-fuse

Then check your disk tool again and you should see the option active. Using fat on a 4 tB disk results in massive sectors, and a huge waste of space, particularly for smaller files, plus as you discovered, it only sees part of the disk space. Using mbr apparently restricts you to 2 tB disk size.

As a rough rule of thumb, I'd say maybe a usb drive < 256 mB, FAT is ok, anything bigger, just use exfat, that's what the new stuff out there uses, mac/windows/ and gnu/linux after installing the packages will support it.

I don't trust the drivers out there for windows and ext2, I'd rather use something that is pretty solidly supported on the native level for file system access, with all respect to the people who have worked for years to get ext support into windows as a 3rd party addon.

Basically once SSD/usb/flash drive capacity went past a few hundred mB, fat became more or less obsolete, and was replaced by exfat, or vfat

https://en.wikipedia.org/wiki/ExFAT http://wikidiff.com/vfat/exfat

is that exfat is (computing) extended fat (extended file allocation table, extended file allocation table, extended file allocation table) ; 64-bit allocation table version of fat while vfat is (computing) a virtual file allocation table; a version of file allocation table that supports an extended set of features such as support for long filenames that the original fat file system did not have.

As an acronym exfat is (computing) extended fat (extended file allocation table, extended file allocation table, extended file allocation table) ; 64-bit allocation table version of fat.

On a technical level, obviously it would have been preferable if device vendors had switched to ext2, which is heavily tested, robust, and pretty much rock solid, and not bound by proprietary code, but that didn't happen, so we have to deal with it by using exfat, but my experience so far with nix exfat tools is it works fine, no issues. And the device remains pretty much universally readable across devices (think, microsd chip in your phone). One main reason if I remember right for ext2 not being adopted was due to the GPL requirements of using that code, vendors shied away from the question and decided to adopt the 'safe' choice of using proprietary licensed microsoft code. Which is unfortunate, but that was the choice made.

FAT itself is not a valid option with today's large storage devices since the size of each chunk gets so big it's just not very efficient.

If I remember right, fat16 could address 2^16 addresses, fat 2^32, so as you can see, the bigger the disk sizes, the larger each addressed space became, aside also from file size limits etc. There were also some file name length limits etc that are quite real and limiting.

gpart

I'm a little rusty on gpt, however, to convert a disk to gpt requires if I remember right resetting the lowest disk level to use gpt, not mbr, which then tells the whole disk that gpt is the basic schema, not mbr. Note that this type of switch is risky in terms of data loss.

apt-cache show gparted

.....
Depends: libatkmm-1.6-1v5 (>= 2.24.0), libc6 (>= 2.4), libgcc1 (>= 1:4.2), libglib2.0-0 (>= 2.16.0), libglibmm-2.4-1v5 (>= 2.50.0), libgtk2.0-0 (>= 2.14.0), libgtkmm-2.4-1v5 (>= 1:2.24.0), libpangomm-1.4-1v5 (>= 2.40.0), libparted-fs-resize0 (>= 3.1), libparted2 (>= 3.1), libsigc++-2.0-0v5 (>= 2.8.0), libstdc++6 (>= 5.2), libuuid1 (>= 2.16)
Suggests: xfsprogs, reiserfsprogs, reiser4progs, jfsutils, ntfs-3g, dosfstools, mtools, yelp, kpartx, dmraid, dmsetup, gpart
.....

So here you'd want to ensure that gpart as well as gdisk is installed, for example, but note, if I remember gparted right, you won't see gpt as an option if the disk has already been set to use mbr type, you have to go in an redo it totally. Assuming this is correct re mbr vs gpt size limits (I"ve never run > 1 tB disks personally so I'm a touch behind on this)

https://www.howtogeek.com/193669/whats-the-difference-between-gpt-and-mbr-when-partitioning-a-drive/

MBR does have its limitations. For starters, MBR only works with disks up to 2 TB in size. MBR also only supports up to four primary partitions—if you want more, you have to make one of your primary partitions an “extended partition” and create logical partitions inside it. This is a silly little hack and shouldn’t be necessary.

Conclusion:

You have to fully redo the disk, set it to gpt, which this fairly good explanation walks you through. Note that I never used gparted to work with gpt, I always used gdisk because honestly I found it easier to do.

https://askubuntu.com/questions/84501/how-can-i-change-convert-a-ubuntu-mbr-drive-to-a-gpt-and-make-ubuntu-boot-from

This one is also nicely explained: https://askubuntu.com/questions/672436/how-can-i-change-a-drives-partition-table-from-mbr-to-gpt-without-losing-an-ntf

Again, it's recommended to use gdisk directly to do this.

In general, it's far easier to just set the disk to gpt FIRST, then partition, then format to file system type (exfat maybe in your case), otherwise you have to undo stuff and redo it, which always entails some risk in terms of data loss.

0

I am facing a similar problem of Linux to Mac compatibiity and vice versa. I chose to format to the large drive to Linux ext2/3/or 4 (you choose; I chose 2) and then added Paragon ExtFS software to my Mac. As for the 4TB issue, I stayed with 2TB to avoid it. Good luck.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.