SSD exfat formatted on EOS works fine on EOS but not accessible from Windows 10

General system Newbie
1

Hello friends.

This thread contains a problem related to Windows 10, so I understand if you can’t help me with this!

I have formatted an SSD and HDD in EOS KDE with KDE Partition Manager with the exfat format, so that it is compatible with EOS and Windows 10.

Both were formatted with exfat and work fine on EOS, I can access both and create files etc.

But if I access from Windows 10, I can only access HDD, and can’t access SSD, it says no access, or disk access denied (can’t remember right now).

Also, in EOS I can see the 2 new names of the 2 drives correctly, but in Windows 10 I can only see the new name of the HDD, but I don’t see the new name of the SSD, which I can’t access.

Is it possible that the solution to this is in EOS, or is it a Windows 10 problem?

Thanks in advance and sorry if I shouldn’t be asking windows related stuff!

2

Can you share the output of sudo parted -l and lsblk -o name,type,fstype,size,mountpoint

3

Sure friend!

The sdb (I renamed it KINGSTON), is the SSD that cannot be accessed from Windows 10.

The sdc (I renamed it as MAXTOR), is the HDD that can be accessed correctly from EOS and Windows10.

I chose exfat because I was told and read that it is more compatible with Linux than ntfs, although I don’t know whether to stay with exfat or ntfs, I don’t know which one will give less compatibility problems to share files between each other.

[mylinux@mylinux ~]$ sudo parted -l
Model: ATA CT240BX500SSD1 (scsi)
Disk /dev/sda: 240GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  53,5MB  52,4MB  primary  ntfs         boot
 2      53,5MB  128GB   128GB   primary  ntfs
 3      128GB   129GB   561MB   primary  ntfs         msftres
 4      129GB   240GB   111GB   primary  ext4


Model: ATA KINGSTON SA400S3 (scsi)
Disk /dev/sdb: 240GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  240GB  240GB  primary


Model: ATA MAXTOR STM325031 (scsi)
Disk /dev/sdc: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  250GB  250GB  primary

[mylinux@mylinux ~]$ lsblk -o name,type,fstype,size,mountpoint
NAME   TYPE FSTYPE   SIZE MOUNTPOINT
sda    disk        223,6G 
├─sda1 part ntfs      50M 
├─sda2 part ntfs   119,4G 
├─sda3 part ntfs     535M 
└─sda4 part ext4   103,6G /
sdb    disk        223,6G 
└─sdb1 part exfat  223,6G /run/media/mylinux/KINGSTON
sdc    disk        232,9G 
└─sdc1 part exfat  232,9G /run/media/mylinux/MAXTOR
4

For me, they are both about the same with compatibility with Linux. I would probably use ntfs for an internal drive for sharing with Windows although either should work fine. Exfat is compatible with almost anything(gaming consoles, cameras, computers, etc, etc) so it is great for removable drives.

Whenever possible, I would recommend using a GPT partition table.

I am not sure why Windows can’t read that partition on the SSD. If there is no data on it I would try throwing a GPT partition table on it and reformatting it.

1 Like
5

It worked, solved!

I deleted the sdb1 partition, then I created a new partition table with GPT, and I formatted the free space with NTFS, I applied the changes, and this time 2 partitions were created (I don’t know why), but it worked, and now I can access from EOS and W10!

Although I don’t understand how my motherboard recognizes GPT partitions, if my pc only has BIOS and no UEFI/EFI, my pc is supposed to be unable to access GPT tables, or so I think.

Thanks again Mr. Dalto!

1 Like
6

As far as I know, GPT does not need UEFI system, it should work on legacy BIOS too.
I actually have an old machine without UEFI for testing this, but the machine is not with me for a few weeks unfortunately…

1 Like
7

Since you are not booting off those devices, your BIOS/firmware doesn’t need to be able to understand the partition table on them.

Although, as pointed out above, not supporting UEFI and not being able to read GPT aren’t the same thing.

1 Like
8

But, the boot disk must be MBR, and the other secondary disks can be GPT (as in my case), right?

Oh I see, this is really interesting.

So if I understood correctly, this would only affect the boot hard drive (sda), which is where I have “/” EOS, correct?

9

no the boot device does not need to be MBR.

1 Like
10

If your system only supports Bios/Legacy/MBR boot mode then normally the boot disk is also MBR (msdos partition table).

However this doesn’t have to be so. In cases where the firmware supports booting in Bios/Lgacy off of a GPT disk, an especial Bios Boot partition is required to for the Grub to embed its core.img

For more see:
https://wiki.archlinux.org/title/GRUB#GUID_Partition_Table_(GPT)_specific_instructions
https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-

2 Likes
11

It depends on your specific hardware. There is no absolute answer to the question generally.

However, it would probably be easier/safer to use MBR for your boot disk.

2 Likes
12

You guys were right, I formatted with a new GPT partition table on my SSD with EOS and it worked!

Disklabel type: gpt
2 Likes
13

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.