You are not logged in.
Hello,
I got the following configuration:
NFS-server: Always on, connected via LAN.
NFS-clients: 2 computers, connected via LAN and WLAN. On standby: auto umount NFS-share via system-sleep-hook with systemd.
This works flawlessly some hours or even days. But after some time, the following happens:
1. mount nfs-share: no error message
2a. trying to access that folder via filemanager, e.g. thunar: folder seems to be empty (it isn't on server!), but the correct freesize of the NFS-share on server is displayed in the statusbar.
2b. trying to access that folder via commandline:
$ ls
ls: reading directory .: Input/output errorThe very same worked just a few hours before, I haven't changed anything meanwhile. Apart from standby (--> auto umount NFS-share) and resume (manual mount NFS-share) on the clients which worked before, too.
Any idea what's going wrong?
additional info:
server:
/etc/exports
_______________________
/srv/nfs/myshare 192.168.2.0/24(rw,all_squash,anonuid=33,anongid=33,no_subtree_check)(yes, the mapping is needed and right.)
clients:
/etc/fstab
_______________________
servername:/srv/nfs/myshare /home/carl/nfs nfs4 noauto,soft,user,_netdev,timeo=14,rsize=8192,wsize=8192 0 0/usr/lib/systemd/system-sleep/umount-nfs
_______________________
#!/bin/sh
case $1 in
pre)
umount -f /home/carl/nfs
;;
esacLast edited by Carl Karl (2014-09-21 17:07:47)
Offline
Somehow your nfs mounts have gone stale. You'd need to remount them or restart nfs related services. Dmesg or syslog output may help.
I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.
Offline
Indeed, there could be something interesting in dmesg on the server:
[ 4.190117] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[ 4.190596] NFSD: starting 90-second grace period (net ffffffff818a9540)
[ 5.445237] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
[ 5.895519] r8169 0000:04:00.0 enp4s0: link up
[ 5.895529] IPv6: ADDRCONF(NETDEV_CHANGE): enp4s0: link becomes ready
[72346.265850] usb 3-1: USB disconnect, device number 2
[72346.670926] usb 3-1: new SuperSpeed USB device number 3 using xhci_hcd
[72346.684585] usb-storage 3-1:1.0: USB Mass Storage device detected
[72346.684716] scsi5 : usb-storage 3-1:1.0
[72347.686518] scsi 5:0:0:0: Direct-Access WD Elements 1048 1022 PQ: 0 ANSI: 6
[72347.687606] sd 5:0:0:0: [sdc] 976769024 512-byte logical blocks: (500 GB/465 GiB)
[72347.690295] sd 5:0:0:0: [sdc] Write Protect is off
[72347.690301] sd 5:0:0:0: [sdc] Mode Sense: 47 00 10 08
[72347.692981] sd 5:0:0:0: [sdc] No Caching mode page found
[72347.693025] sd 5:0:0:0: [sdc] Assuming drive cache: write through
[72348.135398] sdc: sdc1
[72348.141458] sd 5:0:0:0: [sdc] Attached SCSI disk
[72348.455737] EXT4-fs (sdc1): recovery complete
[72348.455919] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null)
[74276.020331] EXT4-fs error (device sda1): ext4_find_entry:1310: inode #14024711: comm nfsd: reading directory lblock 0
[74276.021107] EXT4-fs error (device sda1): ext4_find_entry:1310: inode #14024711: comm nfsd: reading directory lblock 0(last one repeats several times...)
Indeed, the NFS-share resists on a external WD harddrive connected via USB, /dev/sdc1.
As suggested in the NFS wiki article, the NFS-share is a bind-mount:
/etc/fstab on server:
_____________
(...)
# fake-root for NFS
/magnet/owncloud/data/carl/files /srv/nfs/myshare none bind,noauto,x-systemd.automountwhile /srv is on /dev/sda1.
The external harddrive has an auto-standby (NOT hdparm...) which isn't causing troubles with other services.
So it seems to be a problem connected to this bind-mount to external USB setup....
I'll try to find out whether there is a way to avoid that.
Thanks so far!
Last edited by Carl Karl (2014-09-16 14:30:02)
Offline
OK, I changed the fakeroot-directory now to be on the external-USB-harddrive /dev/sdc1, too.
For now, it works.
I'll inform you here whether it's working still in some hours, too...
Offline
That can change from time to time on those external mounts. Maybe you need a GUID mounting in /etc/fstab.
I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.
Offline
I use a label mount, so that won't cause troubles. :-)
I just used that notification to make it matchable to the dmesg output.
Offline
GUID mounts will make sure that the kernel doesn't swap it around.
I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.
Offline
OK, found the true cause of the trouble: These NFS problems were the first signs of a failing harddrive. The "ls: reading directory .: Input/output error" message appeared later on the server directly, too.
So I replaced the USB-harddrive by a SATA-harddrive (which is better any way), no more problems. :-)
Offline