The comment answerers are not reading the output in your question. The output tells us this:
GPT PMBR size mismatch (732566645 != 5860533167) will be corrected by w(rite).
fdisk is telling you that you have an EFI partition table with a so-called "protective" old-style MBR partition record. But the protective partition record does not correctly protect the contents of your disc, because it ends way before the actual end of the disc, leaving a couple of TiB of free space unaccounted for.
fdisk says that it will fix this for you. Do not attempt to use
fdisk to do so.
fdisk is wrong.
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdb1 1 732566645 732566645 349.3G ee GPT So
fdisk has decided to not show you the EFI partition table at all. It is showing you the "protective" old-style MBR partition table instead, as if that were how you had partitioned your disc. That contains one entry, which is really (since it is type
ee) a dummy entry that is supposed to encompass the entire disc, including the EFI partition table. But it is only 732566645 sectors long, which is roughly 349GiB, not 2.7TiB.
This is one of several reasons why it is wrong to run
fsck against this. It is not a disc volume containing a formatted filesystem. It is a dummy old-style partition that is supposed to span the entire disc.
Partition 1 does not start on physical sector boundary. This is a red herring. Your dummy protective partition is supposed to begin at sector 1. Sector 1 is where the EFI partition table begins. It is the alignment of the real partitions, recorded in the new EFI partition table that
fdisk isn't reading, that matters, and that for performance reasons. You should be able to mount misaligned volumes. But you haven't even got as far as using the right partition table, so whether this is even a problem in the first place is unknown.
However, it is likely that it is not. Alignment is likely entirely a red herring here. Because what you are experiencing is well known, and is something else.
$ sudo parted /dev/sdb print
Error: /dev/sdb: unrecognised disk label
parted is failing to read your EFI partition table, too. Unlike
fdisk, it isn't falling back to treating your disc as being partitioned in the old style, and reporting one big dummy partition. It is failing outright.
size: 2794GiB (3TB)
description: EFI GPT partition
physical id: 1
bus info: scsi@1:0.0.0,1
lshw is seeing a 3TB (2.7TiB) disc. It is also seeing the EFI partition table. But your EFI partition table claims that this is a 349GiB disc.
Why did 2.7TiB become 349GiB?
Well, notice what you get when you multiply 349GiB by 8.
When it is in your USB disc enclosure, the system thinks that your disc has 4KiB sectors, and everything has been accessing it using that as the sector size. In the USB enclosure, the rest of the system sees your disc with its native, true, sector size.
Moreover, with 4KiB sectors 732566645 sectors really does encompass the entire 2.7TiB of your disc, and both the old-style protective partition and the actual EFI partition table have the right numbers.
Outwith your USB disc enclosure, your disc is being read in "512e" compatibility mode, where most of the system pretends that your disc has 0.5KiB sectors. (There is a more complex explanation to do with a second inverse transformation undoing the first when the USB enclosure is involved, but I am glossing over that here, as it is beyond the scope of this answer.) The partition start and size numbers in your partition tables, and indeed anything else that points to a logical block address on your disc, are all wrong.
4KiB is 8 times 0.5KiB.
Downgrading from native 4KiB sector sizes to "512e" is possible, but it is not for the fainthearted. I recommend as the far simpler course of action that you put the disc back into the enclosure to read it, where it will be seen with its true 4KiB sector size by the rest of the system and the numbers will come out right.