On my EPS in EFI/refind/drivers_x64, I have a bunch of filesystem drivers; btrfs_x64.efi, ext2_x64.efi, ext4_x64.efi, hfs_x64.efi, iso9660_x64.efi, ntfs_x64.efi, and reiserfs_x64.efi.
I noticed that my Ubuntu 18 install automatically mounts my externally connected Mac backup drive, which is formatted using HFS of course. Though it doesn't mount the internal partition which contains MacOS, perhaps because of APFS?
MacOS however sees my external EXT4 drive as a Microsoft Basic Data drive, though I can mount it using ext4fuse.
I recall reading in the rEFInd Features page of the documentation that loading the drivers during the boot stage can enable facilitate reading foreign filesystems. Is there a way of tweaking this to enable MacOS to read EXT4 without having to use a manual mount (ext4fuse) command?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
MacOS relies on its own drivers, not EFI drivers, to read filesystems. Thus, rEFInd's EFI drivers will do you no good in macOS. There are native macOS drivers to read some Linux filesystems, especially the ext2/3/4 family. I've dabbled with them from time to time, but I haven't used them in ages, so I can't provide pointers to specific implementations that are likely to work well. You might try asking on a Linux or Mac forum for advice on this topic.
That said, my own approach to macOS/Linux data sharing is to use either FAT (especially if Windows is also in the mix) or HFS+. Linux includes an HFS+ driver that's pretty reliable, with the caveat that it defaults to read-only mode if the filesystem includes a journal. The workaround is simple: Use a non-journaled filesystem for data exchange.
Note that mounting any OS's root filesystem in another OS is risky. Non-native filesystem drivers tend not to be as reliable as native drivers, so there's a chance that a bug will cause filesystem damage. In some cases, security controls and other features may vary, which can create security problems; however, macOS and Linux share the same basic Unix filesystem ownership and permissions features, so this isn't as much of an issue for them as it is for either of them and Windows. In any event, the risk of non-native filesystems is a good reason to use a dedicated data-exchange partition rather than giving either OS full read/write access to the other OS's main partition.
As to macOS seeing your Linux partition as "Microsoft Basic Data," chances are the Linux partition's type code is set incorrectly. This issue is covered on a rather elderly (2012) Web page I wrote:
AFAIK, all major Linux distributions now create partitions with the correct Linux-native type code; however, depending on how you set the partition up, you may have converted it from a Windows partition and not adjusted the type code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the details and summary of your experience.
I created the Linux partition using a live USB with CloneZilla installe on it, which could be the source of the problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Clonezilla might still be using the Windows filesystem type code; or you might have been using an old live USB that predated that type code's widespread use. (Prior to adoption of that type code, Linux partitioning tools used the Windows type code even for Linux-native filesystems.) In any event, the fix is fairly easy with gdisk.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On my EPS in EFI/refind/drivers_x64, I have a bunch of filesystem drivers;
btrfs_x64.efi,ext2_x64.efi,ext4_x64.efi,hfs_x64.efi,iso9660_x64.efi,ntfs_x64.efi, andreiserfs_x64.efi.I noticed that my Ubuntu 18 install automatically mounts my externally connected Mac backup drive, which is formatted using HFS of course. Though it doesn't mount the internal partition which contains MacOS, perhaps because of APFS?
MacOS however sees my external EXT4 drive as a
Microsoft Basic Datadrive, though I can mount it usingext4fuse.I recall reading in the
rEFInd Featurespage of the documentation that loading the drivers during the boot stage can enable facilitate reading foreign filesystems. Is there a way of tweaking this to enable MacOS to read EXT4 without having to use a manual mount (ext4fuse) command?MacOS relies on its own drivers, not EFI drivers, to read filesystems. Thus, rEFInd's EFI drivers will do you no good in macOS. There are native macOS drivers to read some Linux filesystems, especially the ext2/3/4 family. I've dabbled with them from time to time, but I haven't used them in ages, so I can't provide pointers to specific implementations that are likely to work well. You might try asking on a Linux or Mac forum for advice on this topic.
That said, my own approach to macOS/Linux data sharing is to use either FAT (especially if Windows is also in the mix) or HFS+. Linux includes an HFS+ driver that's pretty reliable, with the caveat that it defaults to read-only mode if the filesystem includes a journal. The workaround is simple: Use a non-journaled filesystem for data exchange.
Note that mounting any OS's root filesystem in another OS is risky. Non-native filesystem drivers tend not to be as reliable as native drivers, so there's a chance that a bug will cause filesystem damage. In some cases, security controls and other features may vary, which can create security problems; however, macOS and Linux share the same basic Unix filesystem ownership and permissions features, so this isn't as much of an issue for them as it is for either of them and Windows. In any event, the risk of non-native filesystems is a good reason to use a dedicated data-exchange partition rather than giving either OS full read/write access to the other OS's main partition.
As to macOS seeing your Linux partition as "Microsoft Basic Data," chances are the Linux partition's type code is set incorrectly. This issue is covered on a rather elderly (2012) Web page I wrote:
http://www.rodsbooks.com/linux-fs-code/index.html
AFAIK, all major Linux distributions now create partitions with the correct Linux-native type code; however, depending on how you set the partition up, you may have converted it from a Windows partition and not adjusted the type code.
Thanks for the details and summary of your experience.
I created the Linux partition using a live USB with CloneZilla installe on it, which could be the source of the problem.
Clonezilla might still be using the Windows filesystem type code; or you might have been using an old live USB that predated that type code's widespread use. (Prior to adoption of that type code, Linux partitioning tools used the Windows type code even for Linux-native filesystems.) In any event, the fix is fairly easy with
gdisk.