Mount - hvad styrer rettighederne på det monterede netværksd

[Ole Mose]

Jeg har et sært problem på flere maskiner. De er tilsluttet en lille NAS server (Synology 109).

Jeg monterer et område på disken med følgende linie i /etc/fstab:

Kode: Vælg alt

//192.168.0.40/dev /mnt/synology/dev cifs credentials=/home/ole/.smbcredentials$

(//192.168.0.40/dev er et delt område på serveren, der anvendes til at gemme programer under udvikling - det er således IKKE systembiblioteket /dev)

Det mærkelige er, hvis jeg fra et brugerprogram (f.eks. Geany, eller SPE) opretter en fil på drevet, så oprettes den skrivebeskyttet!? Det er i sig selv en modsætning.
I praksis betyder det, at jeg kan oprette filen. Når jeg senere forsøger at gemme ændringer, får jeg skrivefejl?

Hvordan kan det næsten hænge sammen?

Tilføjet:
En nyoprettet fil har rettighederne 664 - altså -rw-rw-r--

Hvis jeg manuelt ændrer det så alle får skriverettigheder er problemet løst. Det er bare lidt bøvlet at skulle gøre det ved alle nyoprettede filer.

[lath]

Rettigheder er delt op i 3 typer.
Fra venstre mod højre er der rwx rettighed for brugeren, gruppen og alle andre (other).
Det du vil er at du have rettighederne skal være -rw-rw-rw, eller 666

Jeg fortæller dig ikke hvordan man så permanent sætter other bits til altid at blive -rw da det gennemhuller sikkerheden i Linux, fordi den ændring er system-wide og dermed også omfatter superbrugeren 'root'.

Du kan i stedet bruge:

Kode: Vælg alt

chmodu o+w filnavn.filendelse

... for hver fil.
Eller hvis du vil gøre det for alle filer i en undermappe (incl for filer i alle undermapper til den mappe), så skal du køre:

Kode: Vælg alt

chmod -R o+w navn_på_mappe/*

(Bemærk at den ender på /*, det er vigtigt).
Hvis du vil gøre det fra "denne mappe", hvor "denne mappe" kan vises med:

Kode: Vælg alt

pwd

... kommandoen, så skal du i stedet køre:

Kode: Vælg alt

chmod -R o+w ./*

Man kunne godt lave en service (hedder en daemon i Linux'sk, BSD'sk og UNIX'sk) der automatisk sætter write bit for others fra en undermappe og i undermapper under den mappe på nye filer, men det har jeg ikke rigtig tid til at lave, selv om det lyder som et interessant lille projekt.

/Lars

[Ole Mose]

Jeg er helt med på den del af rettighedssystemet, du beskriver. Det er ikke det, der driller.

Det der undrer mig er, hvad i systemet der gør, at brugerprogrammer kan oprette en fil, der samtidigt er (eller i hvert fald ender med) at være skrivebeskyttet.
Brugeren har skriverettigheder på mappen/undermapper og som følge af dette, børe Geany, SPE, kWrite og andre ikke lave filer, der er skrivebeskyttede, når brugeren opretter filer med disse programmer.

Der bør på ingen måde køre "daemons", der skal rette op på de ting. Det er noget andet, der er galt.

[lath]

Jeg er helt med på den del af rettighedssystemet, du beskriver. Det er ikke det, der driller.

Det der undrer mig er, hvad i systemet der gør, at brugerprogrammer kan oprette en fil, der samtidigt er (eller i hvert fald ender med) at være skrivebeskyttet.

Svaret er at der eksisterer standard-rettigheder for filer, programmer og mapper.

De bliver automatisk tildelt til nye filer, nye programmer, og nye mapper.
Ved kopiering af et program, mistes alle execute, set uid, og set gid bits, og bliver dermed til en almindelig data fil. Det sker også automatisk.
Samtidigt ignorer kernen set uid rettigheder for script af sikkerhedsårsager, dvs. at for scripts bliver rettigheden altid fjernet af kode inde i kernen.

Brugeren har skriverettigheder på mappen/undermapper og som følge af dette, børe Geany, SPE, kWrite og andre ikke lave filer, der er skrivebeskyttede, når brugeren opretter filer med disse programmer.
...

Det er kernen (Linux) der tildeler standard-rettigheder til en nyoprettet fil - ikke et program.

Det der sker et at når et program via et systemkald opretter en fil, så opretter kernen den nye fil via en filsystem device driver, og derefter tildeles filen standard-rettighederne via samme filsystem device driver.
Standard-rettigheder til filer bliver tildelt den nye fil før systemkaldet returnerer til programmet.

Prøv det her:
Da en NAS har sit eget styresystem, så kan du også lave noget rettighesstyring der.

/Lars

[Ole Mose]

Godt - jeg prøver at beskrive det på en anden måde.

Hvis jeg opretter en fil på samme server og mappe fra en Windows maskine, er der ingen problemer. Jeg opretter filen og kan efterfølgende rette i den og gemme den - helt uden problemer. Filen oprettes med fulde rettigheder på såvel bruger, gruppe og ejerniveau.

Gør jeg det samme fra min (K)Ubuntu maskine får jeg i stedet førnævnte problemer.

Således er det ikke NASen der er problemet.

Det er nærmere Samba der driller - sandsynligvis fra min klient. Det er sikkert et forkert parameter, eller måske et problem med den mountede (lokale) mappe.
Men det er ganske besynderligt, at det virker som det gør.

Filer kan oprettes men ikke redigeres?

Tilføjet: Jeg kan se at der er hakket lidt af linjen fra fstab, jeg har indsat i det første indlæg. Den rette linje kan ses her:

Kode: Vælg alt

//192.168.0.40/dev /mnt/synology/dev cifs credentials=/home/ole/.smbcredentials 0 0

De 2 0er manglede

[lath]

Godt - jeg prøver at beskrive det på en anden måde.

Hvis jeg opretter en fil på samme server og mappe fra en Windows maskine, er der ingen problemer. Jeg opretter filen og kan efterfølgende rette i den og gemme den - helt uden problemer. Filen oprettes med fulde rettigheder på såvel bruger, gruppe og ejerniveau.

Gør jeg det samme fra min (K)Ubuntu maskine får jeg i stedet førnævnte problemer.

Således er det ikke NASen der er problemet.

Det er nærmere Samba der driller - sandsynligvis fra min klient. Det er sikkert et forkert parameter, eller måske et problem med den mountede (lokale) mappe.
Men det er ganske besynderligt, at det virker som det gør.

Filer kan oprettes men ikke redigeres?

Tilføjet: Jeg kan se at der er hakket lidt af linjen fra fstab, jeg har indsat i det første indlæg. Den rette linje kan ses her:

Kode: Vælg alt

//192.168.0.40/dev /mnt/synology/dev cifs credentials=/home/ole/.smbcredentials 0 0

De 2 0er manglede

Åh ja, Samba, og ikke NFS.

Du bliver nok nødt at rette i din smb.conf fil indtil det virker (tag backup af filen før du redigere i den).

I smb.conf.5.html kan jeg se at der er en ...

Kode: Vælg alt

read only = yes | no

... indstilling, som jeg gætter på at du synes er meget interessant

Der er også et værktøj - swat(8) - du kan bruge via en browser: http://localhost:901/, når du har startet værktøjet i en terminal.

/Lars

[Ole Mose]

Hvis det monterede netværksdrev var readonly, ville det slet ikke være muligt at oprette en ny fil.
Den option gør det ikke.

Der er noget andet galt. Mon det er cifs, der er problemet?

[lath]

Hvis det monterede netværksdrev var readonly, ville det slet ikke være muligt at oprette en ny fil.
Den option gør det ikke.

Der er noget andet galt. Mon det er cifs, der er problemet?

Eftersom sidste gang jeg brugte Microsoft teknologi var 2008, så du må få hjælp af andre nu.
Jeg melder mig af tråden.

Overvej om din NAS boks trænger til en software-opdatering - der kan være kendte fejl som rettes med en opdatering

/Lars

[Ole Mose]

NASen er fuldt opdateret og den kan ikke være grund til problemet, i og med, at alt fungerer som det skal fra Windowsmaskinerne.

Det er helt fair, at du står af. Jeg tror også, at vi har talt forbi hinanden. Sikkert fordi, jeg ikke har formuleret problemet præcist nok. Det er enormt svært, at beskrive præcist. Men tak for din indsats.
Jeg håber samtidigt, andre vil kigge på problemet med friske øjne - for det er dybt underligt, at det fungerer, som det gør.

Det der er nok så mærkeligt er, at jeg fint kan slette de skrivebeskyttede filer på serveren gennem Dolphin. Det eneste jeg ikke kan er, at gemme ændringer fra diverse editorer.
Det siger mig at Ubuntu og Dolphin sørger for, at jeg korrekt opfattes som den rette bruger på Synology'en. Jeg er ejer af filerne og jeg kan derfor slette dem.

Når jeg arbejder på filerne gennem et brugerprogram (Geany, SPE, kWrite o.a.) , virker det som om programmet opfatter mig som en almindelig bruger - altså ikke med min indloggede brugerprofil. Derfor kan jeg ikke skrive til en fil, der er skrivebeskyttet i forhold til alle brugere.
Det er den eneste logiske forklaring jeg kan finde her og nu.

Spørgsmålet er bare, hvad styrer mon brugerprogrammernes rettighede. Jeg forventer, at de arbejder, som den bruger jeg logger på med gennem indstillingerne i /etc/fstab. Man kunne forestille sig, at det ikke holder stik. Gad nok vide, hvad der skal ændres, for at få det til at fungere?