Řešení 1:
Za předpokladu Linuxu:
umount -f -l /mnt/myfolder
Problém to nějak vyřeší:
-f Vynutit odpojení (v případě nedostupného systému NFS). (Vyžaduje jádro 2.1.116 nebo novější.)
-l Líné odpojení. Odpojte souborový systém od hierarchie souborového systému nyní a vyčistěte všechny odkazy na souborový systém, jakmile přestane být zaneprázdněn. (Vyžaduje jádro 2.4.11 nebo novější.)
-f existuje také v systémech Solaris a AIX.
Řešení 2:
Rozvíjíme nápovědu Davida Pashleyho,
pokud "umount -l" nevyřeší váš problém, můžete nastavit falešný server se stejnou adresou jako ten, který zmizel - ale ve skutečnosti nemusíte nastavovat nový server nebo tak něco. Nejjednodušší cestou ze situace blokování/nezastavení připojení je nastavení rozhraní IP místního aliasu , takto:
ifconfig eth0:nfstmp 11.22.33.44 netmask 255.255.255.255
umount -l /mnt/deadnfsmount # -l or -f or whichever that gets the job done
ifconfig eth0:nfstmp down
(samozřejmě 11.22.33.44 je (bývalá) IP adresa (nyní mrtvého) serveru NFS)
Řešení 3:
Možná by bylo rozumné přidat intr možnost libovolného /etc/fstab položky, které by mohly skončit zavěšením nebo zhroucením. Pokud nepoužíváte soft nebo intr volby, pak když server hostující soubory NFS selže, server, na kterém jsou soubory připojeny (klient), se může při spouštění zablokovat.
Podle man 5 nfs :
měkký / tvrdý
Určuje chování při obnově klienta NFS po vypršení časového limitu požadavku NFS. Není-li zadána žádná možnost (nebo je-li zadána pevná volba), požadavky NFS se opakují donekonečna. Pokud je zadána soft volba, pak klient NFS selže požadavek NFS po odeslání opakovaného přenosu, což způsobí, že klient NFS vrátí volající aplikaci chybu.
... a pak to pokračuje říkat intr je preferován před soft , ale má podobný účinek jako prevence před oběšením.
Řešení 4:
umount -f /mnt/myfolder by to mělo vyřešit. Viz manuálová stránka umount.