Виртуальный ящик Ubuntu Desktop 18 не может изменить права доступа к файлам в общей папке
Я пытаюсь использовать общую папку с хост-компьютера Windows в качестве корневого каталога для lighttpd на гостевой виртуальной машине Ubuntu. Когда я пытаюсь изменить разрешения, ничего не происходит. Разрешения всегда остаются одинаковыми (как показано ниже). lighttpd всегда возвращает ошибку 403 независимо от типа файла. Как я могу изменить права доступа к файлу?
Редактировать:
Исследования показывают, что добавление моего пользователя в группу пользователей vboxsf позволит мне изменить разрешения. Когда я пытаюсь добавить своего пользователя в группу, используя usermod, кажется, что он работает, но изменения немедленно отменяются и откатываются. Другие источники предлагают мне вручную смонтировать диск с необходимыми разрешениями. Несмотря на мои попытки сменить владельца, root все еще остается владельцем. Это несмотря на мое ранее объяснение попытки использовать usermod для смены владельца. Проверяя настройки группы в файле / etc / group, я вижу мое имя пользователя в списке. Тем не менее, виртуальный ящик может создавать помехи.
В качестве альтернативы я рассматриваю возможность совместного использования сети от гостя до хоста.
Конец редактирования
/media/sf_Space.io$ ls -l
total 10
drwxrwx--- 1 root vboxsf 0 May 12 11:57 css
-rwxrwx--- 1 root vboxsf 8 May 12 12:27 index.html
drwxrwx--- 1 root vboxsf 0 May 12 11:57 js
drwxrwx--- 1 root vboxsf 0 May 12 11:57 PythonCGITest
-rwxrwx--- 1 root vboxsf 1181 May 12 11:57 README.md
drwxrwx--- 1 root vboxsf 0 May 12 11:57 sprites
-rwxrwx--- 1 root vboxsf 587 May 12 11:57 test.html
drwxrwx--- 1 root vboxsf 4096 May 12 11:57 'welcome page (sketch)'
2 ответа
После часов работы я выяснил свое собственное решение. Проблема полномочий связана с тем, как virtualbox монтирует файловые системы от хоста. Моя файловая система хоста является ntfs в этой ситуации. Несмотря на любые команды, пытающиеся изменить полномочия объема, полномочия останутся с корнем как владелец и набор полномочий к 770.
Установите гостевой дополнительный пакет в своей виртуальной машине. Создайте новую совместно используемую папку с только, "делают постоянными" проверенный. НЕ устанавливайте флажок автомонтирования. Кроме того, не уверенный, если это необходимо, но также и устанавливает пакет расширения для virtualbox в Вашей хостовой операционной системе.
Создайте каталог на гостевой машине (операционная система, работающая в virtualbox).
Создайте a
.shфайл со следующим сценарием удара:sleep 1 echo '[your password]' | sudo -S mount -t vboxsf -o rw,uid=1000,gid=1000 [share name] [path to the directory created in the previous step]Перейдите "менеджеру" приложений запуска и создайте новый запуск с командой:
xterm -e "/path/to/script/in/previous/step"Установите разрешение файла на исполняемый файл:
chmod +x [file name].- Установка xterm
sudo apt-get install xterm.
Я осознаю угрозу безопасности "ввода" sudo пароля. Однако в этой ситуации, я - единственный с доступом или требованием выполнить эту виртуальную машину. Я считал риск низко. Оцените свою ситуацию прежде, чем обратиться к этому решению. Кроме того, я не забываю читать, что, добавляя пространство, прежде чем команда будет препятствовать тому, чтобы командная строка хранила ту команду в списке предыстории.
Это решение работало на меня на Ubuntu 18LTS. Я знаю о rc.local и chron заданиях, но они варьируются среди версий распределения, и это казалось довольно случайным. rc.local даже не существует в моей установке, и создание файла вручную ничего не выполнило.
В моем случае ничего не работало - и простая переустановка гостевых дополнений виртуального ящика сделала свою работу. Хотел бы я попробовать это раньше.