У меня Windows 10 работает на ноутбуке с VirtualBox и гостем Linux.

Я много программирую для среды Linux и работаю с репозиториями исходного кода, расположенными в дереве каталогов FS /, совместно используемом хостом Windows и гостем Linux, например редактирую с помощью SublimeText, работающего под Windows, но выполняю компиляцию, тестирование, контроль версий и т.д. В терминал, связанный с гостем Linux.

По разным причинам мне нужны каталоги, в которых размещаются репозитории исходного кода, чтобы разрешить полную семантику Unix, то есть иметь возможность устанавливать uid/gid для владельца, биты разрешений, создавать fifos, символические ссылки и т.д. И т.д. И т.д.

Мне все равно, если эти функции не имеют общего использования между Windows и Linux. Мне нужно, чтобы эти вещи были четко определены на стороне Linux. Что касается Windows, мне просто нужно иметь возможность читать / записывать содержимое файла.

Я хочу, чтобы файлы размещались на стороне хоста Windows/, а не в гостевой системе Linux, поскольку я не хочу запускать гостевую систему Linux, чтобы файлы стали видимыми / доступными в Windows.

Как я могу настроить такую вещь?

Я пробовал разные вещи.

Кажется, vboxsf предлагает только небольшое подмножество функций Unix. Пожалуйста, поправьте меня, если я ошибаюсь.

Я пробовал posixovl поверх монтирования vboxsf, но я не могу заставить его поддерживать такую простую операцию, как «mkdir mydir; rm -rf mydir». Такая операция не удастся с «rm: не может удалить" mydir ": каталог не пуст». Мой диагноз проблемы с этим состоит в том, что он создаст файл "somedir/.pxovl", чтобы сохранить биты разрешения somedir и тому подобное на более низкой FS. На верхней ФС этот файл не виден, поэтому «rm -rf» не может избавиться от файла. Когда «rm -rf» пытается "rmdir mydir" на верхней FS, это вызовет попытку сделать это на нижней FS, которая не удалась, потому что файл «.pxovl» все еще там. Пожалуйста, поправьте меня, если есть решение, но это сводит меня с ума.

Я попытался настроить каталог как сетевой ресурс на стороне Windows, а затем подключить его через mount.cifs в Linux. Кажется, что такое монтирование также не предлагает должным образом Unix-функций, и в этом смысле имеет ограничения, подобные vboxsf, и я не могу найти никаких опций, которые позволили бы для любого типа эмуляции или чего-то подобного.

Мне пришло в голову, что, возможно, могут быть программы, которые можно настроить на стороне хоста Windows, которые предлагают реальную семантику Unix и выполняют какую-то эмуляцию функций Unix, таких как NFS-сервер или другой тип сервера для сетевых общих файловых систем, но Кажется, я не могу их найти.

Мне также пришло в голову, что оверлейные файловые системы могут быть полезным инструментом для создания такого решения, но не могут по-настоящему осмыслить, как может выглядеть такое решение.

Есть идеи?

|источник

2 ответа2

0

Оказалось, что я могу приблизиться к тому, что я хотел, с помощью комбинации

  • WSL с использованием новых функций drvfs, в которых определенные аспекты семантики unix эмулируются в WSL (опция metadata для монтирования drvfs);
  • SSH работает на этом WSL на хосте Windows;
  • sshfs работает в гостевой системе VirtualBox под Linux.

Решение было:

  • Установка Ubuntu для Windows (WSL).
  • Включение sudo без пароля в WSL с использованием строки %sudo ALL=(ALL:ALL) NOPASSWD: ALL в /etc/sudoers на WSL.
  • Помещение команды "bash -c 'sudo /etc/init.d/ssh start'" в автозапуск под Windows с использованием реестра, чтобы сервер OpenSSH на основе WSL запускался автоматически, как только я вхожу в систему.
  • Настройка брандмауэра Защитника Windows, чтобы разрешить подключения к порту 22.
  • Настройка ключей SSH, чтобы разрешить вход без пароля с гостя linux на сервер SSH на основе WSL.
  • Используя wsl.conf для вставки метаданных опций metadata,umask=0002,fmask=0113 при монтировании drvfs в WSL.
  • На гостевой Linux, поместив user_allow_other в /etc/fuse.conf
  • В гостевой системе linux sudo -u myuser sshfs -o allow_other myuser@windowshost:/mnt/c /mnt/c для совместного использования C-Drive.
  • Убедитесь, что UID для myuser одинаковы для WSL и Linux.

РЕЗУЛЬТАТ: Это делает так, что имена файлов и содержимое файла совместно используются Windows, WSL и Linux на гостевой виртуальной машине, что эмулируются дополнительные возможности Unix, такие как биты прав доступа и ссылки, и что эти эмулированные функции являются общими для WSL и Linux. Но:

  • ОГРАНИЧЕНИЕ: Когда я создаю файл, даже через пользователя, отличного от myuser в гостевой системе Linux, он становится владельцем myuser .
  • ОГРАНИЧЕНИЕ: fifos не поддерживаются.
  • Я могу жить с этими ограничениями, поскольку мне не нужны fifo, и я действительно беспокоюсь только о том, что происходит с файлом, с которым я работаю, под одним пользователем, который я использую для разработки программного обеспечения на своем ноутбуке.
|источник
0

К сожалению, Windows не считает, что файлы имеют те же метаданные, что и системы Linux/Unix - это приводит к головной боли, которую вы испытываете в настоящее время.

Мое решение (к сожалению для вас) - хранить файлы на виртуальной машине Linux и использовать CIFS / Samba для обмена ими с хостом Windows - я делаю это часто.

Я не знаю ни одного способа добиться прозрачности и надежности, к которым вы стремитесь, при размещении файлов в файловой системе Windows (не Unix).

Возможно, стоит покопаться в подсистеме Windows для Linux. Недавно они добились больших успехов (например, Chmod/Chown WSL Improvements), так что вы можете установить сервер NFS или что-то под WSL, чтобы добиться того, чего вы хотите, но с учетом того, где NFS реализована в Linux (в ядро), это, скорее всего, не может быть и речи.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .