Excalibur: Mounting NFS shares using /etc/fstab

Andre4freedom · 2025-11-03 13:40:09

Hello,
has anyone encountered the problem too?
In Daedalus I had entries in /etc/fstab to mount NFS shares from the server at boot, and this worked fine.
No longer in Excalibur. I have tried with OpenRC / Excalibur. I couldn't solve the problem with mount-options nor with sysv-init. Upgrade, Fresh Install, fiddling... no success.
I have to mount (sudo mount -a) after login to access my files.
Just curious..... any hint is appreciated. Thanks.

fsmithred · 2025-11-03 15:57:48

I gave up using fstab to mount nfs shares a few years ago. I think it was because of problems if the server or the client rebooted. I use autofs now. It auto-mounts the share when you access the share. Simple config desribed here: https://dev1galaxy.org/viewtopic.php?pid=58917#p58917

I use these options in /etc/export. It looks like I added 'sync' either in daedalus or excalibur. (I don't have a daedalus to check right now.)

(rw,sync,no_subtree_check,crossmnt)

rolfie · 2025-11-03 17:00:32

Me too. I don't use fstab, I wrote a cron script that is executed @reboot on the clients. My setup is a bit special anyhow. The server is shut down at nigth when all clients are off, and woken up in the morning by the first client in the morning. It checks if the network is available, if the server can be pinged, if the shares have been setup. Then the shares are mounted on the client(s). Server and clients are encrypted, the server is on a RAID6.

ralph.ronnquist · 2025-11-03 23:06:06

@Andre4freedom: please show the error log, from the boot with fstab set up as in your daedalus. (It's awfully hard to just guess)

Probably logged to /var/log/dmesg and/or /var/log/syslog.

Andre4freedom · 2025-11-04 14:44:31

Thank you for your reaction, Ralph.
Of course, I have searched the files (dmesg and syslog) for these problems and found not a hint.
I could never get that autofs-thing to work, only a tiny part of it. Sometimes.... So I postpone my research.
I have temporarily switched to Linux Mint. There /etc/fstab still works correctly.
BTW: Daedalus did not show the problem, only excalibur.
I will pick up the task again, later.

I tried with these help-files:
https://thelinuxcode.com/mount-filesyst … ng-autofs/
https://cloudspinx.com/how-to-automatic … th-autofs/

Andre4freedom · 2025-11-04 17:10:43

@ralph.ronnquist
I could install excalibur on a spare machine.
Excalibur-openrc-cinnamon-nfs-common

I have extracted 3 log files: dmesg, syslog, boot
Where can I post or send this files?
I found no hints in them at all.

NB, the same problem again, no NFS resource is mounted at boot. But,

sudo mount -a

mounts the all
Thanks for your efforts.

steve_v · Yesterday 08:57:00

Without logs, crystal ball says boot service ordering issue - i.e. netmount runs before network is up. Especially likely if using some newfangled network "manager" rather than ifupdown.

Where can I post or send this files?

Any pastebin or fileshare service that isn't obnoxious... or just use pastebinit.

Andre4freedom · Yesterday 10:19:24

@steve_v : Thank you.
I have tried my luck to upload some files. You can find them here (hopefully):

(dmesg):
https://pastebin.com/V3iQa77z

(fstab):
https://pastebin.com/HiGjWMAj

(hosts):
https://pastebin.com/hX8evCQY

(syslog):
https://pastebin.com/UvuWqyVw

(boot-log):
https://pastebin.com/s6tumGik

Thank you for volunteering into that mystery.
Sincerely, Andre4Freedom

steve_v · Yesterday 11:35:14

Tue Nov 4 17:25:19 2025: Starting network connection manager: NetworkManager.

I suspected as much.

The traditional ifupdown setup runs /etc/network/if-up.d/mountnfs to scan fstab once the network interface is up.
I don't have a Devuan install with NetworkMangler to check, but IIRC NM should call the same via /etc/NetworkManager/dispatcher.d/01-ifupdown...

Which is suspiciously absent in the Excalibur package.

Poking about...

network-manager (1.44.2-2) unstable; urgency=medium
NetworkManager or rather NetworkManager-dispatcher will no longer execute
ifupdown hook scripts from /etc/network/if-*.d/ on network state changes.
Packages that want to be notified and react on such network state changes
are advised to ship native NetworkManager scripts in
/usr/lib/NetworkManager/dispatcher.d.
Users may provide local hook scripts or override package provided ones by
installing those into /etc/NetworkManager/dispatcher.d.
For further information about the NetworkManager-dispatcher interface see
the NetworkManager-dispatcher(8) man page.
-- Michael Biebl <biebl@debian.org> Wed, 18 Oct 2023 13:55:54 +0200

I don't use the thing myself, perhaps someone who does might explain how mountnfs is intended to be called by NM now (sans systemd, which would otherwise handle all this)? I dont see a new dispatcher hook file in initscripts (which provides /etc/network/if-up.d/mountnfs), or the Excalibur network-manager package itself.

@ralph.ronnquist: Unless I'm missing some other mechanism, I don't see how the setup in Excalibur is going to work as packaged, at least without a bunch of (somewhat arcane) end-user shenanigans creating a new hook to call mountnfs.
NFS in fstab isn't unusual and should really work OOTB for the default desktop install, was this configuration tested prior to release?

Last edited by steve_v (Yesterday 12:21:27)

Andre4freedom · Yesterday 13:52:00

Thank you, steve_v and ralph.ronnquist!
That shows that something is wrong with the default setup.
I will try to find a solution (not sure if I'm up to it).
When and if solved, I will let you know, and post the solution.
Have a good day, andre4freedom

ralph.ronnquist · Yesterday 22:56:54

Traditionally, NFS mounts are set up as declared in fstab via the init script mountnfs.sh, and it's not as a side effect of networking. That kind of NFS mount is supported with sysvinit, and it works as fine with excalibur as it has done with prior repository codenames.

Clearly one may insist on some different NFS mount behaviour.. In such a case one will need to set up the system to support that.

steve_v · Today 04:32:06

ralph.ronnquist wrote:

NFS mounts are set up as declared in fstab via the init script mountnfs.sh, and it's not as a side effect of networking.

Here is initscripts: /etc/init.d/mountnfs.sh

#! /bin/sh
### BEGIN INIT INFO
# Provides:          mountnfs
# Required-Start:    $local_fs
# Required-Stop:
# Should-Start:      $network $portmap nfs-common  udev-mtab
# Default-Start:     S
# Default-Stop:
# Short-Description: Wait for network file systems to be mounted
# Description:       Network file systems are mounted by
#                    /etc/network/if-up.d/mountnfs in the background
#                    when interfaces are brought up; this script waits
#                    for them to be mounted before carrying on.
### END INIT INFO

. /lib/init/vars.sh
. /lib/init/mount-functions.sh
. /lib/lsb/init-functions

do_wait_async_mount() {
	# Read through fstab line by line. If it is NFS, set the flag
	# for mounting NFS file systems. If any NFS partition is found
	# then wait around for it.

	waitnfs=
	for file in $(fstab_files); do
		if [ -f "$file" ]; then
			while read DEV MTPT FSTYPE OPTS REST; do
				case "$DEV" in
				  ""|\#*)
					continue
					;;
				esac
				case "$OPTS" in
				  noauto|*,noauto|noauto,*|*,noauto,*)
					continue
					;;
				esac
				case "$FSTYPE" in
				  nfs|nfs4|smbfs|cifs|coda|ncp|ncpfs|ceph)
					;;
				  *)
					continue
					;;
				esac
				case "$MTPT" in
				  /usr/local|/usr/local/*)
					;;
				  /usr|/usr/*)
					waitnfs="$waitnfs $MTPT"
					;;
				  /var|/var/*)
					waitnfs="$waitnfs $MTPT"
					;;
				esac
			done < "$file"
		fi
	done

	# Wait for each path, the timeout is for all of them as that's
	# really the maximum time we have to wait anyway
	TIMEOUT=900
	for mountpt in $waitnfs; do
		log_action_begin_msg "Waiting for $mountpt"

		while ! mountpoint -q $mountpt; do
			sleep 0.1

			TIMEOUT=$(( $TIMEOUT - 1 ))
			if [ $TIMEOUT -le 0 ]; then
				log_action_end_msg 1
				break
			fi
		done

		if [ $TIMEOUT -gt 0 ]; then
			log_action_end_msg 0
		fi
	done
}

case "$1" in
    start)
        # Using 'no !=' instead of 'yes =' to make sure async nfs
        # mounting is the default even without a value in
        # /etc/default/rcS
        if [ no != "$ASYNCMOUNTNFS" ] ; then
                do_wait_async_mount
        else
                FROMINITD=yes /etc/network/if-up.d/mountnfs
        fi
        ;;
    restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;
    stop|status)
        # No-op
        ;;
    *)
        echo "Usage: $0 start|stop" >&2
        exit 3
        ;;
esac

:

Feel free to point out where it mounts NFS filsystems "not as a side effect of networking", because I sure don't see any calls to /bin/mount, and the header quite clearly contradicts your statement:

# Description:       Network file systems are mounted by
#                    /etc/network/if-up.d/mountnfs in the background
#                    when interfaces are brought up

That sure sounds like a "side effect of networking" to me (and it needs to be, since starting networkmanager doesn't indicate whether or not it successfully brought up an interface via exit codes, rather it backgrounds immediately expecting systemd to query status over dbus).

All that init script does is loop until the filesystems exist in /proc/self/mountinfo, so that other scripts can use it as a dependency. Actually mounting NFS filesystems is handled by:
a) systemd network.target, if /run/systemd/system exists.
b) /etc/network/if-up.d/mountnfs, as called by ifup.
c) /etc/network/if-up.d/mountnfs, as called by networkmanager-dispatcher.

a) is obviously not going to happen
b) is not how the OPs system is configured, they're not using ifup / /etc/network/interfaces.
c) is broken in Excalibur, because Debian networkmanager behaviour has changed (since Debian uses option a now) and no replacement has been shipped.

ralph.ronnquist wrote:

That kind of NFS mount is supported with sysvinit, and it works as fine with excalibur

Well unless Andre4freedom is just making things up, it clearly does not when the network is managed by networkmanager.
If you don't want to actually look at the logs you asked for, read the shell scripts you reference, or offer any constructive advice... You do you.

@Andre4freedom: You might try grabbing that missing file (/etc/NetworkManager/dispatcher.d/01-ifupdown) from the Daedalus network-manager package. Like I said I don't have a system to test it on, but the manual suggests networkmanager should still call it if it exists.
Add some printfs (or drop a 'set -x' for mondo verboseo) in the relevant scripts if you need more info on what is going on... There are no NFS related errors in your logs, and I'm pretty confident that's because nothing is even trying to mount NFS right now.

Last edited by steve_v (Today 06:09:17)

ralph.ronnquist · Today 06:50:31

Indeed, it seems prepared for random asynchronous bootup when one has configured it so. Though it seems the default setup case is the invocation at line 90, where the hook script is used explicitly.

steve_v · Today 07:32:35

it seems the default setup case is the invocation at line 90

I read it the other way:

        # Using 'no !=' instead of 'yes =' to make sure async nfs
        # mounting is the default even without a value in
        # /etc/default/rcS

/etc/default/rcS as shipped with initscripts has '#ASYNCMOUNTNFS=yes', so

87          if [ no != "$ASYNCMOUNTNFS" ] ; then

is true, and the do_wait_async_mount loop runs until timeout or all mounts appear.

i.e. async mount (AKA just loop while waiting for the network initscript / manager / whatever to call the mountnfs hook) is default behaviour as per the comment, and /etc/init.d/mountnfs.sh only calls /etc/network/if-up.d/mountnfs itself if the user has explicitly disabled async mount.

...which neatly explains the conspicuous lack of attempts to mount NFS in Andre's logs on a fresh install with networkmanager, and the "works same as it always did" for those using ifup and static definitions in /etc/network/interfaces (me, and I suspect you as well).

Seems to me that if Devuan is going to use networkmanager in the default desktop install (connman is going away and all that) and we want fstab NFS mounts to work, the obvious solution would be for Devuan to fork the networkmanager package and put /etc/NetworkManager/dispatcher.d/01-ifupdown back where it belongs.

Last edited by steve_v (Today 08:23:41)

ralph.ronnquist · Today 08:49:41

Ha! You're right. I interpreted that condition wishfully rather than correctly.

So obviously, would I want to use nfs, I need to arrange for that by myself since I wouldn't find joy in associating nfs mounting with networking events.

And if I choose to install a system with a Devuan installer iso and select a desktop flavour that installs NetworkManager, I will need some additional post-install hands-on to purge that together with apparmor, avahi-daemon and whatnot that the desktop flavour developers have included at the outside of my ideal setup.

stargate-sg1-cheyenne-mtn · Today 10:00:54

while looking for tailscale references/commentary/notes/etc on the forum i came across this specific post:

https://dev1galaxy.org/viewtopic.php?pid=57261#p57261

which referenced /lib/init/init-d-script and so i went and saw that a bit of it referenced "mountnfs.sh" with some content/context referencing the words "after" and "before" and so i post the snippet of code here below:

# PATH should only include /usr/* if it runs after the mountnfs.sh
# script.  Scripts running before mountnfs.sh should remove the /usr/*
# entries.
PATH=/usr/sbin:/usr/bin:/sbin:/bin

also at the end of /lib/init/init-d-script there was a reference to:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822753#53

and that link drops one into the midst of just one of many "discussions" which seem not so distant from some of those on this forum...(*cough* hat-tip @steve_v)

as always, ymmv.

edited to add: also wanted to quote a snippet from message#36 in the same above noted "discussion"

Wait, no. There is. See #427889 and policy 9.3.2. By the way, seems
#427889 could be closed...
Also, by just common sence, program that return 0 in case of failure is
bad, very bad. What if I want to call /etc/init.d/{foo} in my own
script?
There are scripts around, that pass exit code {rc.local, hostname}; there
are scripts around, that do not (random example - wicd).
So either we
* violate LSB and adjust all initscripts to return 0 always.
I strongly oppose.
* consider script, that swallows exit code to be buggy. I support it,
but there is a lot of scripts in wild that do so. I do /not/ volonteer
to fix them.
All in all, let us remove last line in `init-d-script'.

Dmitry Bogatov may *not* volonteer(sic) to _fix_ them...nevertheless, there be dragons...sigh.

Last edited by stargate-sg1-cheyenne-mtn (Today 10:10:38)

Andre4freedom · Today 13:25:43

@steve_v
You are true hero, you have nailed it.
I did as you suggested and placed that script /etc/NetworkManager/dispatcher.d/01-ifupdown to the right place and rebooted. And sure enough: BINGO.
Thank you for that precious hint.

@ralph.ronnquist
I did the tests on a spare machine, doing a fresh-install with the excalibur-netinstall-iso and running the the devuan installer's first option: install
Test 1: Excalibur - Cinnamon - OpenRC
Test 2: Excalibur - Cinnamon - sysvinit
In both cases I just edited the hosts file, the fstab, created the mountpoints and rebooted. In both cases NFS was not mounted.

Copying the famous file /etc/NetworkManager/dispatcher.d/01-ifupdown from my local server (daedalus) to the test machine did the trick..
BTW: Editing the /etc/rc.local file didn't change a thing.

Would you like me to write a simple procedure (a text file) how to fix that problem? Then, where could I send it for inclusion to the release readme file?

Unfortunately I'm not able to fix the networkmanager package.

Once again, to all of you: Thank you for your help.
Sincerely, Andre (andre4freedom)

Andre4freedom · Today 13:34:52

And just a little side-note:
Due to the situation I installed temporarily Linux Mint 22.2 to be able to work. This morning was the first time that my machine hung, just freezed, X11, text consoles, keyboard, mouse - all dead. That machine has never ever done that with Devuan running all these years. How happy I am to re-install Devuan - with your fix. You see, Devuan is worth making the effort and taking a few extra steps to resolve issues.
Happy Devuan

fsmithred · Today 14:06:42

Andre,

You could file a bug report against network-manager requesting that the missing file be restored. We already fork that package, so the report goes to bugs.devuan.org. I find email submission to be the easiest.

Instructions:
https://bugs.devuan.org/Reporting.html

The officially official Devuan Forum!

#1 2025-11-03 13:40:09

Excalibur: Mounting NFS shares using /etc/fstab

#2 2025-11-03 15:57:48

Re: Excalibur: Mounting NFS shares using /etc/fstab

#3 2025-11-03 17:00:32

Re: Excalibur: Mounting NFS shares using /etc/fstab

#4 2025-11-03 23:06:06

Re: Excalibur: Mounting NFS shares using /etc/fstab

#5 2025-11-04 14:44:31

Re: Excalibur: Mounting NFS shares using /etc/fstab

#6 2025-11-04 17:10:43

Re: Excalibur: Mounting NFS shares using /etc/fstab

#7 Yesterday 08:57:00

Re: Excalibur: Mounting NFS shares using /etc/fstab

#8 Yesterday 10:19:24

Re: Excalibur: Mounting NFS shares using /etc/fstab

#9 Yesterday 11:35:14

Re: Excalibur: Mounting NFS shares using /etc/fstab

#10 Yesterday 13:52:00

Re: Excalibur: Mounting NFS shares using /etc/fstab

#11 Yesterday 22:56:54

Re: Excalibur: Mounting NFS shares using /etc/fstab

#12 Today 04:32:06

Re: Excalibur: Mounting NFS shares using /etc/fstab

#13 Today 06:50:31

Re: Excalibur: Mounting NFS shares using /etc/fstab

#14 Today 07:32:35

Re: Excalibur: Mounting NFS shares using /etc/fstab

#15 Today 08:49:41

Re: Excalibur: Mounting NFS shares using /etc/fstab

#16 Today 10:00:54

Re: Excalibur: Mounting NFS shares using /etc/fstab

#17 Today 13:25:43

Re: Excalibur: Mounting NFS shares using /etc/fstab

#18 Today 13:34:52

Re: Excalibur: Mounting NFS shares using /etc/fstab

#19 Today 14:06:42

Re: Excalibur: Mounting NFS shares using /etc/fstab

Board footer