Synology-Forum.nl
Overige software => FTP, NFS and Samba Server => Topic gestart door: schekker op 03 juni 2014, 09:56:15
-
Ik heb de DS214play met daarin 2 disks als losse volumes. Ik wil vanaf mijn Ubuntu server met dirvish (een op rsync gebaseerde backup script) een backup maken op mijn NAS. Daartoe mount ik via NFS een gedeelde map van mijn NAS op mijn server. Probleem is dat die map als rechten 000 heeft en ik er dus niet op kan schrijven.
Uiteraard heb ik zitten experimenteren met de rechten op de NAS, maar zelfs als ik iedereen RW rechten op die share geef, blijven de rechten via NFS op 000 staan. Ik heb gelezen dat NFS4 wat vervelend doet met verschillen in gebruikers tussen de server en de NAS en heb NFS4 dus uitgezet.
Ook heb ik met ssh op de NAS gekeken en gezien dat de betreffende directory ook op de NAS die 000 rechten heeft. Verander ik die rechten via chmod naar 700 (volledige rechten voor de owner, root in dit geval, en geen voor anderen), dan kan ik er wel gewoon via NFS bij.
Het probleem lijkt dus te liggen aan de standaard rechten die een zelf aangemaakte share op de NAS krijgt. Maar het kan toch niet zo zijn dat je je via ssh en chmod eerst met het handje de rechten van zo'n directory goed moet zetten, voordat je er met NFS bij kan? Dus wat mis ik?
-
Waarom wil je eigenlijk NFS share gebruiken i.pv. Samba?
-
Omdat Samba vooral een noodzakelijk kwaad is om met de Windows wereld te kunnen connecten? :geek:
Naar wat ik begrepen heb is de overhead van nfs een stukje kleiner dan van samba, en met mijn ReadyNAS of andere linux machines heb ik er ook nooit problemen mee gehad. Behalve dus bij de Synology, daar lijkt het alleen te werken met het nodige geklooi onder de moterkap. En laat ik nu net de Synology gekocht hebben om een beetje van dat geklooi af te zijn :(
-
Over welke samba versie heb je het dan. Oude testen zeggen weinig over de huidige situatie. smb v2 is duidelijk sneller dan smb v1.
Als ik op de nas smb als protocol kies, gebruikt hij versie 2 als je dat in de voorkeuren aan hebt staan. Als je expliciet via de oude samba v1 wilt verbinden, moet je 'cifs' als protocol kiezen.
-
Eerlijk gezegd vind ik dat niet zo relevant. NFS is het protocol voor linux en dat wil ik gewoon gebruiken. Synology claimt dat te ondersteunen, heeft daar ook opties voor in zijn U.I. en met die ondersteuning ondervind ik problemen. Vandaar dat ik me tot dit forum richt. Kennen anderen dit probleem, of ligt het aan mij? De suggestie dat ik dan maar geen NFS moet willen is mij te kort door de bocht.
-
ALs je een Synology koopt om van het geklooi onder de motorkap af te zijn en vervolgens met NFS rechten moet gaan klooien moet je je afvragen waar dat klooien vandaan komt. :'(
NSF is antiek SUN product dat echt z'n tijd gehad heeft en niet kan tippen aan SMB 2 en dan heb ik het helemaal nog niet over smb 3 waar de echte verbeteringen in zitten.
Helaas heef t SMB 3 Synology nog niet bereikt :o
-
Waarom denk je dat ik in dit forum post?
En ik heb even een duckduckgo search of nfs vs samba gedaan, en de eerste hit gaf meteen aan dat nfs voor mijn situatie inderdaad de betere keuze zou moeten zijn. Ik connect vanaf een ubuntu machine en daar geeft nfs in ieder geval minder overhead dan samba en vereist het ook veel minder configuratie. Verder wordt nfs ook nog steeds verbeterd, dat het zijn tijd gehad heeft is pure onzin.
Ik wil hier ook helemaal geen discussie over samba vs NFS voeren. Ik wil om mij persoonlijke redenen gewoon via NFS connecten en loop daarbij op de Synology tegen problemen aan. Herkennen anderen die problemen, of beter nog, weten jullie daar een betere oplossing voor dan via ssh directory rechten aan te gaan passen?
-
Standaard staan gedeelde mappen op d---------
DSM regelt verder de rechten maar, daar was je wel achtergekomen.
Echter, heb je wel een user gemaakt in Ubuntu en die user ook in DSM gemaakt met de nodige rechten voor die gedeelde map ?
Ook hier gekeken of alles goed staat ?
[attachimg=1]
-
Ik gebruik geen NFS maar vond wel een YouTube filmpje hier over.
Wel, eenmalig, met SSH even iets aanpassen. Iets met locks maar ik weet niet wat dat is.
Maar misschien heb je er toch iets aan?
-
Ik heb nog nooit NFS als protocol gebruikt en heb het ook even geprobeerd. Mounten gaat blijkbaar net anders dan de andere protocollen en het volume moet ook in het pad opgenomen worden.
Mounten via 'nfs://10.0.1.30/volume1/video' werkte in een keer op mijn Mac.
Dan krijg ik een share waar ik gewoon op kan schrijven. Echter, meer beangstigend is dat mij dan niet om een wachtwoord gevraagd wordt. Dus iedereen die vanaf mijn computer bij de shares wil, kan er bij. De enige beveiliging is een bron IP.
Maar geen noodzaak om iets via putty aan te passen.
-
Daarom kan je ook specifieke ip adressen toegang verlenen.
En over het internet werkt het toch niet?
-
Heb je in DSM het ip adres van je Ubuntu gezet of maak je gebruik van wildcards (*.*.*.*). Dit laatste zorgt er bij mij voor dat ik wel de shares zie maar geen lees en schrijf rechten heb. Hier loop ik niet tegen aan wanneer ik de ip adressen voluit schrijf.
Wat betreft accounts aanmaken tbv nfs. Dat is dus niet nodig bij nfs aangezien je geen accounts toegang geeft tot je shares maar ip adressen.
-
Daarom kan je ook specifieke ip adressen toegang verlenen.
Bij mijn zus b.v. zitten ze met zijn 4-en op de PC. Beide ouders en beide kinderen hebben een eigen account op die PC. Bij NFS kun je dan niet de kinderen buitensluiten als je zelf toegang wilt hebben.
Dat geeft niet, zolang je het maar weet. Alleen vreemd omdat juist Unix opgezet is als een multi-user OS. En zowel OSX als Linux is van Unix afgeleid. Dan zou je toch verwachten dat een linux filesysteem ook multi-user opgezet is in plaats van IP ge-oriënteerd.
-
IN NFS4 hebben ze ondersteuning voor users, maar dan moeten die users wel op zowel de server als client bekend zijn. Leuk als je een centrale user authenticatie hebt, maar voor thuisgebruik minder handig, deze heb ik op de Synology dan ook niet geactiveerd.
Ook kan je nog wel wat slims doen met de access rights op de parent directory van het mountpunt. Kun je niet bij die parentdirectory komen, dan kom je ook niet bij de NFS share. Maar ook dat heb ik voor de backup niet nodig.
Heb je in DSM het ip adres van je Ubuntu gezet of maak je gebruik van wildcards (*.*.*.*). Dit laatste zorgt er bij mij voor dat ik wel de shares zie maar geen lees en schrijf rechten heb. Hier loop ik niet tegen aan wanneer ik de ip adressen voluit schrijf.
Wat betreft accounts aanmaken tbv nfs. Dat is dus niet nodig bij nfs aangezien je geen accounts toegang geeft tot je shares maar ip adressen.
Ik gebruikte wildcards. Ik ben nu aan het experimenteren met volledige ip adressen, maar dat werkt nog niet helemaal zoals het hoort. Maar ik moet daar nog even wat verder testen.
Als ik het goed begrijp hoort de Synology standaard de rechten voor de shared folders op d--------- te zetten en zou de NFS-server op de Synology er onder water voor moeten zorgen dat toch de juiste rechten gebruikt worden, iets wat bij mij dus problemen geeft.
Het is me nog onduidelijk of het kwaad kan om handmatig die rechten ruimer te zetten. De photo gedeelde map staat bijvoorbeeld standaard al helemaal open op het filesysteem en daar lijkt het ook geen kwaad te kunnen.
En ja, ik heb hier echt wel wat op gezocht, maar het probleem is dat veel informatie inmiddels verouderd is. Synology is in DMS4.3 overgegaan op nfs4 en naar ik gelezen heb zijn sindsdien de problemen begonnen. Echte oplossingen kwam ik echter niet tegen (die aanpassing in het youtube filmpje zou bijvoorbeeld dankzij een patch van Synology inmiddels niet meer nodig zijn).
-
Hoe mount je in Ubuntu? Ik neem aan via fstab regels? Heb je daar een nfs versie in staan? Als je in Synoloy als admin een share aanmaakt kun je die doorgaans met een standaard fstab regel benaderen. Elke submap kun je dam rw meegevn.
-
Op dit moment gewoon met een mount commando zodat de mount er alleen maar is als mijn backup loopt.
Mijn mountcommando is
mount -t nfs -onoatime,rw,tcp 192.168.1.2:/volume1/data /media/data
Ik heb wel met het opgeven van nfs versies geëxperimenteerd, maar dat lostte mijn probleem niet op. Bovendien staat NFSv4 op de Synology uit en is de connect dus sowieso met NFSv3.
Als /volume1/data dicht staat, dan kan ik na de mount wel in die folder en subfolders komen, maar elk bestand of directory die ik aanmaak staat ook dicht. En daar kan mijn backup niet tegen.
Unmount ik en geef ik /volume1/data de rechten 'drwx------' en maak ik daarna na een mount een bestand aan, dat heeft deze wel de standaard 'rw-r--r--' rechten.
Ik heb vervolgens weer een unmount gedaan en het mountpunt weer dicht gezet. Toen ik deze daarna mountte en weer een bestand aanmaakte, hield deze zijn standaard 'rw-r--r--' rechten. Precies wat ik wil dus. Ik weet alleen of dit ook zo blijft na een reboot (er loopt op dit moment een initiële backup van de data op mijn NAS naar een externe schijf, en die wil ik niet onderbreken).
Wat me opviel is dat het gedrag via de NFS mount gelijk was aan het gedrag van een lokale root-user op de NAS zelf.
Voor de volledigheid nog even de NFS-instellingen zoals ik die op het moment op de server heb staan:
NFS inschakelen: aangevinkt
NFSv4-ondersteuning inschakelen: staat uit
Standaard UNIX machtigingen toepassen: aangevinkt
Pakketgrootte lezen: 8KB
Pakketgrootte schrijven: 8KB
Kerberos-instellingen: leeg
En voor de betreffende map staan de NFS-machtigingen als volgt:
Hostnaam of IP*: 192.168.1.5
Rechten: Lezen/schrijven
Squash: Geen toewijzing
Beveiliging: sys
Asynchroon inschakelen: aangevinkt
Verbinden van niet-gemachtigde poorten toestaan (poorten hoger dan 1024): aangevinkt.
-
En als je "Squash: Geen toewijzing" wijzigt in "Squash: Toewijzing aan Admin" ?
-
Dan krijgt alles de rechten rwxrwxrwx en wordt elk nieuw bestand van user 'admin'. Ik ben dan dus de access rights en ownership van elk bestand kwijt. Niet echt praktisch voor een backup. Maar zo heb ik wel toegang ja.