I think I found a solution! For whatever reason, my network interface enp5s11 was not in the "auto" line in /etc/network/interfaces. After adding it there and a reboot, the filesystem is mounted correct without any of the x-systemd mount options.
Am Fr., 2. Juli 2021 um 19:30 Uhr schrieb Reiner Buehl < reiner.bu...@gmail.com>: > Hello, > > this is the full unit: > > # /etc/systemd/system/vdr.service > [Unit] > Description=Video Disk Recorder > > Wants=systemd-udev-settle.service > After=systemd-udev-settle.service > > [Service] > Type=notify > ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh "commands" > ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh "reccmds" > ExecStart=/usr/bin/vdr > Restart=on-failure > RestartPreventExitStatus=0 2 > > [Install] > WantedBy=multi-user.target > > # /etc/systemd/system/vdr.service.d/override.conf > [Unit] > After=remote-fs.target > Requires=remote-fs.target > > I only added the x-systemd options to /etc/fstab because the filesystems > where not mounted at boot time at all with the old fstab options that I > used before the upgrade to Debian (I did use yavdr before - a distro that > was based on a super old 12.x version of Ubuntu). There I just used > > 192.168.1.2:/video /video nfs > defaults,rsize=8192,wsize=8192,soft,nolock,noatime 0 0 > > If I try with this entry, the auto-generated video.mount unit fails as it > seems to be started too early: > > ● video.mount - /video > Loaded: loaded (/etc/fstab; generated) > Active: failed (Result: exit-code) since Fri 2021-07-02 19:26:02 CEST; > 2min 46s ago > Where: /video > What: 192.168.1.2:/video > Docs: man:fstab(5) > man:systemd-fstab-generator(8) > > Jul 02 19:26:02 vdr systemd[1]: Mounting /video... > Jul 02 19:26:02 vdr mount[403]: mount.nfs: Network is unreachable > Jul 02 19:26:02 vdr systemd[1]: video.mount: Mount process exited, > code=exited, status=32/n/a > Jul 02 19:26:02 vdr systemd[1]: video.mount: Failed with result > 'exit-code'. > Jul 02 19:26:02 vdr systemd[1]: Failed to mount /video. > > Best regards, > Reiner > > Am Fr., 2. Juli 2021 um 19:15 Uhr schrieb Reco <recovery...@enotuniq.net>: > >> Hi. >> >> On Fri, Jul 02, 2021 at 06:12:58PM +0200, Reiner Buehl wrote: >> > I have a directory that is mounted via NFS from a remote server. >> >> Actually, you have an autofs mountpoint, because you set >> x-systemd.automount option in fstab. >> Only if something starts using that mountpoint an NFS filesystem should >> be mounted there. >> >> In another words - you do not require your NFS filesystem to be mounted >> at boot time, and thus remote-fs.target does not include your NFS >> filesystem. >> >> >> > If I boot the vdr daemon fails during startup with the error message >> >> In other words, vdr fails to trigger automounting of the filesystem in >> question. As usual with journald, the actual reason of this is not >> present in this log. >> >> >> > The vdr.service has an override of >> > >> > [Unit] >> > After=remote-fs.target >> > Requires=remote-fs.target >> > >> > to ensure that the filesystem is mounted. >> >> These dependencies are useless for your service given the current state >> of your fstab. >> The reason being - "autofs" filesystems belong to local-fs.target, not >> remote-fs.target, and explicitly depending on local-fs.target is useless >> anyway (it's one of the default dependencies for the most units). >> What you probably need here is a dependency for a .mount unit >> corresponding to your NFS filesystem. >> >> >> > If I try to restart vdr.service, it fails again with the same error but >> if >> > I just cd to the directory and then try to restart it, it starts and >> works >> > fine. >> >> Can you show the result of "systemctl cat vdr" please? >> >> > What is systemd doing here that blocks the mount point for the vdr >> process? >> >> Many things are possible here. You have ProtectSystem=full set in unit, >> or you have PrivateMounts=true set in there. >> >> > Do I need different fstab options? >> >> It depends. x-systemd.automount is useful, because it does not require >> your NFS server to be present at boot time. >> I'll refrain from suggesting certain hacks for now, I'd like to see your >> unit in full first. >> >> Reco >> >>
