Consider the following issue - Using virt-manager with qemu:///session - User adds a storage pool pointing at /tmp. No explicit permissions are requested in the XML - virt-manager calls PoolDefine, then PoolBuild - libvirt tries to unconditionally chmod 755 /tmp. This fails because my user doesn't own root. Pool build fails, virt-manager reports failure Yes there's a couple ways we could avoid this specific case in virt-manager, but I think it makes more sense to have pool.build on a directory be a no-op in this case. The following patches address this. I already pushed some bits of v2 of the series. Now the patches are: - Patch 1 (new) update existing docs about storage <permissions> - Patch 2 changes storage XML to not hardcode a <mode> value if the user didn't specify one in. - Patch 3 (new) don't output empty <permissions> block - Patch 4 makes pool.build skip dir chmod unless the user explicitly requested <mode> via the XML. However if a mode is required for mkdir, continue to use the previous default. Cole Robinson (4): docs: formatstorage: Update <permissions> docs storage: conf: Don't set any default <mode> in the XML conf: storage: Don't emit empty <permissions> block storage: fs: Only force directory permissions if required docs/formatstorage.html.in | 40 ++++++++----- docs/schemas/storagecommon.rng | 8 ++- src/conf/storage_conf.c | 70 ++++++++++++---------- src/storage/storage_backend.c | 20 +++++-- src/storage/storage_backend.h | 3 + src/storage/storage_backend_fs.c | 32 ++++++---- src/storage/storage_backend_logical.c | 4 +- src/util/virfile.c | 4 +- tests/storagepoolxml2xmlout/pool-netfs-gluster.xml | 3 - tests/storagevolxml2xmlout/vol-gluster-dir.xml | 3 - tests/storagevolxml2xmlout/vol-sheepdog.xml | 3 - 11 files changed, 113 insertions(+), 77 deletions(-) -- 2.4.1 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list