First, HFS+ is a non-native filesystem from a Linux perspective, so some amount of oddity with it is expected. That said, completely unmounting the filesystem when deleting files goes beyond the sort of quirks I'd expect, but it could be that this is at least part of what's going on. If so, and if none of the below suggestions help, switching to FAT may do the trick. Although FAT is also non-native, its drivers (in both Linux and macOS) are mature enough that it's unlikely to cause such problems. OTOH, FAT is also very limited compared to HFS+, so it may not be adequate (such as if you need to store large files).
In any event, a few specific issues may be at work here:
- Journaling -- By default, macOS creates HFS+ volumes with journaling active. In fact, this default cannot be disabled in recent versions of macOS when using the GUI Disk Utility. Journaling, however, is poorly supported in Linux's HFS+ drivers. Thus, for a shared data partition, it's best to disable journaling. Unfortunately, I don't know how to do this on an existing volume; but maybe a Web search will turn something up. If not, or if you don't mind doing a backup-reformat-restore juggle, you can do that. When you do, I'd suggest using
mkfs.hfsplus in Linux to create the new filesystem. To create a non-journaled filesystem, you would omit the -J option. (Type man mkfs.hfsplus to learn more about this command.) If the command is not installed, you might need to install the hfsprogs package. There's a command-line way to do this in macOS, too; I believe the command is newfs or something similar. I don't recall the details, though.
- Coordinated user IDs -- By default, Ubuntu's first user ID (UID) is 1000, whereas it's 501 in macOS. Thus, when you try to share files on an HFS+ partition across these OSes, the files will appear to be owned by different users in each OS. Although it's possible to set permissions loosely or make heavy use of
sudo to enable file-sharing to work, a better solution is to coordinate the UID values across the two installations. My answer to this question on AskUbuntu describes how to do this in Ubuntu, and provides pointers to other sites that describe how to do it in macOS. (Making the change in macOS is preferable, but the process is more tedious in macOS.) In suggesting making this change, my hypothesis is that you may be running into permissions problems and that these problems are interacting with filesystem bugs that are causing the filesystem to be unmounted.
- Filesystem errors -- If the filesystem has been damaged, it may be causing the kernel to unmount it suddenly. You can run
fsck on an HFS+ partition in Linux, and that should fix the problem, provided the hfsprogs package is installed. Apple open-sourced much of their HFS+ code, so in theory this should be pretty much identical to running a check in macOS; however, Apple's been making some changes to their filesystems lately, and I don't know if those changes have worked their way into Linux distributions' packages, so it may be safer to do the job from macOS, using Disk Utility. If Disk Utility gives you an option to do so, though, do not enable a journal on the partition, for the reasons noted earlier.
You may be able to gain some clues about what's causing the problem by looking at the kernel ring buffer immediately after the problem occurs. You can do this by typing dmesg to see the whole thing, or dmesg | tail to see the last few lines. (You can extend the number of lines shown via the -n option to tail, as in dmesg | tail -n 20; or you can use less rather than tail to be able to scroll through the whole thing.) The kernel ring buffer should record information on kernel failures, which an unrequested unmount of a filesystem is. OTOH, it's conceivable that whatever's causing the unmount isn't really a kernel failure, or the error reporting doesn't happen for some reason. If you try the above suggestions and they don't help, but if the kernel ring buffer shows something suspicious, you can try posting the details.
