Перенос папки с раздела vfat на раздел ext-4 без изменения filepath

Хитрый трюк не снимая брюк. Решение показалось изящным, поэтому решил документировать.

Абстракт

Мы решили подключить старый HDD для использования с локальным веб-сервером под nginx в Docker-контейнере.

Диск 500 ГБ с одним разделом остался от Windows 10  и использовался для хранения 250 ГБ различного контента: графики для статей, видео и т. д.  HDD железный, тихий, холодный, в хорошем состоянии, WD,  2017 год. 

Минусы: VFAT, dirty bit, помечен msdata, guid sambashare и никак не поменять права даже через sudo chown.

Файловая система vfat  и прочие указанные выше "особенности" при попытках использовать драйв в ubuntu с использованием системных возможностей по взаимодействию с контейнерами приводили к постоянным глюкам при копировании из контейнеров, работе с правами, группами и POSIX-совместимыми атрибутами.

Решение: создать новый раздел ext4, чтобы избежать проблем с правами доступа и POSIX. Исходя из ответов от  KDE Partition Manager у меня были мысли отформатировать и разбить на два раздела, так как партишн менеджер нес какой то бред про "заполнение" файловой системой всего диска и невозможность изменения размеров партишн. Звучало правдоподобно и пнуть винду лишний раз за деревянные технологии - святое дело, поэтому всё казалось, шло к форматированию драйва. Ни запаса по питанию, по слотам, по usb портам нет для установки нового диска, и вообще держать почти терабайт дискового пространства на скромном настольном моноблоке вполне достаточно, я считаю. В системе два драйва SSD и HDD это мне нравится и меня устраивает. KDE KDE Partition Manager мне удобен для управления свопом с графическим UI и дизайн приятный.

Мои ковыряния:

Использовал GParted 1.0.0 (libparted 3.3), так как KDE Partition Manager 22.08.1 не смог корректно выполнить разбивку - там другие библиотеки.

Разделили диск:

• Было:

Device Start End Sectors Size Type 
/dev/sdb1 2048 746254335 746252288 465.9G Microsoft basic data 

• Стало:

Device Start End Sectors Size Type 
/dev/sdb1 2048 746254335 746252288 355.9G Microsoft basic data 
/dev/sdb2 746254336 976773119 230518784 109.9G Linux filesystem 

После работы GParted права на созданный раздел и на старый vfat стали root.
Разделы стали доступны для монтирования и размонтирования через UI приложения со сменой прав доступа, владельца и группы. Явно то, что gparted вычистил проблему, причину которой мне самостоятельно найти было сложно.

Для корректной работы разделов в моей системе выполнили:

sudo chown -R hakim:hakim /media/hakim/HDD  

Аналогично - sudo chown для второго раздела /dev/sdb2 , монтажную точку для которого сначала  использовал  /media/hakim/HDD-ext4

sudo chown -R hakim:hakim /media/hakim/HDD-ext4

С owner = root на диск особо не попишешь, только для чтения открыт.

После этого появился нормальный доступ на запись к файлам и возможность менять права в UI приложениях типа Dolphin и тп.

Создали монтажную точку и смонтировали туда раздел ext4:

Предварительно переименовали существующую папку /HDD/f-docker  из-за которой собственно, весь сыр-бор. Это папка со скриптами и volumes Docker.

Как оказалось…

Это можно было сделать только так, и по другому - никак:

sudo mkdir -p /media/hakim/HDD/f-docker 
sudo mount -t ext4 /dev/sdb2 /media/hakim/HDD/f-docker  

Попытки монтирования с такой Mount Point через Gparted, Dolphin и KDE Partition Manager приводили к страшным «ошибкам» и сообщениям о невозможности монтирования ext4-раздела внутри vfat-раздела.

В итоге, "мандирование" вручную средствами линукс через mount как всегда оказалось лучшим вариантом. Но риски ручного ковыряния конечно  - щекочут нервы.

Прописанные ранее и отлаженные длинные bash скрипты с логированием, которые стартуют и останавливают контейнер, включают https, генерят сертификаты SSL, переименовывают системные бриджи, монтируют папки контейнера в локальные папки, что тоже с vfat не очень то хорошо дружит, еще куча кастомизации для nginx - все должно было переехать на другие адреса в файловой системе. Оставить линк на новую папку с тем же именем нельзя - vfat такого не может.

Вообщем, все настройки развертывания контейнера были уже привязаны к конкретным директориям. Перспектива перелопатить всё чтобы поменять 12 строчек с путями к директориям и забыть две, потом искать полдня - не очень нравилась.

/media/hakim/HDD/f-docker

Такое решение - смонтировать раздел в монтажную точку, которая находится в другом (не системном) разделе, как вложенная папка, не приходил в голову не только мне, но и разрабам gparted, KDE PM, Dolphin приложения которых падали в обморок при попытке такого монтажа. Скорее всего - это баг библиотек которые они используют, можно писать репорт.

Вот и всё - три часа ужоса от перспективы бэкапа и восстановления 250ГБ с альтернативой разбора архивов и сокращения этого объема вдвое.