You are not logged in.
Hi, i have nfs shares, that i would like to mount on boot. Before switching to systemd i was using rc.local file.
Now, in fstab i have following line:
192.168.2.108:/home/bagheera/download /home/bagheera/share/debian/download nfs4 rsize=8192,wsize=8192,timeo=14,intr 0 0
systemctl logs
bagheera@tux:~$ sudo systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
home-bagheera-share-debian-download.mount loaded failed failed /home/bagheera/share/debian/download
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
bagheera@tux:~$ sudo systemctl status home-bagheera-share-debian-download.mount
home-bagheera-share-debian-download.mount - /home/bagheera/share/debian/download
Loaded: loaded (/etc/fstab)
Active: failed (Result: exit-code) since sob 2013-02-16 11:45:39 CET; 7min ago
Where: /home/bagheera/share/debian/download
What: 192.168.2.108:/home/bagheera/download
Process: 371 ExecMount=/bin/mount 192.168.2.108:/home/bagheera/download /home/bagheera/share/debian/download -t nfs4 -o rsize=8192,wsize=8192,timeo=14,intr (code=exited, status=32)
lut 16 11:45:39 tux mount[371]: mount.nfs4: mounting 192.168.2.108:/home/bagheera/download failed, reason given by server:
lut 16 11:45:39 tux mount[371]: No such file or directory
lut 16 11:45:39 tux systemd[1]: home-bagheera-share-debian-download.mount mount process exited, code=exited status=32
lut 16 11:45:39 tux systemd[1]: Failed to mount /home/bagheera/share/debian/download.
lut 16 11:45:39 tux systemd[1]: Unit home-bagheera-share-debian-download.mount entered failed state
In general, the share works, wen i issue command after system is fully booted, it mounts successfully:
mount 192.168.2.108:/home/bagheera/download /home/bagheera/share/debian/download
I suspect the reason is system is trying to mount share before network is set up. I use wicd network manager as dhcp client.
One solution is to run script on KDE boot, but how can i configure it correctly in systemd?
Last edited by bagheera (2013-02-24 09:38:26)
arch linux user
Offline
I have the nfs share mount shown below in my /etc/fstab. I will warn you though, if the server is down, and you are booting your client, for me it hangs on boot for ~2 min. I haven't been able to figure out why.
phobos:/media /mnt/media nfs4 x-systemd.device-timeout=8 0 0
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
Try adding _netdev mount option. AFAIK this is assumed for NFS, at least for v3, but anyways...
Offline
I have the nfs share mount shown below in my /etc/fstab. I will warn you though, if the server is down, and you are booting your client, for me it hangs on boot for ~2 min. I haven't been able to figure out why.
phobos:/media /mnt/media nfs4 x-systemd.device-timeout=8 0 0
I am aware of that. But that remote machine is always on on my basement.
arch linux user
Offline
I am aware of that. But that remote machine is always on on my basement.
OK... does formatting your mount this way solve your problem?
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
I first tried adding a timeout which worked ok but decided to go with the automount option which doesn't mount it till you try to access it.
# servername:/media/files /media/stuff nfs x-systemd.device-timeout=7s,soft,rsize=16384,wsize=16384,timeo=14,intr 0 0
servername:/media/files /media/stuff nfs noauto,x-systemd.automount,soft,rsize=16384,wsize=16384,timeo=14,intr 0 0
HTH
You're just jealous because the voices only talk to me.
Offline
Well, i changed line in fstab:
192.168.2.108:/home/bagheera/download /home/bagheera/share/debian/download nfs4 noauto,users,x-systemd.device-timeout=7s,rsize=8192,wsize=8192,timeo=14,intr 0 0
But, when i try to access share via kde dolphin, i get
An error occurred while accessing 'Katalog domowy', the system responded: mount.nfs4: mounting 192.168.2.108:/home/bagheera/download failed, reason given by server:
No such file or directory
From terminal:
bagheera@tux:~$ sudo mount 192.168.2.108:/home/bagheera/download
mount.nfs4: mounting 192.168.2.108:/home/bagheera/download failed, reason given by server:
No such file or directory
But i can mount a share by typing
sudo mount 192.168.2.108:/home/bagheera/download /home/bagheera/share/debian/download
Any idea on the solution?
Last edited by bagheera (2013-02-21 21:15:40)
arch linux user
Offline
Doesn't a mount command without specifying nfs4 use nfs3? Mounting nfs4 shares is different compared to mounting nfs3 shares.
Offline
That is a good point gsgleason, I would have to imagine that debian is likely not using nfs4, especially since it was big news that their new installer finally has ext4 as the default filesystem.
OP try using nfs instead of nfs4.
Offline
Well, i made a change, but it still doesn't work
An error occurred while accessing '/home/bagheera/download on 192.168.2.108', the system responded: mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified
192.168.2.108:/home/bagheera/download /home/bagheera/share/debian/download nfs noauto,users,x-systemd.device timeout=7s,rsize=8192,wsize=8192,timeo=14,intr 0 0
bagheera@tux:~$ sudo systemctl status rpcbind.service
rpcbind.service - RPC Bind
Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; enabled)
Active: active (running) since sob 2013-02-23 21:49:34 CET; 2h 9min ago
Process: 369 ExecStart=/usr/bin/rpcbind (code=exited, status=0/SUCCESS)
Main PID: 371 (rpcbind)
CGroup: name=systemd:/system/rpcbind.service
└─371 /usr/bin/rpcbind
lut 23 21:49:34 tux systemd[1]: Started RPC Bind.
Am I missing sth?
arch linux user
Offline
Did you try starting rpc-statd.service?
Offline
Bingo!
Problem solved. Thank You.
arch linux user
Offline
I've had the same problem recently. But delays didn't help me.
Maybe somebody will find my experience useful. In my case the problem was in that that systemd tried to mount the NFS share before rpc-statd.target even started. For a reason /usr/lib/systemd/system/rpc-statd.target didn't contain 'Wants=remote-fs-pre.target' line. And this target is a passive target which means no consumer would have pulled this target in (even systemd while reading /etc/fstab). So I added the line and after that systemd began to mount NFS shares only after rpc-statd had started.
I've filed a bug #72493 on systemd. I don't now maybe the designers will agree with me.
Offline