[clug] NFSv4 "Invalid argument"

[Scott Ferguson]

Excellent George, thanks for persevering, and especially thanks from
other with the same problem who will benefit from you posting your results.

Not an ideal situation - using the set v3 method, but it works, which is
a start.


On 16/10/14 21:19, George at Clug wrote:
>     Scott,
> 
> I have had some success with the virt-manager and NFS.  The issue
> seems to be two fold, a) NFS version 4 is more complex and I do not
> know how to use it, b)  that I was not using the correct option for
> controlling the version of NFS _and_ in OpenFiler I had to set the NFS
> share to no_root_squash
> This site
> "https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/sect-shared-storage-nfs-migration.html"
> gave me the idea to go and look in OpenFiler to see if I could change
> the NFS shares (export) options, and I discovered that I could change
> between the default of root_squash to no_root_squash. (of course
> no_root_squash is not as secure).

That's one way - another way is to use the anonuid and anongid options.
0=root
I don't know that has any advantages or no_root_squash or the v3 method.
NOTE: I've used the no_root_squash option on webservers (no virtual
host) to get around the www-data problem, though this is not something I
now do.

------------8<-------------->8---------------------------------
> 
> I have not resolved the a) issue, but I have the b) option: "-o
> vers=3"
> # mount -t nfs -o vers=3 -v
> 192.168.0.12:/mnt/vg2/vol1/san12_nfs_ds1/kvm-images/images
> /var/lib/libvirt/images
> 
> Previously I had used the wrong syntax; "nfsvers=3"
------------8<-------------->8---------------------------------

You can chain those o(ptions),should you need to (standard mount format
 e.g. -o nfsver=3,sec=krb5,etc

For testing I find the -f (fake) and -v (verbose, more v's is more
verbose) options useful
e.g.:-
$ su -c "mount -fvvvt cifs -o credentials=/home/scott/.cifs
//dev/packages /var/cache/apt/archives"
Password:
mount: fstab path: "/etc/fstab"
mount: mtab path:  "/etc/mtab"
mount: lock path:  "/etc/mtab~"
mount: temp path:  "/etc/mtab.tmp"
mount: UID:        0
mount: eUID:       0
mount: spec:  "//dev/packages"
mount: node:  "/var/cache/apt/archives"
mount: types: "cifs"
mount: opts:  "credentials=/home/scott/.cifs"
mount: external mount: argv[0] = "/sbin/mount.cifs"
mount: external mount: argv[1] = "//dev/packages"
mount: external mount: argv[2] = "/var/cache/apt/archives"
mount: external mount: argv[3] = "-f"
mount: external mount: argv[4] = "-v"
mount: external mount: argv[5] = "-o"
mount: external mount: argv[6] = "rw,credentials=/home/scott/.cifs"
mount.cifs kernel mount options:
ip=192.168.0.2,unc=\\dev\packages,user=scott,pass=********

You might use sudo instead. I don't have access to an nfs share from
where I'm writing - but the effect is the same with nfs. Note that the
share isn't actually mounted (-f switch). Confusingly dev (development),
in this instance, is a box name, not a file system.

> 
> Now mounting the NFS share with option "-o vers=3" I can change the
> permissions on the folders and files, see the below commands which
> should explain things for you;
> 
------------8<-------------->8--------------------------------->
> =====================================================================================
> Now to put the permissons the way I wanted them
> --------------------------------------------------
> # chown -R libvirt-qemu:libvirt-qemu /var/lib/libvirt/images
> # ls -al  /var/lib/libvirt/images
------------8<-------------->8--------------------------------->
> And now the VM will run without an errors.
> 
> ===================================================================================
> But I get the below error messages when using virt-manager if I do not
> use "# chmod -R 777 /var/lib/libvirt/images"
> 
> "The emulator may not have search permissions for the path
> '/var/lib/libvirt/images/ISO/debian-7.5.0-amd64-DVD-1.iso'."

Hmmmm. I probably shouldn't suggest this, but an insecure solution,
might be to modify the group's membership. I'd still try the anonid/gid
options first - then that share should mount as root.

Can any other readers suggest something?


------------8<-------------->8---------------------------------


Kind regards