[Samba] Kan bestanden wel schrijven, maar niet verwijderen

[Verwijderd]

Allen, ik heb een vreemd rechten probleem met samba. Ik kwam hier gisteren achter toen ik bestanden wilde verwijderen van een samba share en mij dat werd geweigerd. Het vreemd is dat ik meerdere shares op dezelfde manier heb die daar geen enkele last van hebben. Hieronder een voorbeeld van 2 van mijn shares, de eerste werkt wel en de tweede niet:

code:

[Files 1]
   comment = Linux bestands server
   path = /usr/files1
   public = no
   valid users = tomb
   read only = no
   writable = yes

[Files 2]
   comment = Linux bestands server
   path = /usr/files2
   public = no
   valid users = tomb
   read only = no

   writable = yes

De mappen /usr/files* hebben beide dezelfde rechten. Misschien dat ik iets heels stoms over het hoofd zie.

Even nog voor de goede orde mijn global settings:

code:

[global]
        workgroup = LINUX
        server string = server
        security = SHARE
        log file = /var/log/samba/%m.log
        max log size = 50
        socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
        os level = 65
        wins support = Yes
        idmap uid = 16777216-33554431
        idmap gid = 16777216-33554431

Wie o wie kan mij helpen ?

[Spider.007]

Wat staat er precies in je samba logfiles? Staan daar interessante meldingen in? Weet je verder zeker dat de rechten op de bestanden in de gebruikte paden gelijk zijn? Als de samba config gelijk is zal daar dan namelijk het probleem niet liggen

[Tux]

Heeft die niet werkende map wel dezelfde eigenaar als de werkende map?

[Verwijderd]

Spider.007 schreef op 23 juni 2004 @ 19:06:
Wat staat er precies in je samba logfiles? Staan daar interessante meldingen in? Weet je verder zeker dat de rechten op de bestanden in de gebruikte paden gelijk zijn? Als de samba config gelijk is zal daar dan namelijk het probleem niet liggen

In de log files staat niks interessants volgens mij. Ik ben er vrij zeker van dat de rechten goed zijn, dit omdat ik de bestanden er zelf op het bezet (op de smb share) via mijn windows xp machine. Het vreemde is dat dit de enige share is met dit probleem en dat deze op dezelfde wijze is aangemaakt als alle andere.

Heeft die niet werkende map wel dezelfde eigenaar als de werkende map?

Ik weet niet precies wat je hiermee bedoelt maar de mappen zijn door mijzelf op mijn windows xp machine aangemaakt. Sommige ook op de server maar zelf chmod 777 kan nergens verandering in brengen.

EDIT:

Als ik ls -l doe in mijn /usr map komt dit eruit:

code:

drwxrwxrwx    6 tom  tom   4096 jun 22 22:58 files1
drwxrwxrwx   11 root root  4096 jun 22 23:02 files2
drwxrwxrwx    3 root root  4096 jun 22 23:07 files3
drwxrwxrwx   15 root root  4096 jun 22 20:11 files4
drwxrwxrwx    5 root root  4096 jun 22 23:10 files5
drwxrwxrwx    7 tomb root  4096 jun 22 17:48 files6

ik krijg het vermoeden dat dat niet kan kloppen, echter is files2 de enige share die mij problemen geeft.

[ Voor 22% gewijzigd door Verwijderd op 23-06-2004 19:32 ]

[Wilke]

chmod 777 is altijd een slecht idee (bovendien verandert dat de eigenaar van de files ook niet).

Hierover zijn al tig topics geweest, waarschijnlijk is het probleem dat je aan de Linux-kant geen rechten hebt om te schrijven in die directory. Als je niet weet wat dat is, wordt het tijd om een basis-handleiding Linux door te gaan lezen.

[Verwijderd]

Wilke schreef op 23 juni 2004 @ 19:33:
chmod 777 is altijd een slecht idee (bovendien verandert dat de eigenaar van de files ook niet).

Hierover zijn al tig topics geweest, waarschijnlijk is het probleem dat je aan de Linux-kant geen rechten hebt om te schrijven in die directory. Als je niet weet wat dat is, wordt het tijd om een basis-handleiding Linux door te gaan lezen.

Ik weet dat chmod 777 niet slim is, maar beveiliging vindt ik niet zo belangrijk. Het zijn maar wat slome files in een thuisnetwerk, dus dat maakt me niet zoveel uit. Over die rechten, ik heb op elke map dezelfde rechten, althans op sommige zag ik net, en daarop werkt het wel.

EDIT:

Door wat hier is gezegd ben ik er inmiddels wel achter wat de bestanden die ik niet kan verwijderen met elkaar gemeen hebben. Ze zijn allemaal via su op de server van cd naar de share gekopieerd. Dit zou de oorzaak kunnen zijn.

EDIT:

Bij nader inzien heb je advies toch ter harte genomen en alle chmod 777 veranderd in 770. Is dat al beter of raad je me iets anders aan ? Misschien 700 om het nog dichter te maken ?

[ Voor 25% gewijzigd door Verwijderd op 23-06-2004 20:10 ]

[viper]

Je moet volgens mij gewoon kijken wie eigenaar is van de directories. Ik durf te wedden dat de dir's die problemen met su (en dus als root) gekopieerd zijn. chown -r tomb files2 zou wel eens wonderen kunnen doen. Oowja.. chmod 775 is ook wel goed..

[Spider.007]

Verwijderd schreef op 23 juni 2004 @ 19:37:
[...]

EDIT:

Bij nader inzien heb je advies toch ter harte genomen en alle chmod 777 veranderd in 770. Is dat al beter of raad je me iets anders aan ? Misschien 700 om het nog dichter te maken ?

Tjah.. de enige juiste oplossing is natuurlijk om alleen execute rechten te zetten op bestanden die dat nodig hebben (waarschijnlijk geen) en directories. De vraag is dan hoe jij je groepen hebt ingedeeld; maar het netste is om de groep alleen leesrechten te geven en world none, of groep ook schrijf en dan world leesrechten.

Als ik jou was zou ik echter het volgende even doen (in de juiste map!):

chmod 640 * -R
find -type d -exec chmod ug+x

[Verwijderd]

Mijn dank is groot, ik zal jullie adviezen opvolgen en kijken wat er van komt. Ik denk dat ik veiligheid toch iets hoger in het vaandel moet gaan zetten en je leert er tevens ook van