GNU bug report logs - #39770
mount-file-system fails to mount NFS file system

Previous Next

To reply to this bug, email your comments to 39770 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: maxim.cournoyer <at> gmail.com
To: bug-guix <bug-guix <at> gnu.org>
Subject: mount-file-system fails to mount NFS file system
Date: Mon, 24 Feb 2020 14:39:13 -0500

The mount-file-system call used in our init RAM disk (see: (gnu build
file-systems)) doesn't produce the correct system call as can be
demontstrated by the following C program:

--8<---------------cut here---------------start------------->8---
#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <sys/mount.h>

/* int mount(const char *source, const char *target, */
/* 	  const char *filesystemtype, unsigned long mountflags, */
/* 	  const void *data); */

int main() {
  //char *src = "192.168.51.34:/mnt/scratch/yocto-sstate";
  char *src = "192.168.51.34:/mnt/scratch/yocto-sstate";
  char *target = "/mnt/scratch/yocto-sstate";
  char *type = "nfs";
  unsigned long mountflags = 0;
  char *data = "addr=192.168.51.34";  //file system specific options

  int ret = 0;
  ret = mount(src, target, type, mountflags, data);

  if (ret == -1); {
    int errsv = errno;
    printf("mount() failed with error: %s\n", strerror(errsv));
  }
}

--8<---------------cut here---------------end--------------->8---

Running the program with strace, we can see that it failed with a
connection refused error:

--8<---------------cut here---------------start------------->8---
/* mount("192.168.51.34:/mnt/scratch/yocto-sstate", "/mnt/scratch/yocto-sstate", "nfs", 0, "addr=192.168.51.34") = -1 ECONNREFUSED (Connection refused) */
--8<---------------cut here---------------end--------------->8---


When having nfs-utils installed and tracing mount.nfs with:

--8<---------------cut here---------------start------------->8---
strace -f -s320 mount j1-slave1.sfl.team:/mnt/scratch/yocto-dldir /mnt/scratch/yocto-dldir -t nfs
--8<---------------cut here---------------end--------------->8---

We can see that the working invocation reads as:

--8<---------------cut here---------------start------------->8---
mount("j1-slave1.sfl.team:/mnt/scratch/yocto-dldir", "/mnt/scratch/yocto-dldir", "nfs", 0, "vers=4.2,addr=192.168.51.34,clientaddr=192.168.49.249")
--8<---------------cut here---------------end--------------->8---

It seems we're missing either a "vers" (doubtful) or more likely the
"clientaddr" option.

Maxim

Message #8 received at 39770 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: 39770 <at> debbugs.gnu.org
Subject: Re: bug#39770: mount-file-system fails to mount NFS file system
Date: Mon, 24 Feb 2020 16:21:21 -0500

[Message part 1 (text/plain, inline)]

Hi,

maxim.cournoyer <at> gmail.com writes:

[...]

> It seems we're missing either a "vers" (doubtful) or more likely the
> "clientaddr" option.

It turns out that the "vers" (or more specifically, "nfsvers") option
was mandatory to resolve this error.  What "mount.nfs" from
nfs-utils seems to do is start with "4.2", then retry upon errors lesser
versions.

The attached patch adds the required "nfsvers=4.2" option by default, or
honors a user specified one.  No retry is done.  Note that it currently
uses file system options represented as an alist, but this is likely to
change as the code review on "allow booting from a Btrfs subvolume"
progresses (the current patch is based atop of
<https://bugs.gnu.org/37305>).

Maxim

[0001-build-file-systems-Specify-a-nfsvers-option-by-defau.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.