|
kami89
Anmeldungsdatum: April 27, 2009
Beiträge: 143
|

22. August 2012 21:26
Hallo zusammen, Auf meinem PC (Ubuntu 12.04) gebe ich ein Verzeichnis per Samba frei, um aus dem LAN darauf zugreifen zu können. Es handelt sich um meine kompletten Eigene Dateien und die Freigabe ist passwortgeschützt. In diesem Ordner existiert ein Ordner "www/", in dem ein paar Webseiten gespeichert sind. Den Webserver möchte ich aber in einer virtuellen Maschine laufen lassen. In dieser VM läuft ebenfalls ein Ubuntu 12.04, mit Apache2, PHP5, MySQL. Nun mounte ich per fstab einfach den freigegebenen Ordner nach /var/www, damit der Server die Webseiten im LAN zur Verfügung stellt. Eigentlich funktioniert das soweit auch wunderbar. Nur ein Problem gibt es: Ich kann per PHP-Befehle (z.B. file_put_contents()) keine Dateien im Ordner der Webseite erstellen (genauer gesagt, die Datei wird zwar erstellt, aber bleibt leer). Mache ich das genau gleiche, aber ohne den gemounteten Ordner, funktioniert es einwandfrei (vorausgesetzt natürlich die Gruppe www-data hat Schreibrechte im entsprechenden Ordner). Ich habe nun keine Ahnung wie ich hinkriegen kann, dass die Webseiten Schreibrechte in deren Ordnern haben. Ausprobiert habe ich schon vieles, aber eher planlos da ich nicht so extrem viel Ahnung von dieser Sache habe. Momentan sieht die Freigabe meiner Eigenen Dateien folgendermassen aus:
| [Eigene_Dateien]
path = /media/Daten/Eigene_Dateien
writeable = yes
; browseable = yes
valid users = urban
create mode = 0777
directory mode 0666
|
Die letzten beiden Einstellungen funktionieren einwandfrei wenn ich in der virtuellen Maschine "von Hand" (also mit dem dort angemeldeten Benutzer) eine Datei im freigegebenen Verzeichnis anlege. Doch Dateien, die vom Webserver erstellt werden, bekommen nur Leserechte für die Gruppe, warum denn das? Weil die Gruppe "www-data" auf meinem lokalen System nicht existiert? In der VM wird die Freigabe folgendermassen eingehängt (fstab):
| //urban-pc-ubuntu/Eigene_Dateien/Elektronik/Part-DB/www /var/www smbfs defaults,user=urban,passwd=*****,gid=33,umask=000 0 0
|
das "gid=33" habe ich nur probeweise mal drin, bringt aber auch nichts (33 ist die Gruppe "www-data"). Ich verstehe nichtmal, wo das Problem überhaupt liegt. Ist die Ordnerfreigabe schon nicht korrekt, oder stimmt etwas in der fstab nicht?
Das freigegebene Verzeichnis liegt übrigens auf einer ext4 Partition. Würde mich freuen wenn mir jemand helfen könnte  Gruss
Urban
|
|
coffeeholic
Supporter
Anmeldungsdatum: Aug. 10, 2012
Beiträge: 1936
Wohnort: zwischen Sessel und Tastatur
|

22. August 2012 21:28
Trag auch testweise mal uid=33 bei den Optionen ein. Das bringt wahrscheinlich den Erfolg.
|
|
kami89
(Themenstarter)
Anmeldungsdatum: April 27, 2009
Beiträge: 143
|

22. August 2012 21:44
coffeeholic schrieb: Trag auch testweise mal uid=33 bei den Optionen ein. Das bringt wahrscheinlich den Erfolg.
Wow, funktioniert tatsächlich einwandfrei!!
Aber ich versteh die Welt nicht mehr. uid steht doch für User-ID, und ein User mit der ID 33 gibts doch gar nicht? Daher kam ich gar nie auf die Idee uid=33 auszuprobieren, uid=1000, uid=0 und uid=1001 (extra angelegter User mit gleichem Namen + Passwort wie mein lokales System) habe ich alles schon ausprobiert, aber auf uid=33 wäre ich nie im Leben gekommen. Naja...so einfach kann es sein wenn man weiss wie es geht  Vielen Dank!
|
|
coffeeholic
Supporter
Anmeldungsdatum: Aug. 10, 2012
Beiträge: 1936
Wohnort: zwischen Sessel und Tastatur
|

22. August 2012 21:45
kami89 schrieb: Aber ich versteh die Welt nicht mehr. uid steht doch für User-ID, und ein User mit der ID 33 gibts doch gar nicht?
Doooooooooooch, das ist www-data. 
|
|
kami89
(Themenstarter)
Anmeldungsdatum: April 27, 2009
Beiträge: 143
|

22. August 2012 21:49
coffeeholic schrieb: kami89 schrieb: Aber ich versteh die Welt nicht mehr. uid steht doch für User-ID, und ein User mit der ID 33 gibts doch gar nicht?
Doooooooooooch, das ist www-data. 
äääh ich glaube ich muss mal das Benutzer/Gruppen-System von Linux ein bisschen genauer studieren  Ich dachte, Gruppe ist Gruppe und Benutzer ist Benutzer, und eine Gruppe ist nicht zugleich auch ein Benutzer?!...
|
|
coffeeholic
Supporter
Anmeldungsdatum: Aug. 10, 2012
Beiträge: 1936
Wohnort: zwischen Sessel und Tastatur
|

22. August 2012 21:56
kami89 schrieb: äääh ich glaube ich muss mal das Benutzer/Gruppen-System von Linux ein bisschen genauer studieren 
Das glaube ich auch Soll jetz kein newbie-bashing sein! *Jedi-Handbewegung* Du willst das Wiki lesen. kami89 schrieb Ich dachte, Gruppe ist Gruppe und Benutzer ist Benutzer, und eine Gruppe ist nicht zugleich auch ein Benutzer?!...
Hmm, nein, das sind verschiedene Dinge! Benutzer und Gruppe sind in Sachen Dateirechte recht unabhängig. Wo wir schon bei dem Thema sind, lies doch bitte auch den Wiki-Artikel über Dateirechte.
|
|
kami89
(Themenstarter)
Anmeldungsdatum: April 27, 2009
Beiträge: 143
|

22. August 2012 22:22
Danke für die Links, aber eigentlich habe ich diese beiden Artikel schonmal gelesen. coffeeholic schrieb: kami89 schrieb Ich dachte, Gruppe ist Gruppe und Benutzer ist Benutzer, und eine Gruppe ist nicht zugleich auch ein Benutzer?!...
Hmm, nein, das sind verschiedene Dinge! Benutzer und Gruppe sind in Sachen Dateirechte recht unabhängig.
Ja eben, dass Benutzer und Gruppen ziemlich unabhängig voneinander sind, davon bin ich ja bis jetzt auch immer ausgegangen. Deshalb verstehe ich nicht, dass man bei einer Benutzer-ID auch eine Gruppen-ID angeben kann, wenn es doch zwei unterschiedliche Dinge sind?! Du schreibst ja, dass die Benutzer-ID 33 zu www-data gehört. Aber www-data ist doch nur eine Gruppe, und kein Benutzer? Im Wiki-Artikel konnte ich diesbezüglich auch keinen Hinweis finden, da werden Benutzer und Gruppen auch als zwei getrennte Dinge behandelt. Ausserdem müsste doch die Angabe der Gruppe in der fstab eigentlich genügen, denn ich brauche ja einfach Zugriff für die Gruppe "www-data". Die Besitzer der Dateien sollte dann doch eigentlich egal sein, solange die Gruppe "www-data" auch Schreibrechte besitzt. Und diese Schreibrechte wollte ich eigentlich mit "umask=000" quasi "erzwingen". Wobei mir jetzt aber gerade etwas klar geworden ist: "User" steht im Zusammenhang mit Dateien wohl eher für "Besitzer" und nicht für "Benutzer", und dass eine Gruppe auch ein Dateibesitzer sein kann leuchtet irgendwie ein. So habe ich es bisher noch gar nicht betrachtet... Trotzdem würde ich meinen, wenn ich einer Datei die Gruppe "www-data" zuordne (was die fstab ja "simulieren" soll) muss doch diese Gruppe auch Schreibrechte haben, völlig unabhängig davon, wer der Besitzer der Datei ist.
|
|
coffeeholic
Supporter
Anmeldungsdatum: Aug. 10, 2012
Beiträge: 1936
Wohnort: zwischen Sessel und Tastatur
|

22. August 2012 22:43
www-data ist der Benutzer, unter dessen Kennung z.B. Apache2 ausgeführt wird.
Benutzer und Gruppe sind bei den Dateirechten völlig unabhängig! Nein, die Angabe der Gruppe allein genügt eben nicht, siehe fett gedrucktes.
|
|
kami89
(Themenstarter)
Anmeldungsdatum: April 27, 2009
Beiträge: 143
|

23. August 2012 00:09
coffeeholic schrieb: Nein, die Angabe der Gruppe allein genügt eben nicht,
Aber wenn ich doch z.B. ein Ordner anlege, dessen Besitzer auf "root" stelle und mein Benutzerkonto als Gruppe zuordne (mit Schreibrecht), dann kann ich darin ja auch Dateien anlegen und löschen, obwohl ich nicht "root" bin. Heisst: In diesem Fall reicht die Angabe der Gruppe aus, der Besitzer ist völlig egal weil man über die Gruppe ja bereits Schreibrechte erhält.
Daher frage ich mich, warum Apache2 kein Schreibrecht in einem Ordner hat, deren Gruppe per fstab ("gid=33") auf "www-data" eingestellt ist. Das will mir einfach nicht in den Kopf gehen.
|
|
coffeeholic
Supporter
Anmeldungsdatum: Aug. 10, 2012
Beiträge: 1936
Wohnort: zwischen Sessel und Tastatur
|

23. August 2012 00:13
Hmm, zeig mal deine /etc/group. Vielleicht ist der User www-data tatsächlich nicht in die Gruppe www-data eingetragen, das wäre dann die Erklärung warum die Angabe der Gruppe allein nicht reichte.
|
|
kami89
(Themenstarter)
Anmeldungsdatum: April 27, 2009
Beiträge: 143
|

23. August 2012 00:24
in der /etc/group gibt es diesen Eintrag für "www-data":
www-data:x:33:
|
|
coffeeholic
Supporter
Anmeldungsdatum: Aug. 10, 2012
Beiträge: 1936
Wohnort: zwischen Sessel und Tastatur
|

23. August 2012 00:29
Das bedeutet, dass im Moment niemand in der Gruppe www-data eingetragen ist. Ja, damit ist die Ursache klar: du musstest uid=www-data zusätzlich zu gid=www-data als Mountoption angeben, weil www-data nicht in der Gruppe www-data eingetragen ist.
|
|
kami89
(Themenstarter)
Anmeldungsdatum: April 27, 2009
Beiträge: 143
|

23. August 2012 00:41
coffeeholic schrieb: Das bedeutet, dass im Moment niemand in der Gruppe www-data eingetragen ist. Ja, damit ist die Ursache klar: du musstest uid=www-data zusätzlich zu gid=www-data als Mountoption angeben, weil www-data nicht in der Gruppe www-data eingetragen ist.
OK ich habe mal folgenden Befehl ausgeführt:
| sudo usermod -aG www-data www-data
|
Und habe die VM neu gestartet. Nun sieht die /etc/group folgendermassen aus:
www-data:x:33:www-data Aber sobald ich "uid=33" wieder aus der fstab entferne, hat Apache wieder keine Schreibrechte mehr. Eigentlich ist es ja jetzt egal, funktionieren tuts mit dem Zusatz "uid=33" ja, aber es würde mich trotzdem interessieren warum es nicht ohne geht 
|
|
Max-Ulrich Farber
Anmeldungsdatum: Jan. 23, 2007
Beiträge: 5545
|

23. August 2012 15:24
//urban-pc-ubuntu/Eigene_Dateien/Elektronik/Part-DB/www /var/www smbfs defaults,user=urban,passwd=*****,gid=33,umask=000 0 0
Ist dieser fstab-Eintrag abgesehen von der zusätzlichen Option uid=33 noch aktuell? Dazu wäre zweierlei zu sagen:
smbfs ist seit Jahren nicht mehr aktuell; es heißt jetzt cifs. Die Bezeichnung smbfs ist nur aus Kompatibilitäts-Gründen noch als Wrapper für cifs zulässig, falls man das Paket smbfs installiert hat (siehe dazu Samba Client cifs). Ich würde das lieber ändern, denn mit der Syntax von smbfs kennt sich bald niemand mehr aus.
Die Option umask=000 gibt es weder bei cifs noch bei smbfs; sie ist deshalb unwirksam, was auch erklärt, dass Du die Option uid=33 brauchst. Statt umask=000 müsste bei cifs stehen dir_mode=0777,file_mode=0666 (siehe dazu man mount.cifs). Wie es bei smbfs heißen muss, weiß ich nicht mehr. Bei cifs sind möglicherweiße dann die UNIX-Extensions aktiv; falls Du uid=... und gid=... verwenden willst, brauchst Du in diesem Fall dann zusätzlich die Option nounix.
Gruß - Max-Ulrich
|
|
kami89
(Themenstarter)
Anmeldungsdatum: April 27, 2009
Beiträge: 143
|

23. August 2012 16:39
Max-Ulrich Farber schrieb: Ist dieser fstab-Eintrag abgesehen von der zusätzlichen Option uid=33 noch aktuell?
Ja, ist er.
smbfs ist seit Jahren nicht mehr aktuell; es heißt jetzt cifs. Die Bezeichnung smbfs ist nur aus Kompatibilitäts-Gründen noch als Wrapper für cifs zulässig, falls man das Paket smbfs installiert hat (siehe dazu Samba Client cifs). Ich würde das lieber ändern, denn mit der Syntax von smbfs kennt sich bald niemand mehr aus.
Ups, das habe ich irgendwie gar nicht mitgekriegt OK habe jetzt auf auf cifs umgestellt.
Ahhh, das erklärt natürlich einiges!
Statt umask=000 müsste bei cifs stehen dir_mode=0777,file_mode=0666 (siehe dazu man mount.cifs). Wie es bei smbfs heißen muss, weiß ich nicht mehr.
Also das mit "uid=..." und "gid=..." funktioniert sogar ohne das "nounix". Die Unix extensions müssten aber eigentlich aktiviert sein, jedenfalls gibt es dazu in meiner smb.conf keinen Eintrag und Standard ist ja "on". Kann das vielleicht daran liegen, dass in der smb.conf die Optionen "create mode" und "directory mode" gesetzt sind? Was ich aber noch komisch finde, ist die Tatsache, dass eben genau diese Optionen "create mode" und "directory mode" gar keine Wirkung haben bei Dateien, die von Apache angelegt werden. Lege ich mit dem ("fremden") Standardbenutzer der VM ganz normal über Nautilus eine Datei im freigegebenen Ordner an, dann habe diese nachher auch diese per smb.conf erzwungenen Rechte. Warum ist das bei Dateien, die von Apache angelegt werden, nicht auch so? mfg
|