OpenSuse Tumbleweed sluit niet af bij NFS-client

Nederlands (Dutch) Netwerk/Internet
1

Hallo,

Ik ben nieuw in OpenSuse en heb een voor mij lastig probleem. Bij het instellen van NFS, ik wil namelijk de shares van mijn Synology server mounten, hangt OpenSuse bij het afsluiten. Zodra ik in Yast de NFS-client verwijder loopt alles weer normaal.

IN Ubuntu werkte de door mij gebruikte Fstab-regel wel prima.

servername:dir /mntpoint nfs rw,hard,intr 0 0

Welke ‘options’ ik ook gebruik, bij het afsluiten ‘hangt’ OpenSuse. Misschien heb ik de juiste combinatie nog niet gevonden? Het nadeel van dit 'hangen’is dat nu al twee keer mijn systeempartitie (btrfs) corrupt is geraakt. Dit is wel op te lossen met een Live CD en Gparted, maar fijn is anders.

Is er een andere methode in OpenSuse die mijn shares via NFS mount waardoor mijn syteem niet ‘hangt’ bij afsluiten of is er een andere oplossing?
Alvast bedankt voor het meedenken.

Gr,

Martin

2

Hallo,

Helaas ben je zo geobsedeerd door je probleem, dat je vergeten bent te beginnen met te vertellen welke versie van openSUSE je gebruikt.

3

Ah, sorry, Laatste Tumbleweed, is dat dan 13.2? Of krijgt dit een andere versie mee?

4

Dat is dan zoiets als 13.2+ denk ik. Maar het is zekert van belang dat je vertelt dat je Tumbleweed gebruikt.

Ik ben geen Tumbleweed gebruiker en zal dan ook niet proberen te antwoorden.

5

OK.
Ik vraag mij af of ‘Tumbleweed’ het probleem is. Voor zover ik mij kan herinneren heb ik bij een eerdere poging met 13.2 hetzelfde probleem gehad. Ik zal vanavond eens OpenSuse 13.2 installeren. Kijken of ik het probleem onder 13.2 kan reproduceren.

6

Dag, hier NFS en Tumbleweed en zonder dat verschijnsel. Maar … wat staat er op de NFS share? Ik heb bij een klant meegemaakt dat mysql sockets niet werden vrijgegeven, en dat daardoor NFS niet kon afsluiten.

Vergelijk openSUSE maar niet teveel met Ubuntu. Canonical (zo mocht ik van 't weekend ook weer ontdekken) kiest er soms voor om dingen net even anders te doen.

Meteen daarover door: openSUSE heeft Yast. En Yast heeft zowel voor NFS-client als NFS-server prachtige configuratie modules. Gebruik die, dan weet je in ieder geval dat de syntax in de diverse configuratie bestanden goed is. Ga bij NFS alsjeblieft niet experimenteren met op het web geadverteerde “oplossingen” als locking uitzetten Nz., voor je 't weet is er dan een mismatch tussen server en client, wat bijv. voor Kontact ( met z’n databases, de mail in ~/.local ) kan zorgen voor inconsistentie.

Een heel groot probleem is 't overigens niet, immers een server die NFS draait moet altijd aan :smiley:

7

Oeps, ik heb gedacht dat het de clients zijn die blijven hangen.

Ik heb de eerste post nu herlezen. Volgens mij is de server Synology (wat dat ook moge zijn, maar ik interpreteer dat als: geen openSUSE). En dan staat er dat OpenSUSE (sic) ‘hangt’ bij afsluiten. Inderdaad een beetje vaag. Ik heb dit gelezen als: de (een? iedere) openSUSE client hangt bij shutdown (afsluiten mag dan goed Nederlands zijn, maar welke vertaling past daar in dit geval bij? Shutdown, Logout???)

Tja, we zijn allemaal geneigd om gezellige borrelpraat hier te tikken, maar wat we nodig hebben zijn droge, exacte beschrijvingen. >:(

8

Even een NFS share aangekoppeld op mijn laptop (Tumbleweed) via Yast - Networkservices - NFS client, en dan komt deze regel in mijn fstab:


192.168.178.100:/disk/Muzickx   /Muzickx        nfs     defaults 0 0

mount geeft dan


192.168.178.100:/disk/Muzickx on /Muzickx type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.178.102,local_lock=none,addr=192.168.178.100)

Die “defaults” kun je vinden in /etc/nfsmount.conf
Ik heb ook even een paar keer gereboot, niks aan de hand.

Wat voor NFS versie draait de NAS overigens?

9

Even voor de volledigheid: op mijn laptop staat Opensuse Tumbleweed 13.2 (Gnome Shell), en daar wil ik de shares van mijn Synology nas op mounten. Dat doe ik in eerste instantie ook via YAST –> NFS-Client. Dat werkt inderdaad mooi. Na configuratie worden ook direct de shares gemount. Mountloctie is de op /server/<shares>. Er zijn meerdere gebruikers op mijn laptop die van deze shares gebruikmaken. Mijn SSd is niet al te groot dus wil ik grag dat iedereen zijn spullen netjes op de nas opslaat.

Ik stel ook verder geen eisen aan de verbinding en voor mij werkt de default setting prima.

192.168.1.10:/volume1    /server/<shares>    nfs    defaults 0 0

Dat wijkt dus niet veel af van hoe jij je shares mount.

Ah, dus als ik je goed begrijp worden de ‘defaults’ niet bepaald door NFS4 (versie server), maar door de nfsmount.conf. In die file staat alles nog ‘uitgecomment’
Ik moet Ubuntu dus vergeten (daarom ben ik ook overgestapt naar OpenSuse), maar hoe weet ik nu welke ‘options’ in Opensuse werkenmet mijn server? Ik kwan meestal niet verder dan:

192.168.1.10:/volume1    /server/<shares>    nfs    rw,hard,intr 0 0
10

Kun je de output 's posten, tussen CODE tags (# in de opmaakbalk):


grep nfs /etc/fstab

en

mount | grep nfs

?

Kopiëren de andere gebruikers alleen dingen, of heb je /home op de NAS staan? Of per gebruiker /home/gebruiker?

11

Alle gebruikes maken van de zelfde shares gebruik. Op de Synology is ‘squash’ toegewezen aan admin.
grep nfs /etc/fstab geeft:

martin@linux-v0az:~$ grep nfs /etc/fstab
192.168.1.10:/volume1/music    /server/music    nfs    defaults 0 0 
192.168.1.10:/volume1/homes    /server/homes    nfs    defaults 0 0 
192.168.1.10:/volume1/public    /server/public    nfs    defaults 0 0 
192.168.1.10:/volume1/photo    /server/photo    nfs    defaults 0 0 
192.168.1.10:/volume1/transmission    /server/transmission    nfs    defaults 0 0

mount | grep nfs geeft:

martin@linux-v0az:~$ mount | grep nfs
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
192.168.1.10:/volume1/music on /server/music type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.10,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.1.10)
192.168.1.10:/volume1/homes on /server/homes type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.10,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.1.10)
192.168.1.10:/volume1/public on /server/public type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.10,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.1.10)
192.168.1.10:/volume1/photo on /server/photo type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.10,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.1.10)
192.168.1.10:/volume1/transmission on /server/transmission type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.10,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.1.10)

NFS is versie 3 maar kan op de server ingesteld worden op versie 4.

12

Herinstallatie gedaan en voor de systeempartitie niet de standaard geselecteerde Btrfs gebruikt maar EXT4. Probleem lijkt daarmee opgelost. Aantal keer gestart en afgesloten, gen probleem meer! Raar!.
EXT4 dan maar. Is dit te verklaren? In ieder geval bedankt voor het meedenken.

13

Het probleem is denkelijk niet NFS, maar iets in de systemd configuratie. Wat er gebeurt is het volgende: je laptop ( kwam ik pas bij nalezen achter) gebruikt NetworkManager. Bij het opstarten laat systemd de nfs service (de client) netjes wachten tot het netwerk er is, dwz NetworkManager verbinding gemaakt heeft. Maar, als jij (of een andere gebruiker) uitlogt verbreekt NetworkManager de netwerkverbinding. Vervolgens wil systemd netjes de shares unmounten, maar de serverkant geeft geen sjoege meer. Er staan hier in de forums wel posts over dit fenomeen, maar 't zou allemaal al lang gefixt moeten zijn. Je laptop gaat trouwens wel uit, na ~15 minuten wordt e.e.a. geforceerd.

Overigens kun je op een laptop beter XFS voor root gebruiken. Mijn btrfs root ging aan gort toen de accu van mijn laptop stuk ging zonder dat ik 't merkte. Toen ik de draad los trok was 't een acute stop, en kapot btrfs. Tegenwoordig is dat met een LiveCD of -stick te repareren.

Je kunt ook nog proberen om in de eigenschappen van de netwerkverbinding aan te geven bij de Algemene instellingen dat alle gebruikers van dat netwerk gebruik mogen maken. De verbinding wordt dan volgens mij niet dicht gesmeten als je uitlogt. Ik kijk ook nog even verder naar systemd.

14

Iets te snel geroepen, ook bij Ext4 blijft hij nu hangen.

Ik heb inderdaad voor ik hier kwam ook al een en ander gelezen. Inderdaad ook over systemd en autofs. Maar dat soort zaken gaan mij te ver.

Overigens kun je op een laptop beter XFS voor root gebruiken. Mijn btrfs root ging aan gort toen de accu van mijn laptop stuk ging zonder dat ik 't merkte. Toen ik de draad los trok was 't een acute stop, en kapot btrfs. Tegenwoordig is dat met een LiveCD of -stick te repareren.

Klopt, dt heb ik dus nu ook geregeld met btrfs door die geforceerde shutdowns. Daarom wilde ik even kijken hoe dit met ext4 ging. Maar XFS prevaleerd?

Je kunt ook nog proberen om in de eigenschappen van de netwerkverbinding aan te geven bij de Algemene instellingen dat alle gebruikers van dat netwerk gebruik mogen maken. De verbinding wordt dan volgens mij niet dicht gesmeten als je uitlogt. Ik kijk ook nog even verder naar systemd.

Doe ik inderdaad al standaard.

Bedankt voor het meedenken.

15

Over XFS: ik heb daar geen goede onderbouwing voor. Op één van de bijeenkomsten had ik 't over mijn accu ervaring met btrfs. Één van de aanwezige SUSE mensen met kennis van zaken op het gebied van filesystems gaf toen aan dat hij op laptops XFS voor / gebruikte. De argumenten kan ik me zo niet herinneren, maar waren voor mij zodanig dat ik na thuiskomst overgestapt ben op XFS. Nou is dat voor mij niet meer dan opnieuw installeren op een extra partitie (ik heb altijd twee installaties, één /home, zowel op laptop als server/werkstation).

Eerst maar even: ik denk niet dat het zinvol is om te gaan klooien in de systemd unit files. Een update van systemd zou dat meteen weer ongedaan maken. Eerder denk ik dat we 't moeten zoeken in een commando toevoegen in /etc/init.d/halt.local, de shutdown tegenhanger van boot.local waarin je extra dingen kunt laten starten tijdens het booten. Wat dat precies moet zijn moeten we even uitvinden

Je zou eerst het stoppen van nfs 's kunnen proberen:


systemctl stop nfs.service

(als root), daarna machine uitschakelen. Als dat normaal verloopt, dus zonder hangen, dan kun je die regel 's in /etc/init.d/halt.local zetten, het systeem herstarten, dan uitschakelen en kijken of dat de remedie is.

Een ander insteek die ik tegenkwam is om de NetworkManager service van systemd te stoppen via halt.local , een gebruiker rapporteert dat het fenomeen voor hem/haar daarmee verdween:


systemctl stop NetworkManager.service

daarna met Ctrl-Alt-F7 of Ctrl-Alt-F8 terug naar het login scherm en de machine uitschakelen.

Let wel, dit zijn eigenlijk geen oplossingen. Er is een dieper liggende oorzaak. Ik vraag me af of 't probleem ook bestaat met openSUSE 13.2, ik vind nl. wel posts over 13.1, en bijbehorende bugreports, maar die bugs zijn gefixed. Nou draait mijn Tumbleweed al even, dus 't zou zelfs een regressie in systemd kunnen zijn waar ik geen last van heb.

16

OK, Ik zal eens kijken. Ik heb ook voor /home een eigen partitie dus omschakelen is niet veel werk.

Je zou eerst het stoppen van nfs 's kunnen proberen:

systemctl stop nfs.service

(als root), daarna machine uitschakelen. Als dat normaal verloopt, dus zonder hangen, dan kun je die regel 's in /etc/init.d/halt.local zetten, het systeem herstarten, dan uitschakelen en kijken of dat de remedie is.

Dat ga ik proberen, alhoewel ik bij al wel weet dat dat gaat werken. Als ik aan fstab ‘noauto’ toevoeg en de shares niet aanraak, sluit hij prima af.

Een ander insteek die ik tegenkwam is om de NetworkManager service van systemd te stoppen via halt.local , een gebruiker rapporteert dat het fenomeen voor hem/haar daarmee verdween:

systemctl stop NetworkManager.service

daarna met Ctrl-Alt-F7 of Ctrl-Alt-F8 terug naar het login scherm en de machine uitschakelen.

Ga ik ook proberen.

Let wel, dit zijn eigenlijk geen oplossingen. Er is een dieper liggende oorzaak. Ik vraag me af of 't probleem ook bestaat met openSUSE 13.2, ik vind nl. wel posts over 13.1, en bijbehorende bugreports, maar die bugs zijn gefixed. Nou draait mijn Tumbleweed al even, dus 't zou zelfs een regressie in systemd kunnen zijn waar ik geen last van heb.

Klopt, daar heb ik ook over gelezen in deze: Access Denied
Lijkt dus te zijn opgelost.

Resumé: ik ga vanavond een frisse systeeminstallatie doen op XFS met openSUSE 13.2. En dan kijk is of het probleem zich ook voordoet. Ik meld me weer, hopelijk met goed nieuws :slight_smile:

17

Problemen zijn dan uiteindelijk vaak toch simpeler dan gedacht. Bij thuiskomst heb ik eens gekeken welke versie van systemd was geinstalleerd. Dit bleek 210 te zijn. Met 219 beschikbaar!
Ondank dat ik een zypper dup had uitgevoerd is deze niet geupdate. Misschien iets te maken met dependencies die eerst geinstalleerd moesten worden?

Nu systemd is geupdate naar 219 wordt er netjes afgesloten. Wel raar dat deze niet in de gedownloade Tumbleweed iso zat.

Nu de boel weer opbouwen nar herinstallatie en systeempartitie aanpassen naar Xfs.

@Knurpht bedankt voor het meedenken.

18

Mooi dat 't werkt, en zonder workarounds.

19

[Update]
Na een dag weer hetzelfde probleem. Daarna de ‘halt.local’ opties geprobeerd maar zonder succes.
Voor nu het ik in de fstab ‘noauto,bg’ toegevoegd en mount ik handmatig mocht ik dat willen en unmount is handmatig voor het afsluiten. Dat werkt prima en kan er mee leven :wink:

20

Hmpf. toch niet erg bevredigend. :frowning: