PDA

View Full Version : OpenSuse Tumbleweed sluit niet af bij NFS-client



kopstukken
30-Mar-2015, 01:40
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

hcvv
30-Mar-2015, 01:44
Hallo,

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

kopstukken
30-Mar-2015, 01:54
Hallo,

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

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

hcvv
30-Mar-2015, 02:14
Ah, sorry, Laatste Tumbleweed, is dat dan 13.2? Of krijgt dit een andere versie mee?
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.

kopstukken
30-Mar-2015, 04:36
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.

Knurpht
30-Mar-2015, 08:08
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 :D

hcvv
30-Mar-2015, 08:20
Een heel groot probleem is 't overigens niet, immers een server die NFS draait moet altijd aan :D
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. >:(

Knurpht
30-Mar-2015, 09:26
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?

kopstukken
30-Mar-2015, 11:25
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


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.


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?

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

Knurpht
30-Mar-2015, 11:35
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?

kopstukken
30-Mar-2015, 12:15
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.

kopstukken
30-Mar-2015, 13:28
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.

Knurpht
30-Mar-2015, 13:38
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.

kopstukken
30-Mar-2015, 14:03
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.

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


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.
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.

Knurpht
31-Mar-2015, 04:02
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.

kopstukken
31-Mar-2015, 06:19
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).
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: https://bugzilla.novell.com/show_bug.cgi?id=861489
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 :-)

kopstukken
31-Mar-2015, 10:06
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.

Knurpht
31-Mar-2015, 11:39
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.

Mooi dat 't werkt, en zonder workarounds.

kopstukken
04-Apr-2015, 05:06
[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 ;)

hcvv
04-Apr-2015, 08:06
Dat werkt prima en kan er mee leven
Hmpf. toch niet erg bevredigend. :(

kopstukken
04-Apr-2015, 12:58
Hmpf. toch niet erg bevredigend. :(

Nee, dat klopt, maar alles beter dan het was. Nu ik voor het afsluiten dus 'umount' sluit openSUSE netjes af. Ik weet niet of ik dit commando ook in de 'halt.local' kan zetten zoals @knurpht eerder heeft aangegeven voor de systemctl acties. Of dat ik hier een bashscript voor moet laden voor shutdown. Maar ik heb te weinig kennis van Linux om hier gefundeerd mee aan de slag te gaan.

Als je nog ideeën hebt dan hoor ik het graag. Maar zoals ik al zei, kan ik hier prima me leven.

pieter1602
04-Apr-2015, 13:45
pieter1602@linux-ljnv:~> mount | grep nfs
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
192.168.1.42:/volume1/LinuxPC on /home/pieter1602/Synology type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.32,local_lock=none,addr=192.168.1.42)


Gebruik ook een Synology en nu ook een tumbleweed geinstaleerd ook een nfs share.en geen problemen met afsluiten .
Die van mij zie hierboven zat ik te vergelijken met die van jou en zie toch wel enkele verschillen:),en dan valt me die clientaddr op ,geen idee verder hoe of wat maar misschien is dit wat.

kopstukken
04-Apr-2015, 23:56
pieter1602@linux-ljnv:~> mount | grep nfs
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
192.168.1.42:/volume1/LinuxPC on /home/pieter1602/Synology type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.32,local_lock=none,addr=192.168.1.42)


Gebruik ook een Synology en nu ook een tumbleweed geinstaleerd ook een nfs share.en geen problemen met afsluiten .
Die van mij zie hierboven zat ik te vergelijken met die van jou en zie toch wel enkele verschillen:),en dan valt me die clientaddr op ,geen idee verder hoe of wat maar misschien is dit wat.
Dat inderdaad een goeie. Daar ga ik eens induiken. Heeft jouw pc/laptop (client) een vast ip-adres? Mijn server in iedergeval wel en die bevind zich buiten de dhcp pool. Ik zal de Server-ip ook eens binnen de pool brengen. Kijken of dat wat uithaalt.

Bedankt voor je opmerking.

pieter1602
05-Apr-2015, 03:27
Bij mij gaat hier alles met DHCP.:\Heb best wel veel last gehad met moeizame NFS Bij de NFS instelling op de synology geef je bij de toewijzijng een IP adres op, zal dat de clientadres zijn.Zelf had ik daar eerst de server IP ingevuld en nu gewoon die van de client.
En NFS is heel goed gaan werken toen ik de UID van de user op de PC het zelfde had gemaakt als de UID van de user op de Synology.Dat heeft echt wonderen verricht.:)

kopstukken
05-Apr-2015, 04:23
Bij mij zijn de uid-s inderdaad niet gelijk. Die zal ik eens rechttrekken.

Ik heb meerdere gebruikers op mijn laptop die allemaal toegang moeten hebben tot de server. Mijn mountpoint is dat ook /mnt/server, en dus niet in een user home map, zoals bij jou. Nu denk ik niet dan dit het probleem is. Eerst de uid gelijktrekken. ;)

Knurpht
05-Apr-2015, 06:05
Bij mij gaat hier alles met DHCP.:\Heb best wel veel last gehad met moeizame NFS Bij de NFS instelling op de synology geef je bij de toewijzijng een IP adres op, zal dat de clientadres zijn.Zelf had ik daar eerst de server IP ingevuld en nu gewoon die van de client.
En NFS is heel goed gaan werken toen ik de UID van de user op de PC het zelfde had gemaakt als de UID van de user op de Synology.Dat heeft echt wonderen verricht.:)

Ik zou nooit DHCP gebruiken voor een server, tenzij die van een eigen DHCP server een IP adres krijgt dat MAC-gebonden is. Je hoeft maar één keer mee te maken dat je server opeens een ander IP krijgt, dan leer je dat wel.

Dat tweede, over UID's, zou wel eens de crux kunnen zijn. Ik heb de hele tijd het idee dat NFS ergens iets vasthoudt wat het om één of andere reden niet los kan laten, waardoor er ook niet geünmount kan worden. Zeer benieuwd.

pieter1602
05-Apr-2015, 09:26
tenzij die van een eigen DHCP server een IP adres krijgt dat MAC-gebonden is Alle Ip adressen zijn MAC gebonden hier:).
En er zijn precies zo veel ip adressen in de pool als er apparaten in huis zijn:).
Ben ook wel benieuw dat van die UID heeft echt hier bij mij zo veel geholpen:).

kopstukken
05-Apr-2015, 11:39
Heren, heren, geeft mij even wat tijd. Het is Pasen en met mijn schoonmoeder op bezoek niet verstandig om achter mijn laptop te kruipen ;). Morgenochtend heb ik even tijd. Ik ben zelf ook benieuwd of dit wat uithaald.

Nog even een aanvullende vraag aan @pieter1602 : hoe heb jij de squash ingesteld op je Synology:


Toewijzing aan admin: wijst de toegangsrechten toe aan rootgebruikers van de NFS-client die gelijk zijn aan de admintoegangsrechten op uw systeem.
Toewijzing alle gebruikers aan admin: wijst de toegangsrechten toe aan alle gebruikers van de NFS-client die gelijk zijn aan de admintoegangsrechten op uw systeem.

Eerder hab ik namelijk '1' ingesteld. Maar als ik alle uid-s gelijk ga trekken vraag ik mij af of ik niet voor '2' moet kiezen.

pieter1602
05-Apr-2015, 12:43
Eigenlijk geen van beide die je opnoemt,hij staat op : geen toewijzing,Is toeval heb ik laten staan zoals hij stond,:\

pieter1602
05-Apr-2015, 12:49
En zie nu dat ik daar ook nog mee aan het experimenteren moet.:\

kopstukken
05-Apr-2015, 13:40
Eigenlijk geen van beide die je opnoemt,hij staat op : geen toewijzing,Is toeval heb ik laten staan zoals hij stond,:\

Misschien nog wel de beste keuze lees ik net:

https://www.synology.com/nl-nl/knowledgebase/tutorials/616



Geen toewijzing: zorgt dat alle gebruikers van de NFS-client, inclusief rootgebruikers, de oorspronkelijke toegangsrechten behouden.

Als ik dit zo lees betekent dit, bij gelijkgetrokken uid-s, dat de rechten van de user op de server wordt overgenomen door de client. En dat wil ik met meerdere gebruikers met eigen gebruikersmappen op de server!

Zoals gezegd, morgenochtend ga ik hier mee stoeien (met de hoop dat een en ander ook netjes afsluit :-)

kopstukken
06-Apr-2015, 00:51
BINGO!

Vanmorgen eerst alle overige users van mijn laptop gehaald via Yast.

Op de server:

alle uid-s opgezocht en opgeschreven:
cat /etc/passwd
de nfs squash ingesteld op 'Geen toewijzing'.


Daarna op de laptop:

Alle uid-s van de ingestelde users op de laptop aangepast aan die van de server.Gereboot
In Yast -> nfs-client-> mount opties weer teruggezet naar 'defaults'. Gereboot
Gecontroleerd of alle users kunnen afsluiten.


Iedereen kan nu gewoon afsluiten. Dit is top!
Qua rechten op de server heb ik nog wel wat werk te doen, maar dat is dan ook alles ;)
Na de laatste reboot, moest ik wel twee keer inloggen in gdm. De eerste keer mislukte het inloggen en kwam ik weer in gdm uit. tweede keer inloggen lukte wel. Herinstallatie van gdm loste dit probleem op.

@pieter1602 : erg bedankt voor de juiste richting.

Na jaren Ubuntu te hebben gebruikt (waar nfs klaarblijkelijk weinig eisen stelt), 'dwingt' openSUSE mij dit netjes in te richten. En daar is niets mis mee!
Weer wat geleerd!

Knurpht
06-Apr-2015, 04:40
BINGO!



Fantastisch. Stom eigenlijk, het gelijklopen van UID's op clients en server moet eigenlijk één van de eerste vragen zijn.... Mooi dat 't werkt, allemaal weer wat geleerd idd.

pieter1602
06-Apr-2015, 12:00
Teamwork;).



@pieter1602 : erg bedankt voor de juiste richting

Leuk dat ik na veel gekregen hulp ook zelf eens een bijdrage kan leveren.