Я знаю, что это - старый поток, но я просто столкнулся с подобной проблемой и нашел решение, которое работает, по крайней мере, в частях.

Я также изменил пользователя и значения группы в /etc/libvirt/qemu.conf базироваться, как Вы сделало.
Но я также изменился dynamic_ownership установка, потому что описание звучало как обещание:

# Должен ли libvirt динамично изменить принадлежность файла
# соответствовать настроенному пользователю / группа выше. Значения по умолчанию к 1.
# Набор к 0 для отключения изменений принадлежности файла.

Моя установка:

• Хост: (Jessie) Debian 8
• Гость: (Jessie) Debian 8
• совместно используемая папка на хосте принадлежит root
• локальный пользователь w/идентификатор 1000 является членом группы libvirt (могло бы быть важным),
• точка монтирования на госте (/mnt/data) принадлежит пользователю 1000 ("alexander")

Я могу теперь наконец записать файлы в смонтированной совместно используемой папке и с корнем (0) и с alexander (1000). (прежде чем я сделал это, только базируюсь, был позволен записать файлы здесь),

Установка dynamic_ownership к 0 то, в чем нужно выполнить "отображенный" accessmode.

Вот еще некоторая информация о моей установке:

/etc/libvirt/qemu.conf:

user = "root"
group = "root"
dynamic_ownership = 0

файловая система (virsh редактирование):

<!-- ... -->
    <filesystem type='mount' accessmode='mapped'>
      <source dir='/share/vm.localdomain/owncloud_data'/>
      <target dir='/data'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </filesystem>
<!-- ... -->

Хост:

ls -al /share/vm.localdomain/owncloud_data/
total 8
drwxr-xr-x 2 root      root      4096 Sep  8 00:15 .
drwxr-xr-x 7 root      root      4096 Sep  8 00:10 ..

fstab на госте:

/data  /mnt/data/  9p  trans=virtio  0  0

Гость:

root@debian:~# cd /mnt/data
root@debian:/mnt/data# touch touched_by_root
root@debian:/mnt/data# su - alexander
alexander@debian:~$ cd /mnt/data
alexander@debian:/mnt/data$ touch touched_by_user
alexander@debian:/mnt/data$ ls -al
total 16
drwxr-xr-x 2 alexander alexander 4096 Sep  8 00:30 .
drwxr-xr-x 6 root      root      4096 Sep  7 18:13 ..
-rw-r--r-- 1 root      root         0 Sep  8 00:30 touched_by_root
-rw-r--r-- 1 alexander alexander    0 Sep  8 00:30 touched_by_user

назад на хосте:

root@Host /share/vm.localdomain # ls -al /share/vm.localdomain/owncloud_data/
total 16
drwxr-xr-x 2 root      root         4096 Sep  8 00:30 .
drwxr-xr-x 7 root      root         4096 Sep  8 00:10 ..
-rw------- 1 root      libvirt-qemu    0 Sep  8 00:30 touched_by_root
-rw------- 1 root      libvirt-qemu    0 Sep  8 00:30 touched_by_user

заключение

Странная вещь состоит в том, что на госте эти два файла принадлежат различным пользователям (корень по сравнению с alexander), тогда как на хосте, оба файла принадлежат тому же пользователю (root:libvirt-qemu).:-O
Я не знаю точно, как это волшебство работает, но по-видимому оно делает.

Надеюсь, это поможет,
Alexander

Я имел эту проблему также, создал папку, названную /home/user/shared на хосте, и затем использовал virt-менеджера для добавления папки и смонтировал его как 9 пунктов virtio на qemu VM.

я проверил настройки в/etc/apparmor.d/libvirt, и он имеет записи для нового /home/user/shared,, и я заметил, что он только имел' r' разрешение для /home/user/shared, но он имеет rw для всех файлов в /home/user/shared/. Я пытался добавить w для полномочий записи, но это, казалось, не было сохранено так, я вошел в хост /home/user/shared и создал подкаталог и сделал chmod 777 на том подкаталоге. Это работало и гость, VM смог записать в su директора, что любой создает и редактирует файлы.

tldr: создайте подкаталог в совместно используемой папке с 777 полномочиями и посмотрите, можно ли записать в это.

@Alexander дал большой ответ. Я не сделал всего, что он сделал, но это - то, что я действительно делал для получения прав того-же-пользователя, работающих оба пути через файловую систему на 9 пунктов. (Этот путь предназначается, чтобы просто заставить 9 пунктов работать, оба пути, без стычек безопасности. Для большей безопасности Вам будут нужны другой метод или настройки),

ХОСТ (порядок неважен),

• Я добавил своего пользователя узла к следующей группе: <kvm> (я - также член <libvirtd>). Этот шаг может быть ненужным потому что:

• в файле/etc/libvirt/qemu.conf можно изменить пользователя и группу, с которой все VMs проходят проверку подлинности и выполняются.

(это - мощное небольшое изменение, и последствия должны планироваться, при попытке выполнить это на чем-то как рабочий сервер),

user = "billy"    #### No, my name isn't billy, but it's cute. 
                  #### Alternatively you can declare your <uid>, like
                  ## user = "+1000" ####        << That's what I did.
                  #### (They tell you everything you need to know about
                  #### this stuff inside /etc/libvirt/qemu.conf)
group = "billy"
dynamic_ownership = 1

(Что делает вышеупомянутое изменение, говорит хосту виртуальной машины преобразовывать весь libvirt cross-VM-requests для любого гостя VMs, который Вы выполняете к <пользователь>, которого Вы устанавливаете; включая гостя-VM <корень>. *Обратите внимание снова, что это - установка в масштабе всей системы относительно libvirt и следовательно qemu, если libvirt является Вашим единственным интерфейсом qemu.)

• Установите Вас хост, как найдено в этом превосходном официальном документе https://www.linux-kvm.org/page/9p_virtio

(между прочим, "Сквош" ссылается на модель обеспечения безопасности на 9 пунктов. Это не означает "ни один" и является самой разрешающей установкой для этого контекста),

ГОСТЬ

• В госте VM смонтируйте, что доля на 9 пунктов с помощью <базируется> полномочия, также найденные в нижней части документа https://www.linux-kvm.org/page/9p_virtio

(Я также добавил одну опцию, как объяснено в документе ниже), Моя команда монтирования:

mount -t 9p -o trans=virtio,access=any,version=9p2000.L /hostshare /tmp/host_files

Nore, что, если Вы не имеете разрешения записать в долю или ограничили разрешение после установки этого превосходное предложение ответом @randomocean должно помочь. Таким образом, имейте <базируются>, создают папку под долей и устанавливают chmod 777 к нему.

- Еще больше Информации: https://wiki.qemu.org/Documentation/9psetup

Я столкнулся с той же проблемой, когда пытаясь смонтировать каталог с хоста Ubuntu на виртуальную машину Minikube. В вопросе не указан Minikube, но это не имеет значения, поскольку это виртуальная машина, управляемая QEMU/KVM. Приведенные ниже инструкции должны применяться к любой виртуальной машине QEMU/KVM. Я не смог найти конкретных инструкций о том, как монтировать каталоги узлов в виртуальные машины KVM. Я много искал, и это было довольно утомительно. Я объясню, что я сделал для обработки ошибок разрешений, а также ошибок символических ссылок или ошибок «Неизвестная ошибка 526». Я кратко упомяну, почему была необходима эта настройка, просто включу несколько ключевых слов, которые может использовать кто-то, у кого есть такие же проблемы, при поиске решения.

Проблема

Я запускал Minikube через VirtualBox. VirtualBox может монтировать /Users в MacOS или /home в Linux в виртуальную машину, и вам не нужно решать проблемы с монтированием так сильно, как с KVM. Мне нужно было разработать приложение для Android, серверная часть которого должна работать на Kubernetes. Чтобы протестировать приложение для Android, мне нужно запустить виртуальные устройства, которые запускаются через KVM в Linux. Нельзя одновременно запускать виртуальную машину на VirtualBox и виртуальную машину на KVM, потому что только одна из них может одновременно использовать технологию виртуализации процессора.Было бы довольно неудобно выключать Minikube, когда мне нужно было бы что-то проверить в приложении Android или наоборот. Поскольку на KVM можно одновременно запускать множество виртуальных машин, я решил запустить Minikube на KVM только для того, чтобы одновременно запускать виртуальные устройства Minikube и Android. С помощью VirtualBox также можно запускать несколько виртуальных машин одновременно, но виртуальные устройства Android по умолчанию не запускаются в VirtualBox. Похоже, что Genymotion использует VirtualBox, но это платное решение.

Цель

Моя цель состояла в том, чтобы смонтировать каталог, содержащий файлы моего приложения, так же, как монтирует VirtualBox. Minikube может монтировать каталоги с хоста с помощью команды minikube mount, но на момент написания статьи это по какой-то причине ненадежно. Это дало мне Неизвестная ошибка 526, когда я пытался получить доступ к файлам. Это также очень медленно.

Ответ @Alexander действительно помог мне решить проблему. Но этого было недостаточно, так как я не хотел запускать виртуальные машины как root. Когда они запускаются как root, файлы и/или каталоги, созданные внутри виртуальных машин, имеют разрешение root:root на хосте, чего я не хочу.

Решение

Определение пользователя, запускающего виртуальные машины

Прежде всего, я отредактировал /etc/libvirt/qemu.conf (на хосте), чтобы изменить пользователя, который запускает процессы VM, как моего пользователя, то есть ubuntu, и отключить dynamic_ownership:

user = "ubuntu"
group = "ubuntu"
dynamic_ownership = 0

После создания изменить выше, я перезапустил свой хост-компьютер, так как я не знаю, как применить изменения в противном случае. Без перезагрузки виртуальные машины продолжали работать от имени предыдущего пользователя, которым был libvirt-qemu. Чтобы убедиться, что изменение применено, выполните следующие действия:

1. На хост-компьютере запустите ps aux | grep kvm
2. Проверьте пользователя, который запускает процессы ВМ. В этом случае вы должны увидеть ubuntu.

Определение подключаемого тома

Далее добавьте оборудование Файловая система в Диспетчер виртуальных машин:

1. На хосте откройте Диспетчер виртуальных машин запустив virt-manager
2. Дважды щелкните на виртуальной машине и выберите View > Details
3. . В окне Details нажмите Add Hardware .
4. Выберите Файловую систему и настройте ее следующим образом:

Type: mount (only option)
Driver: Path
Mode: Squash
Write Policy: Immediate
Source Path: <absolute path to the directory you want to mount into the VM>
Target Path: hosthome # Or any other keyword or path that will be used to define the mount so that we can reference it when mounting it in the VM

# Do not check "Export filesystem as readonly mount"

5. Нажмите Применить. Если виртуальная машина работала, изменения будут применены при следующей загрузке.

Режим Squash важен, поскольку он может обрабатывать символические ссылки. Другие режимы давали мне слишком много уровней символических ссылок ошибок. Проходной режим решил проблемы, которые возникал в режиме Mapped, но этого было недостаточно. Сквош режим, который не дал мне никаких ошибок.

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

Теперь запустите (или перезапустите, если она работала) виртуальную машину. Если вы получаете ошибки прав доступа при запуске виртуальной машины, вам необходимо убедиться, что файлы, используемые для запуска виртуальной машины, принадлежат пользователю, указанному вами в файле qemu.conf. В моем случае я изменил права доступа к следующим файлам на хосте, изучив сообщения об ошибках:

chown ubuntu:kvm ~/.minikube/machines/minikube/boot2docker.iso # Previously belonged to "libvirt-qemu" user
chown ubuntu:root ~/.minikube/machines/minikube/minikube.rawdisk # Previously belonged to "root" user

Подключение тома к виртуальной машине

Теперь осталось только подключить том к виртуальной машине. Войдите в виртуальную машину,в моем случае через minikube ssh, а затем смонтировать том:

# First, create the directory to which the the volume will be mounted. This might not be necessary in your case.
sudo mkdir -p /hosthome/ubuntu/Projects

# Then, mount the volume
sudo mount -t 9p -o trans=virtio,version=9p2000.L,cache=none,msize=262144,rw hosthome /hosthome/ubuntu/Projects

• cache=none: это для повышения производительности. Вы можете изменить это значение на другое в зависимости от вашего случая. Значения объясняются здесь.
• msize=262144: это также для повышения производительности. Это определяет «количество байтов, используемых для полезной нагрузки пакета 9p», как объяснено здесь. Это значение по умолчанию, используемое minikube mount.
• rw: «Смонтировать файловую систему для чтения и записи», как описано в man mount. Это опция команды mount.

Вот так. Вы должны иметь возможность читать и записывать файлы/каталоги внутри виртуальной машины без каких-либо проблем. Если файл /etc/fstab внутри виртуальной машины можно изменить, в него можно добавить логику монтирования, чтобы том монтировался автоматически после запуска виртуальной машины. К сожалению, для Minikube это невозможно (см. раздел Недостатки).

Что я получил благодаря этой настройке

Проблемы, которые эта установка решила для меня:

• монтирование minikube было медленным и ненадежным, как это объясняется в документации. В документации сказано, что крепления 9p ненадежны, но эта установка более надежна, чем minikube.
• Файлы/каталоги, созданные контейнерами Docker внутри смонтированного каталога, принадлежат ubuntu:ubuntu на хосте. Таким образом, я могу получить к ним доступ из среды IDE и изменить их по своему усмотрению.Раньше у них было root:root, чего не было у моего пользователя на хосте.
• Я больше не получаю Неизвестную ошибку 526, которую я получил с помощью minikube mount
• Производительность выше, чем minikube mount
• Я могу запускать виртуальные устройства Android с аппаратным ускорением а также кластер Kubernetes заодно такой, что разработка намного удобней. Собственно, развитие «возможно» и сейчас.

Недостатки

• Для Minikube том следует монтировать вручную при каждом запуске minikube. Это связано с тем, что Minikube не сохраняет изменения, внесенные в файл /etc/fstab. В качестве удобного обходного пути сценарий оболочки, содержащий команду mount, может быть создан внутри каталога /data, который сохраняется после перезапуска ВМ, и может выполняться из ВМ после виртуальная машина запущена.

Ссылки

• Ответы на этот вопрос
• man mount
• Общий доступ к каталогам с виртуальными машинами и libvirt
• v9fs: план 9 совместного использования ресурсов для Linux