Hoi
Ik heb een vraag over het opzetten van een NFS verbinding met een NAS.Werkt goed maar wat gebeurd er nu eigenlijk.
Ik maak als user :pieter1602 een NFS verbinding aan in YAST met de Nas.Als wie of wat gaat dan die NFS verbinding naar die Nas:.
Best wel moeilijk uit te leggen!Op de Nas geef je een user dus toestemming voor een Map.maar is degene die op de Nas komt via mijn 13.2 PC , pieter1602 of misschien Root.:|Omdat je in Yast die verbinding maakt
NFS bestaat uit 2 componenten: nfsserver en nfs (de client). Het simpelst is om maar even de NFS3 standaard aan te houden:
Aan de serverkant exporteer je wat je elders beschikbaar wilt hebben. Een korte knip uit die van mij:
/disk/Muzickx *(rw,root_squash,sync,no_subtree_check)
De map spreekt voor zich, daarna zie je
root_squash -> wat mag root in de share als die is aangekoppeld op een andere machine. In dit geval wordt door NFS een ander numeriek ID aan root toegekend, zodat de root op een andere machine geen rootrechten heeft op de share
sync -> zorgt ervoor dat client en server continu elkaars situatie actueel houden
no_subtree_check -> NFS gaat niet de hele onderliggende mappenstructuur elk moment testen.
Hoe de client 't doet is te zien in je fstab, je ziet daar een regel met het IP en de nfsexport, met filesystem nfs en wat opties.
E.e.a. betekent dat bijv. jouw gebruiker ook op de NAS moet bestaan (liefst met zelfde UUID).
Heel kort: NFSserver exporteert, NFSclient koppelt de export aan. Jij kunt vervolgens de boel lokaal benaderen. Voor bijv. WEBDAV kun je ook dit soort constructies maken.
Om je even helemaal lekker te maken: mijn wederhelft heeft zo als enige in het docentencorps de hele cloudomgeving van school middels davfs2 aangekoppeld op haar laptop thuis.
Nog even over jouw vraag:
- de shares worden standaard aangekoppeld door root.
- omdat jou op de server rechten op een map zijn toegekend, heb je die op de aangekoppelde share ook.
Om te testen:
- maak een nieuwe gebruiker op openSUSE aan, die niet op de NAS bestaat
- probeer de share te benaderen, ingelogd als de nieuwe gebruiker, je moet dan op rechtenproblemen stuiten.
Ik hoop dat je na de uitleg van Knurpht begrijpt dat bovenstaande niet kan kloppen. Als je YaST gebruikt ben je al gelijk niet meer user pieter1602. Je bent dan root, er is ook om het root wachtwoord gevraagd. User pieter1602 heeft met het hele mounten niets te maken. Maar als er gemount is (en het maakt niet uit of dat een NFS mount of een schijfmount is), kan pieter1602 misschien daar dingen doen zoals lezen, schrijven, executen. Mits uiteraard de combinatie van eigenaar/groep en permissiebitjes dat toestaan. Hetzelfde als altijd en overal, NFS of niet.
Wat ik jaren geleden niet doorhad, was dat gebruiker knurpht (jawel) met hetzelfde UUID op server en client bestaan moest. Zo kwam ik, om het geklier van moeten onthouden te voorkomen, erop om NIS te gaan gebruiken. Daarvoor werd me aangeraden om alles dan maar 777 te maken, maar ik snapte genoeg om te weten dat dat niet de te bewandelen weg moest zijn.
Inderdaad, dat is niet datgene waar mijn vorige post de nadruk op ledge (dat was op het feit dat administratie altijd door root wordt gedaan en nit door een eindgebruiker). Maar ik vermeldde dat uiteraard eigenaarschap en permissies werken.
Dat heeft niet direct tot gevolg dat gebruikers in zo’n NFS server/client hetzelfde moeten heten (in een NAS maak je misschine helemaal geen bebruikers aan), maar je moet die userids/UIDs (en groupids/GIDs) goed in de gaten houden. Als je bijv. twee client systemen hent, wordt het al uitkijken!
En dus is het beste om de gebruikersadministratie van alle systemen gelijk te houden, of op zijn minst de UIDs en GIDs niet dubbel uit te geven. Dus niet op systeem A UID 1000 gebruiken voor de hoofdgebruiker van dat systeem en op systeem B weer 1000 voor een andere gebruiker.
Voor je het weet zit je in de prvéadministratie van een familielid die op het NAS staat te prutten.
probeer de share te benaderen, ingelogd als de nieuwe gebruiker, je moet dan op rechtenproblemen stuiten.
Oei probleem ben ik bang, ook met de nieuwe user die niet op de Nas staat kan ik alles doen en zijn er geen rechten problemen.
Dan staat er op de NAS iets niet goed. Kun je van de client 's de volgende output posten:
cat /etc/fstab
mount
pieter1602@linux-ojay:~> cat /etc/fstab
UUID=9a9cb380-bb43-4120-b088-3ffedb65ab9a swap swap defaults 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 / btrfs defaults 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /boot/grub2/i386-pc btrfs subvol=boot/grub2/i386-pc 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /boot/grub2/x86_64-efi btrfs subvol=boot/grub2/x86_64-efi 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /opt btrfs subvol=opt 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /srv btrfs subvol=srv 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /tmp btrfs subvol=tmp 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /usr/local btrfs subvol=usr/local 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/crash btrfs subvol=var/crash 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/lib/mailman btrfs subvol=var/lib/mailman 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/lib/named btrfs subvol=var/lib/named 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/lib/pgsql btrfs subvol=var/lib/pgsql 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/log btrfs subvol=var/log 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/opt btrfs subvol=var/opt 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/spool btrfs subvol=var/spool 0 0
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /var/tmp btrfs subvol=var/tmp 0 0
UUID=ee9f6ef7-587f-459f-bebc-40388021ef3e /home xfs defaults 1 2
UUID=1d49cd2c-9463-439a-adaf-a5c1c7162117 /.snapshots btrfs subvol=.snapshots 0 0
192.168.1.42:/volume1/LinuxPC /mnt/OpenSuse nfs4 defaults 0 0
pieter1602@linux-ojay:~> mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=3938844k,nr_inodes=984711,mode=755)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
/dev/sda2 on / type btrfs (rw,relatime,space_cache)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=33,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
/dev/sda2 on /.snapshots type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/tmp type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/spool type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/opt type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/log type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/lib/pgsql type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/lib/named type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/lib/mailman type btrfs (rw,relatime,space_cache)
/dev/sda2 on /var/crash type btrfs (rw,relatime,space_cache)
/dev/sda2 on /usr/local type btrfs (rw,relatime,space_cache)
/dev/sda2 on /tmp type btrfs (rw,relatime,space_cache)
/dev/sda2 on /srv type btrfs (rw,relatime,space_cache)
/dev/sda2 on /opt type btrfs (rw,relatime,space_cache)
/dev/sda2 on /boot/grub2/x86_64-efi type btrfs (rw,relatime,space_cache)
/dev/sda2 on /boot/grub2/i386-pc type btrfs (rw,relatime,space_cache)
/dev/sda3 on /home type xfs (rw,relatime,attr2,inode64,noquota)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
192.168.1.42:/volume1/LinuxPC on /mnt/OpenSuse 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)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
Hoi Knurpht
Denk ook dat er op de nas iets niet goed staat weet dat er bij de gedeelde map op de nas bij groepen een vinkje staat bij users en als ik die weg haal kom ik vanaf mijn Pc niet meer op de nas.Is het zinnig als ik ook
cat /etc/fstab
mount
doe met dat vinkje bij users weg :\
Nope, dat heeft geen zin. Ik heb recentelijk geen NASsen onder handen gehad, maar wel 's zo’n “users” optie gezien. Daarmee werd een masker (zie Henk’s korte uitleg) gelegd, wat erop neerkomt dat de permissies van 755 naar 775 gezet werden, kortom iedereen die ergens lid is van de groep ‘users’ ( en dan met hetzelfde group ID als op de NAS ) alles mag op de NAS.
Als jouw gebruiker pieter1602 op jouw openSUSE UID 1000 heeft, moet-ie op de NAS ook bestaan als pieter1602 met UID 1000. Je kunt dat zien in /etc/passwd :
(Van mijn testbakje) Eerst voor de inhoud uit “man passwd” de tweede optie ( een 5 intikken )
name:password:UID:GID:GECOS:directory:shell
knurpht:x:1000:100:Knurpht:/home/knurpht:/bin/bash
Als pieter1602 op de NAS bijv. UID 500 heeft ( er zijn distros die daar beginnen ), dan moet je op je openSUSE bak kijken of dat UID vrij is. Zo ja, dan verander je 't UID van pieter1602 in Yast naar 500. Dit kun je beter niet doen terwijl je ingelogd bent als pieter1602, maar via Yast in de console. Er wordt je gevraagd of de rechten van pieter1602’s homedir moeten worden bijgewerkt, dat moet zeker anders heb je geen schrijfrechten meer in je homedir. Als je nu inlogt en verbinding maakt met de NAS moet het goed zijn.
Daarmee werd een masker (zie Henk’s korte uitleg) gelegd, wat erop neerkomt dat de permissies van 755 naar 775 gezet werden, kortom iedereen die ergens lid is van de groep ‘users’ ( en dan met hetzelfde group ID als op de NAS ) alles mag op de NAS.
Ja dat lijkt me ook inderdaad wat er gebeurd .
namepassword:UID:GID:GECOS:directory:shell
knurpht:x:1000:100:Knurpht:/home/knurpht:/bin/bash
En ik begrijp je oplossing maar denk dat ik nog geen idee heb hoe ik het bovenstaande kan uitvoeren.
Je zult dan eerst op de NAS erachter moeten komen welk UID pieter1602 daar heeft. Op sommige NASsen kun je dat UID zelfs op de NAS wel veranderen.
Op je PC kun je dat doen in Yast - Beveiliging en gebruikers - Gebruikers en groepenbeheer - pieter1602 aanklikken - Bewerken - Details. Daar zie je het UID staan, en kun je dat ook wijzigen in het UID dat de NAS van pieter1602 heeft. Tegenwoordig vraagt Yast zelfs niks meer, maar past alles netjes aan.
Ik volg deze draad eerlijk gezegd niet helemaal precies, maar heb het idee dat iets misschien niet helemaal duidelijk is (is het dat wel, dan sorry).
De username (pieter1602 in dit geval begrijp ik), is niet van veel belang. Het is alleen lokaal bekend. Het is de uid (het nummer) dat van belang is. Als pieter1602 uid 1000 heeft op de PC en hij creëert een bestand op een plek op de NAS (uiteraard op ee plek waar hij dat mag), dan wordt automatisch uid 1000 eigenaar van het bestand. Op de PC zie je dat als pieter1602 (want dat is de voor de mens beter begrijpelijke alias van uid 1000). Op het NAS systeem (feitelijk de NFS server) is ook uid 1000 eigenaar. Als dat een Unix/Linux systeem is kan in /etc/passwd een heel andere username/alias staan (en lokaal kijken levert dus die username als eigenaar op). Er hoeft zelfs helemaal geen bijbehorende /etc/passwd regel te zijn (lokaal kijken geeft dan het uid in plaats van de username bij bijv een ls listing).
Op een andere NFS client kan uid 1000 weer een heel ander username zijn. Dit wordt natuurlijk vervelend als op dat andere systeem uid 1000 ook een andere persoon is. pieter1602 (zijnde Pieter) en de uid 1000 op de andere client (zijn zijn broer Gijs of zo) kunnen dan elkaars bestanden ge/misbruiken.
**Van belang **is dus dat uids in zo’n groep samenwerkende systemen echt voor fysieke mensen uniek zijn.
Handig is als daar op alle client systemen dezelfde username bij hoort.
Ook handig is als op het NFS server systeem daar dezelfde username bijhoort (al was het maar voor het gemak van de beheerder).
Voor een NAS, waarbij het beheer misschien zeer beperkt is, is het naar mijn mening niet nodig (en misschien ook niet mogelijk) om usernamen aan uid’s te hangen.
Ik heb overigens wel veel Unix/Linux NFS servers beheerd (nog steeds enkele) maar heb geen ervaring met NAS. Ik neem aan dat beheer daarvan per type verschilt.
NAS = Network Attached Storage.
@Henk: 't zijn meestal (bijna altijd) linux bakjes met NFS, Samba, ssh (en sftp), FTP, webservertje, bedienbaar via een webinterface. Die laatste verschilt per fabrikant, tevens wat je ermee kunt. En, bedankt voor je uitleg, ik denk dat ik jaren geleden al iets gemist heb mbt username, of mezelf heb verteld dat 't moest omdat 't inderdaad wel handiger is. NIS is natuurlijk nog makkelijker.
Uiteraard is NIS een zeer goede oplossing als je zowel de van belang als de handig zijnde zaken in de praktijk wilt invoeren bij een groter aantal systemen. Hoeveel “groter aantal systemen” is hangt niet alleen van het aantal systemen af, maar ook van het aantal te administreren gebruikers en groepen en de aantallen mutaties daarin.
Je moet natuurlijk even in wat NIS studie investeren, maar als je het eenvoudig houdt is het toch zeer goed te doen.
Aan de andere kant, als je één NAS hebt en twee à drie systemen met alleen je gezin als gebruikers is het niet moelijk met de hand te doen. Ik ga bijv. ook geen DNS server opzetten voor drie à vier systemen hier in huis, dat doe ik gewoon in de /etc/hosts en kopie/plak.
Dit is voor mij een hoop stevige info die hier en daar best wel moeilijk te begrijpen is :.Heb putty gedownload en ben op de NAS gaan zoeken naar de users en dat viel niet mee na lang zoeken vond ik pieter1602 met uid van 1026.
Heb toen in openSuse de 1000 veranderd in 1026 en een nieuw nfs mountpunt aangemaakt.
Vervolgens heb ik de vinkjes bij users weggehaald iets wat de nas volgens mij uitzichzelf aanpast en weer neerzet.En alleen pieter1602 aan de gedeelde map gegeven opnieuw opgestart.En de vinkjes bleven staan waar ze stonden (niet meer bij users)en met de extra aangemaakte user was de share niet meer te bereiken:).
Dus hcvv en Knurpht bedankt voor het meedenken en de info het lijkt zover te doen wat het moet doen.
De username (pieter1602 in dit geval begrijp ik), is niet van veel belang. Het is alleen lokaal bekend. Het is de uid (het nummer) dat van belang is
Is denk ik te zien aan het feit dat ik als pieter1602 niet meer aan mijn oude backups mag komen met de andere uid.Dus maar gewist en nieuwe gemaakt:).
Nieuwe backups kunnen geen kwaad, maar je had alles weer goed kunnen zetten, door
chown pieter1602 "pad naar backupmap hier invullen zonder aanhalingstekens" -R
Ahum, volgens mij
chown -R pieter1602 "pad naar backupmap hier invullen zonder aanhalingstekens"
Volgens de man page ook. Maar het werkt wel. Ik heb 't zo geleerd bij NCR, UNIX systemadministration. Daar was een docent, die “Change the directory’s permissions, oooops, the content of it is unchanged. Now we repeat this adding the ‘-R’ option and look what happens. Again, nice, but this is not magic.”, met een zwaar Schots accent. Zo’n man page waar ik nooit meer naar heb gekeken, omdat ik 't blijkbaar niet nodig had.