GNU bug report logs - #47706
nfs mount in file-system works only if "nfs4" type is used for "mount" syscall

Previous Next

Package: guix;

Reported by: fsdfsdfsd3 <fsdfsdfsd3 <at> protonmail.com>

Date: Sun, 11 Apr 2021 10:46:02 UTC

Severity: normal

Tags: patch

Merged with 39770

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#47706; Package guix. (Sun, 11 Apr 2021 10:46:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to fsdfsdfsd3 <fsdfsdfsd3 <at> protonmail.com>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Sun, 11 Apr 2021 10:46:02 GMT) Full text and rfc822 format available.

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

From: fsdfsdfsd3 <fsdfsdfsd3 <at> protonmail.com>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: nfs mount in file-system works only if "nfs4" type is used for
 "mount" syscall
Date: Sun, 11 Apr 2021 08:33:34 +0000
[Message part 1 (text/plain, inline)]
Hello,

I ran into an issue with trying to mount an nfs file-system in an operating-system config.. I managed to trace it back to being an issue with the mount syscall.

The following did not work:
(mount "192.168.1.10:/nas-server" "/mnt/nas-client" "nfs" 0 "addr=192.168.
1.10")
and would result in an error "No route to host"

I changed the type from "nfs" to "nfs4" however and this did work (For context; at the command line, both mount.nfs and mount.nfs4 also work fine., mount.nfs also works fine without nfs-utils installed).

This might be fixable by adding another check-procedure option for "nfs4" in addition to nfs, but I am sending it your way in case there is something else going on.

Thank you!
[Message part 2 (text/html, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#47706; Package guix. (Wed, 14 Apr 2021 14:19:03 GMT) Full text and rfc822 format available.

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

From: fsdfsdfsd3 <fsdfsdfsd3 <at> protonmail.com>
To: "47706 <at> debbugs.gnu.org" <47706 <at> debbugs.gnu.org>
Subject: bug#47706: Acknowledgement (nfs mount in file-system works only if
 "nfs4" type is used for "mount" syscall)
Date: Wed, 14 Apr 2021 06:56:04 +0000
[Message part 1 (text/plain, inline)]
Hello,

I ended up testing my config file with nfs4 and that part did work fine. I had earlier errors unrelated to this that threw me off thinking that would not work.

To clarify then, the issue here only seems to be with the mount function in the (guix build syscalls) module. This results in a "No route to host" error even though mount.nfs works fine on the command line.

However perhaps I am assuming that mount.nfs does not make use of nfs4 behind the scenes, even without nfs-utils installed, when it does.

Thank you!
[Message part 2 (text/html, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#47706; Package guix. (Sun, 08 Aug 2021 03:20:01 GMT) Full text and rfc822 format available.

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: fsdfsdfsd3 <fsdfsdfsd3 <at> protonmail.com>
Cc: 47706 <at> debbugs.gnu.org
Subject: Re: bug#47706: nfs mount in file-system works only if "nfs4" type
 is used for "mount" syscall
Date: Sat, 07 Aug 2021 23:19:14 -0400
[Message part 1 (text/plain, inline)]
Hello,

fsdfsdfsd3 <fsdfsdfsd3 <at> protonmail.com> writes:

> Hello,
>
> I ran into an issue with trying to mount an nfs file-system in an operating-system config.. I managed to trace it back to being an issue with the mount syscall.
>
> The following did not work:
> (mount "192.168.1.10:/nas-server" "/mnt/nas-client" "nfs" 0 "addr=192.168.
> 1.10")
> and would result in an error "No route to host"
>
> I changed the type from "nfs" to "nfs4" however and this did work (For context; at the command line, both mount.nfs and mount.nfs4 also work fine., mount.nfs also works fine without nfs-utils installed).
>
> This might be fixable by adding another check-procedure option for "nfs4" in addition to nfs, but I am sending it your way in case there is something else going on.
>
> Thank you!

Does this really work?  I seem to recall that the bigger problem would
be that file system services do *not* and cannot currently depend on
networking (while NFS obviously does).

Here's the attached output of

$ guix system shepherd-graph gnu/system/examples/bare-bones.tmpl \
  | dot -Tsvg -oout.svg

[out.svg (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
We can see that the networking service dependency chain has:

networking --> user-processes --> user-homes --> file-systems

Which to me suggests that it wouldn't be enough to fix the problem you
reported above (or perhaps it is?  and NFS would simply fail during the
boot but keep trying until networking becomes available without too much
of an issue?)

Thanks,

Maxim

Merged 39770 47706. Request was from Maxim Cournoyer <maxim.cournoyer <at> gmail.com> to control <at> debbugs.gnu.org. (Sun, 08 Aug 2021 03:51:02 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 309 days ago.

Previous Next


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