---

Jeg har en ekstern hardisk med en USB2-forbindelse til min computer, der
kører Gentoo 2005.0 med udev.

Den har jeg tidligere haft formateret med vfat som filsystem og har så
mountet semi-manuelt på brugerbasis når behovet var der.
fstab: /dev/sda1 /mnt/usbdrive vfat noauto,users,rw 0 0

No worries.

Nu har jeg så valgt at ville have ext3 på den og har derfor skiftet til
ext3 og ændret fstab til:
/dev/sda1 /mnt/usbdrive ext3 noauto,users,rw 0 0

Nu har jeg et mindre problem efter mount af usbdrevet.

Som alm. bruger har jeg ikke skriverettigheder i roden af mountpoint
/mnt/usbdrive.
I underbiblioteker ejet af min bruger (oprettet/chownet af root) er det
dog intet problem.

Jeg er næsten på bar bund. Jeg har mistænkt det for at være et udev
problem, men har efter en del googling ikke kunnet finde en løsning.

Nogen, der kan hjælpe?


--
Regards, Peter
Topposters and other annoying elements will be killfiled in silence.

---

Den Fri, 15 Jul 2005 23:43:04 +0200 skrev Peter G.:
>
> Nu har jeg så valgt at ville have ext3 på den og har derfor skiftet til
> ext3 og ændret fstab til:
> /dev/sda1 /mnt/usbdrive ext3 noauto,users,rw 0 0
>
> Nu har jeg et mindre problem efter mount af usbdrevet.
>
> Som alm. bruger har jeg ikke skriverettigheder i roden af mountpoint
> /mnt/usbdrive.
> I underbiblioteker ejet af min bruger (oprettet/chownet af root) er det
> dog intet problem.
>
> Jeg er næsten på bar bund. Jeg har mistænkt det for at være et udev
> problem, men har efter en del googling ikke kunnet finde en løsning.

Meget simplere.

# mount /mnt/usbdrive
# chown peterg /mnt/usbdrive



Når det er ext3 er der slet ikke noget hokus-pokus, som ved fat.

Mvh
Kent
--
Hard work may pay off in the long run, but lazyness pays off right now.

---

Kent Friis <nospam@nospam.invalid> writes:

>> Som alm. bruger har jeg ikke skriverettigheder i roden af mountpoint
>> /mnt/usbdrive.
>> I underbiblioteker ejet af min bruger (oprettet/chownet af root) er det
>> dog intet problem.
>>
>> Jeg er næsten på bar bund. Jeg har mistænkt det for at være et udev
>> problem, men har efter en del googling ikke kunnet finde en løsning.

Det sjove er, at da jeg brugte det i morges, virkede det uden
problemer.

Jeg kan se at rettighederne (vistnok) har ændret sig
Før mount:
drwxr-xr-x 2 root root 48 15 jul 22:33 usbdrive
Efter mount:
drwxrwxrwx 7 root users 4096 16 jul 00:02 usbdrive

bruger 'peter' er i wheel og users.


> Meget simplere.
>
> # mount /mnt/usbdrive
> # chown peterg /mnt/usbdrive

Vil dette ikke medføre at mountpoint bliver ejet af bruger peterg og at
andre brugere så vil have det samme problem når de manuelt mounter
drevet; mangl. skriverettighed i rod af mountpoint? Er det her
"group"-permissions (f.eks. users) kommer til redningen?

Dette er et teoretisk problem da jeg er den eneste bruger på denne
maskine, men jeg vil gerne lige se om jeg har (mis)forstået noget.

--
Regards, Peter
Topposters and other annoying elements will be killfiled in silence.

---

"Peter G." wrote:
>
> Jeg kan se at rettighederne (vistnok) har ændret sig
> Før mount:
> drwxr-xr-x 2 root root 48 15 jul 22:33 usbdrive
> Efter mount:
> drwxrwxrwx 7 root users 4096 16 jul 00:02 usbdrive

Ikke optimalt. Hvis du vil give skriverettigheder
til alle er det en god idé også at sætte sticky.
Så kan man ikke slette de filer, som andre har
oprettet.

>
> Vil dette ikke medføre at mountpoint bliver ejet af bruger peterg

Nej. Når filsystemet er mountet kan du ikke gøre
noget med mountpointet, chown kommandoen vil virke
på roden af det mountede filsystem.

> og at
> andre brugere så vil have det samme problem når de manuelt mounter
> drevet;

Hvis de mounter samme filsystem hvis rod har angivet
dig som ejer, så kan de ikke uden videre skrive
dertil. Hvad det angår opfører roden af et filsystem
sig nøjagtigt lige som ethvert andet directory.

Overvej at sætte sticky og skriveadgang til en passende
brugergruppe. (chmod 1775 /mnt/usbdrive).

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> Ikke optimalt. Hvis du vil give skriverettigheder
> til alle er det en god idé også at sætte sticky.
> SÃ¥ kan man ikke slette de filer, som andre har
> oprettet.

Heh. SÃ¥ fik jeg endeligt sat mig ind i sticky, SUID og SGID.

> Nej. Når filsystemet er mountet kan du ikke gøre
> noget med mountpointet, chown kommandoen vil virke
> på roden af det mountede filsystem.

Det forklarer hvorfor jeg ikke kunne forstå hvorfor skriveadgang
pludselig virkede. Jeg havde uforvarende vekslet mellem at
chmodde/chowne på et mountet og umountet mountpoint uden at skelne.

> Hvis de mounter samme filsystem hvis rod har angivet
> dig som ejer, så kan de ikke uden videre skrive
> dertil. Hvad det angår opfører roden af et filsystem
> sig nøjagtigt lige som ethvert andet directory.
>
> Overvej at sætte sticky og skriveadgang til en passende
> brugergruppe. (chmod 1775 /mnt/usbdrive).

Det vil jeg gøre. Især fordi jeg vil se hvordan sticky virker i praksis.
Tak for en meget lærerig post.

--
Regards, Peter
Topposters and other annoying elements will be killfiled in silence.

---

"Peter G." wrote:
>
> Nu har jeg så valgt at ville have ext3 på den og har derfor skiftet til
> ext3 og ændret fstab til:
> /dev/sda1 /mnt/usbdrive ext3 noauto,users,rw 0 0

Har du overvejet at skrive auto i filsystems feltet?

Du bør nok også overveje at smide lidt flere options
på. F.eks. noauto,users,nodev,nosuid,errors=remount-ro

>
> Nu har jeg et mindre problem efter mount af usbdrevet.
>
> Som alm. bruger har jeg ikke skriverettigheder i roden af mountpoint
> /mnt/usbdrive.

Ret ejerskab og/eller permissions på roden af dit nye
filsystem.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> "Peter G." wrote:
>>
>> Nu har jeg så valgt at ville have ext3 på den og har derfor skiftet til
>> ext3 og ændret fstab til:
>> /dev/sda1 /mnt/usbdrive ext3 noauto,users,rw 0 0
>
> Har du overvejet at skrive auto i filsystems feltet?

Ja, men fravalgte det tidligere da jeg mente specificeret filtype gav mig
bedre overblik over fstab. Da jeg ikke er klar over hvor effektiv 'auto' er
til at genkende filsystemer, valgte jeg den sikre metode.

> Du bør nok også overveje at smide lidt flere options
> på. F.eks. noauto,users,nodev,nosuid,errors=remount-ro

'nodev' og 'nosuid' er SVJV implicit i users. 'errors' er værd at
overveje, selvom data på drevet er langt fra essentielle.

> Ret ejerskab og/eller permissions på roden af dit nye
> filsystem.

Ok.

--
Regards, Peter
Topposters and other annoying elements will be killfiled in silence.

---

"Peter G." wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> > Du bør nok også overveje at smide lidt flere options
> > på. F.eks. noauto,users,nodev,nosuid,errors=remount-ro
>
> 'nodev' og 'nosuid' er SVJV implicit i users.

Det kan da godt være, det vil jeg undersøge ved lejlighed.

> 'errors' er værd at
> overveje, selvom data på drevet er langt fra essentielle.

Det er ikke spørgsmål om, hvor vigtige data på drevet er.
Grunden til jeg synes man skal angive errors i fstab er,
at ellers er det indholdet af filsystemet, der bestemmer.
Et passende konstrueret filsystem vil forårsage en kernel
panic ved mount, med mindre fstab overrider den opførsel.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

>> 'errors' er værd at
>> overveje, selvom data på drevet er langt fra essentielle.
>
> Det er ikke spørgsmål om, hvor vigtige data på drevet er.
> Grunden til jeg synes man skal angive errors i fstab er,
> at ellers er det indholdet af filsystemet, der bestemmer.
> Et passende konstrueret filsystem vil forårsage en kernel
> panic ved mount, med mindre fstab overrider den opførsel.

Ja, så er 'errors' en god ting at bruge ved et eksternt drev.

--
Regards, Peter
Topposters and other annoying elements will be killfiled in silence.