#4286 NFS v4 exports do not persist as v4 upon edit - they revert to v3; and NFS Version help missing

[sdaau]

Hi all,

I essentially have the same problem as described in NFS Exports in Ubuntu via Webmin reverting to NFS Version 3 (or lower) [experts-exchange.com]; unfortunately, answers on experts-exchange are not publicly readable, so I don't know what the response there was.

I have done this process on Ubuntu 11.04 with libnet-ssleay-perl libauthen-pam-perl nfs-kernel-server packages installed - and webmin_1.580_all.deb.

Basically, I go to Networking/NFS Exports; and

• On the "NFS Exports" page (/exports/), click Add a new export.
• On the next page, "Create Export" (edit_export.cgi), see that the 4 is selected under "NFS Version"
  • Here one portion of the bug is observable: clicking on "NFS Version" (help.cgi/exports/vers) opens a window, which says: "Failed to read help file /usr/share/webmin/exports/help/vers.html" (however, the help of )
  • The same happens for "NFSv4 Pseudofilesystem to export" (help.cgi/exports/pfs), saying "Failed to read help file /usr/share/webmin/exports/help/pfs.html" - however, it works for "Directory to export" (help.cgi/exports/dir), "Active?" (help.cgi/exports/active) and other help links
• Keep /export as "NFSv4 Pseudofilesystem to export", then add a directory (say /path/mysharedir) under "Directory to export", then continue making settings on the "Create Export" page - finally click on "Create" button
• Process completes fine, and I can see two new entries on the "NFS Exports" page: /export and /export/mysharedir
• However, when I click on either of these entries - in the subsequent "Edit Export" page, the "NFS Version" is marked as "3 (or lower)" - for either of those entries ??!
• Setting the version here back to "4" and clicking on Save doesn't make a difference:
  • process is again apparently successful (no errors); however, clicking on either of those entries to edit them again, will again show "NFS Version" as "3 (or lower)"

I can confirm that NFS apparently works on this machine:

$ showmount
Hosts on mypc:
192.168.1.20
$ showmount -e
Export list for mypc:
/export           *
/export/sharetest *

and that the Webmin process noted above, successfully changes /etc/exports; and there I could end up having e.g.:

/export/mysharedir       (no_subtree_check,rw,nohide)
/export (no_subtree_check,fsid=0,rw,nohide)

I really don't understand NFS mounts, and I cannot tell if the above is v4 syntax or v3 syntax (or if the syntax is where v3 and v4 differ at all). However, especially for someone as ignorant of NFS as myself, this kind of "reverting" behavior really sticks out, and made me think something about NFS itself was buggy.

---

So, I spent some time trying to debug what happens. First I inspected the HTTP exchange using Firebug and /var/webmin/webmin.log, getting something like this:

https://mypc:10000/exports/save_export.cgi?new=1&idx=&via_pfs=1&pfs=%2Fexport&dir=%2Fpath%2Fmysharedir&pfs_dir=%2Fexport%2Fmysharedir&active=1&auth=0&mode=3&host=&netgroup=&network=&netmask=&sec=0&ro=1&insecure=0&no_subtree_check=0&nohide=0&sync=0&squash=1&anonuid_def=1&anonuid=&anongid_def=1&anongid=&link_relative=0&noaccess=0&squash_uids_def=1&squash_uids=&squash_gids_def=1&squash_gids=&new=1

1377496101.12062.1 [26/Aug/2013 07:48:21] user faf05cdb6662a045b6af513af1af979a 127.0.0.1 exports save_export.cgi "create" "export" "/export" active='1' dir='/export' host='' pfs='/export' via_pfs='0'

I can note, that for some reason, the via_pfs=1 parameter in the call, ended up being via_pfs='0' in the webmin log.

However, I think the issue boils down to this piece of code in /usr/share/webmin/exports/edit_export.cgi - note that this snippet is the same in both the .dev version, and the latest from git:

...
local $via_pfs = 0;
local $nfsv = nfs_max_version("localhost");
if ($in{'new'}) {
        &ui_print_header(undef, $text{'create_title'}, "", "create_export");
        $via_pfs = ($nfsv == 4) ? 1 : 0;
        $exp->{"pfs"} = "/export";
    }
else {
        &ui_print_header(undef, $text{'edit_title'}, "", "edit_export");
        @exps = &list_exports();
        $exp = $exps[$in{'idx'}];
        %opts = %{$exp->{'options'}};
        }
...

In my case, it turns out that $nfsv variable always ends up with 4; so at least that is correctly read. Then, $via_pfs is only checked against it, and set to 1, if we're creating a new export - which is why the "4" radio button is selected as NFS version after clicking "Create Export".

However, that is the only place in this file where $via_pfs is set! That means, if I click on an export entry to edit it, then $in{'new'} (passed via GET/POST in web request) is "false" - and $via_pfs then remains on its default value, 0 - which eventually results with the "3 (or lower)" radio button to be selected as NFS version on the "Edit Export" page!

I then tried to hack a bit, so that $via_pfs if checked against $nfsv before the if() - and then indeed, NFS version is shown as "4" both when I create and when I edit an NFS export. However, then when editing the export, that hack also causes the "NFSv4 Pseudofilesystem to export" textfield to be editable/enabled - which may imply to ignorant users like myself that it should be set again. Thankfully, setting this field during edit doesn't seem to have any influence at all in the outcome. However, it seems to me that this field should indeed remain disabled, if we're editing an already existing NFS export - I found ./exports-nfs4/help/pfs.html in git, and it says:

NFSv4 client sees the NFSv4 server's exports as existing inside a single filesystem, called the NFSv4 pseudofilesystem. Here you must define the directory for the pseudofilesystem root.
You will still be able to add directories that are not bellow the root to the pseudofilesystem

So, apparently the role of the "NFSv4 Pseudofilesystem to export" textfield is to be used only upon creating a new NFS export - which is why after the first add, there are two entries added to the export list: one is the pseudofilesystem root, the other is the actual export that handles the directory I wanted to share.

So, I suspect this use of $via_pfs may have been a shortcut, so that respective UI elements are disabled, so as not to confuse users with parameters that may not be relevant at a given stage - however, the resulting lack of persistence of the NFS is, I'd argue, even more confusing to users. (Because of such a confusion, I may have ended up giving a wrong comment on Webmin / Bugs / #4142 NFS Mount Error). Then again, when I check:

$ git log exports/edit_export.cgi
commit fc1c1b243f7973c222c0b3a2d1f0ab45af485397
Author: Jamie Cameron <jcameron@webmin.com>
Date:   Thu Apr 12 20:24:50 2007 +0000

    Initial checkin of Webmin

... it turns out this file hasn't been changed since initial checkin; so I don't really know what to think.

In any case, I think a more proper UI handling is needed in this case of displaying NFS export related properties.

[Jamie Cameron]

Would you be able to craft a patch to fix this? I'd be happy to accept it into the webmin project at github.

[sdaau]

Hi Jamie,

Many thanks for the response!

In principle, I'd love to - however, the problem is that I don't really understand NFS; so I'm not really sure how a GUI for NFS should behave in the first place!

The only thing I have so far is this:

diff --git a/exports/edit_export.cgi b/exports/edit_export.cgi
index 1af01a4..0750e70 100755
--- a/exports/edit_export.cgi
+++ b/exports/edit_export.cgi
@@ -6,9 +6,9 @@ require './exports-lib.pl';
 &ReadParse();
 local $via_pfs = 0;
 local $nfsv = nfs_max_version("localhost");
+$via_pfs = ($nfsv == 4) ? 1 : 0;
 if ($in{'new'}) {
        &ui_print_header(undef, $text{'create_title'}, "", "create_export");
-       $via_pfs = ($nfsv == 4) ? 1 : 0;
        $exp->{"pfs"} = "/export";
     }
 else {

However, as noted in the OP, this has a side issue of "opening" the NFS psf root field, and I'm not really sure how that is supposed to be handled. Also there is the issue of save_export.cgi changing the value of via_pfs, which I don't understand as of yet.

The thing is, I want to set up a renderer project which will work on several Linux PCs, but render from a single folder on one PC, and into a single folder again on the same PC; and so I wanted to avoid overheads of say ssh mounting, which is why I wanted to look into NFS to begin with. However, anything I found online in regards to command line NFS setup I found incredibly complex to handle (maybe because I'm focused more on my rendering problem); the only reason I even started understanding NFS was because of the GUI present in webmin, for which I am thankful!

What I'll do, is I'll try to use webmin - with the hack above - to set up this rendering project, and see how it goes; and see if it makes me learn something more about NFS in general. If all goes well, and I get a sense of what should the correct behavior of the GUI be, then I'll code a patch and submit it here. However, it may be months (or even longer) before I get to do this - so if anyone else jumps in before that with a solution, I will not complain :) Also, if I find some small things that may be relevant to this problem, I'll post them here sporadically.

Cheers!

[Jamie Cameron]

Ok, let me know how it goes, and if it works OK send me a patch.

[sdaau]

I now think the biggest problem here is conceptual: if you add/edit a v4 export, that means you add/edit your standalone export share and a (standalone) pseudoroot share; if you add/edit a v3 export, you deal with a standalone share (without a pseudoroot parent). Noobs like me, not knowing this, end up understanding v3 upon edit, when v4 was selected upon save, as reverting of the value that was explicitly set.

So maybe all this is about alerting us noobs, that all is fine with NFS version globally, and that the radio buttons refer to the current export being dealt with; I think something like the following patch would do it:

diff --git a/exports/edit_export.cgi b/exports/edit_export.cgi
index 1af01a4..25100ce 100755
--- a/exports/edit_export.cgi
+++ b/exports/edit_export.cgi
@@ -1,4 +1,4 @@
-#!/usr/local/bin/perl
+#!/usr/bin/perl
 # edit_export.cgi
 # Allow editing of one export to a client

@@ -75,9 +75,11 @@ print "<tr $cb> <td><table>\n";
 # Show NFS pseudofilesystem (NFSv4)
 if ($nfsv == 4) {
     print "<tr> <td>",&hlink("<b>$text{'edit_nfs_vers'}</b>","vers"),"</td>\n";
-    printf "<td colspan=3><input type=radio name=via_pfs value=1 %s onclick=enable_pfs(1)> 4\n",
+    local $gnfsvs = "Global: v$nfsv ; ";
+    local $ecs = "Current export:";
+    printf "<td colspan=3>$gnfsvs$ecs<input type=radio name=via_pfs value=1 %s onclick=enable_pfs(1)> 4 [<i
     $via_pfs ? "checked" : "";
-    printf "<input type=radio name=via_pfs value=0 %s onclick=enable_pfs(0)> 3 (or lower)</td> </tr>\n",
+    printf "<input type=radio name=via_pfs value=0 %s onclick=enable_pfs(0)> 3 (or lower) [<i>standalone</i
     $via_pfs ? "" : "checked";

     print "<tr> <td>",&hlink("<b>$text{'edit_pfs'}</b>","pfs"),"</td>\n";

How does this look? If I come up with something else as I learn more later, I might post here again...

Cheers!