Во-первых, HFS+ - это не нативная файловая система с точки зрения Linux, поэтому ожидается некоторая странность. Тем не менее, полное размонтирование файловой системы при удалении файлов выходит за рамки того, что я ожидал, но может случиться так, что это, по крайней мере, часть того, что происходит. Если это так, и если ни одно из приведенных ниже предложений не поможет, переключение на FAT может помочь. Хотя FAT также не является нативным, его драйверы (как в Linux, так и в macOS) достаточно развиты, что вряд ли вызовет такие проблемы. OTOH, FAT также очень ограничен по сравнению с HFS+, поэтому он может быть неадекватным (например, если вам нужно хранить большие файлы).
В любом случае, здесь могут возникнуть некоторые конкретные проблемы:
- Журналирование - По умолчанию, MacOS создает HFS+ томов с журнальной активными. Фактически, это значение по умолчанию нельзя отключить в последних версиях macOS при использовании Дисковой утилиты GUI. Журналирование, однако, плохо поддерживается в драйверах Linux HFS+. Таким образом, для общего раздела данных лучше отключить ведение журнала. К сожалению, я не знаю, как это сделать на существующем томе; но, может быть, поиск в Интернете что-то даст. Если нет, или если вы не против сделать жонглирование backup-reformat-restore, вы можете сделать это. Когда вы это сделаете, я бы предложил использовать
mkfs.hfsplus
в Linux для создания новой файловой системы. Чтобы создать файловую систему без журналирования, вы должны опустить опцию -J
. (Введите man mkfs.hfsplus
чтобы узнать больше об этой команде.) Если команда не установлена, вам может потребоваться установить пакет hfsprogs
. Есть способ командной строки сделать это и в macOS; Я считаю, что команда newfs
или что-то подобное. Я не помню детали, хотя.
- Скоординированные идентификаторы пользователей. По умолчанию первый идентификатор пользователя (UID) в Ubuntu равен 1000, а в macOS - 501. Таким образом, когда вы пытаетесь обмениваться файлами в разделе HFS+ между этими ОС, файлы будут принадлежать разным пользователям в каждой ОС. Хотя можно свободно устанавливать разрешения или активно использовать
sudo
чтобы обеспечить общий доступ к файлам, лучшим решением будет согласование значений UID между двумя установками. Мой ответ на этот вопрос в AskUbuntu описывает, как это сделать в Ubuntu, и предоставляет ссылки на другие сайты, которые описывают, как это сделать в macOS. (Внесение изменений в macOS предпочтительнее, но в macOS этот процесс более утомителен.) Предлагая внести это изменение, я предполагаю, что вы можете столкнуться с проблемами разрешений и что эти проблемы взаимодействуют с ошибками файловой системы, которые приводят к отключению файловой системы.
- Ошибки файловой системы - если файловая система была повреждена, возможно, она внезапно отключила ядро. Вы можете запустить
fsck
в разделе HFS+ в Linux, и это должно решить проблему, если установлен пакет hfsprogs
. Apple открыла большую часть своего кода HFS+, поэтому теоретически это должно быть почти идентично выполнению проверки в macOS; тем не менее, Apple в последнее время вносит некоторые изменения в свои файловые системы, и я не знаю, попали ли эти изменения в пакеты дистрибутивов Linux, поэтому может быть безопаснее выполнять работу в macOS с помощью Disk Utility. Если Дисковая утилита дает вам возможность сделать это, не включайте журнал в разделе по причинам, указанным ранее.
Вы можете получить некоторые подсказки о том, что является причиной проблемы, посмотрев на кольцевой буфер ядра сразу после возникновения проблемы. Вы можете сделать это, набрав dmesg
чтобы увидеть все, или dmesg | tail
чтобы увидеть последние несколько строк. (Вы можете расширить число строк, показанных с помощью опции -n
до tail
, как в dmesg | tail -n 20
; или вы можете использовать less
, чем tail
чтобы иметь возможность прокручивать все это.) Кольцевой буфер ядра должен записывать информацию о сбоях ядра, что является незапрошенным размонтированием файловой системы. OTOH, возможно, что то, что вызывает размонтирование, на самом деле не является отказом ядра, или сообщение об ошибке по какой-то причине не происходит. Если вы попробуете приведенные выше предложения, но они не помогут, но если кольцевой буфер ядра показывает что-то подозрительное, вы можете попробовать опубликовать детали.