[Users] Can't add NFS domain

Damiano Verzulli damiano at verzulli.it
Fri Sep 7 09:07:25 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 07/09/2012 06:03, Changsen Xu ha scritto:
> [...] 2 - confirm that your NFS server is configured: - to default to
> NFSv3 (refer to above wiki page); - with a correct export (refer to
> above wiki page). Please pay attention to the need of having, on the
> NFS server, a USER with UID 36. Best if related username is "vdsm";
> 
>> I've playing with this problem for several days, done every step I
>> can find on internet, just can't figure out why.
>> 
>> On my node/host, if I "su - vdsm -s /bin/bash", I can't never use
>> mount. It always complained only root can use mount.

You _cannot_ "mount" as "vdsm" users, as generally only "root" can mount.

The "vdsm" will do the mount as "root", thanks to "sudo" features. In my
case, for example, the vdsm log say:
- --------------------------
Thread-694::DEBUG::2012-09-02
22:23:06,813::__init__::1164::Storage.Misc.excCmd::(_log) '/usr/bin/sudo
- -n /bin/umount -f -l /rhev/data-center/mnt/10.0.49.14:_mnt_STORAGE_NFS'
(cwd None)
- --------------------------

Even if the mount will be done as "root", it will be the "vdsm" user that
will "write" to the NFS share. Hence, on the NFS-server-side, you need
"write permission" for user with UID-36.
That's why you have to take care, on the NFS-server side, that:

- - the NFS server is configured to map _all_ "anonymous" (see below) write
request as if they are made by (local to the NFS server) UID 36 => cfr.
anonuid/anongid option for /etc/exports file (see "man exports").
Consider that, if I'm right, a write request is considered "anonymous" if
it is not possible to reverse-lookup the UID traveling inside NFS-write
request, into a "username" mapped within the (local to the NFS server)
/etc/passwd file.

and to avoid any potential misunderstanding:

- - the NFS server has a local user with UID 36 defined (as well as a local
gid with GID 36). This is not strictly required, but helps during
troubleshooting activities, as you see the same username both within the
client, and the server.


To add further complexity... let me add that when I had NFS problems on
my side....

>> I can use root to mount nfs server manually, but just can't add NFS
>> domain in the engine side.

... I was:

- - perfectly able, with exactly the very-same "sudo" command, and from the
"vdsm" account, to manually mount the NFS-share (again: with
cut-and-paste from the log-file);
- - afterwards, to "read/write" to the NFS share, with "vdsm" user/permission.

Even during the few-seconds interval, after the "ADD ISO DOMAIN" click,
and before the "error" showed in the web-interface, I correctly saw the
NFS-remote filesystem, locally mounted on the ovirt-node. So,
technically, the node is perfectly able to mount the NFS share.

But then, unfortunatly, something goes wrong and... the web-app due to
this, take care to "umount" the NFS. I'm supposing this as, magically,
the previously mounted NFS-share, simply "disappeared" :-(

This, at least, in my case.

Bye,
DV


- -- 
Damiano Verzulli
e-mail: damiano at verzulli.it
- ---
possible?ok:while(!possible){open_mindedness++}
- ---
"Technical people tend to fall into two categories: Specialists
and Generalists. The Specialist learns more and more about a
narrower and narrower field, until he eventually, in the limit,
knows everything about nothing. The Generalist learns less and
less about a wider and wider field, until eventually he knows
nothing about everything." - William Stucke - AfrISPA
  http://elists.isoc.org/mailman/private/pubsoft/2007-December/001935.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlBJuU0ACgkQcwT9fsMT4Sw8OgCgk9PNV5kBmTvVZWqcmcubmbXl
yEIAn0OJQ9qcKkfIcFkHtOn5cVzoXYN3
=pWup
-----END PGP SIGNATURE-----



More information about the Users mailing list