Aus Gründen habe ich mich in das Web-Interface meines Netgear ReadyNAS eingeloggt. Direkt nach dem Login zeigte es mir eine Benachrichtigung über eine neue Version des Betriebssystems, welche ich direkt installieren ließ. Leider war nach dem Update das Web-Interface nicht mehr verfügbar. Er zeigt zwar den Netgear-Splashscreen, und auch die Authentifizierung erfolgte, aber anschließend wurde die Admin-Oberfläche nicht gelanden. Stattdessen wurde eine Fehlerseite angezeigt, die auf eine nicht hilfreiche Supportseite verlinkte.

Da die Kiste prinzipiell ja erreichbar war und sich auch Shares mounten ließen, konnte es eigentlich keine große Sache sein. Also per ssh verbinden und mal im Log schauen. Stellt sich raus, dass der apache über das php-Modul stolpert:

apache2[2555]: apache2: Syntax error on line 244 of /etc/apache2/apache2.conf: Syntax error on line 1 of /etc/apache2/mods-enabled/php5.load: Cannot load /usr/lib/apache2/modules/libphp5.so into server: /usr/lib/apache2/modules/libphp5.so: cannot open shared object file: No such file or directory

systemd[1]: apache2.service: Control process exited, code=exited statAus=1

Netterweise reicht es, /etc/apache2/apache2.conf und /etc/apache2/apache2.load zu löschen, um dem apache wieder auf die Füße zu helfen. Nun halt ohne PHP, aber das scheint nicht benötigt zu werden.

Ich habe seit einien Jahren ein kleines NAS, um dort Musik, Bilder, Backups und so weiter abzulegen. Nun war es so, dass sich anfänglich die Rechte nicht so sauber konfigurieren ließen, wie man es sich eigentlich wünscht. Und so kam es, dass ein anderer User des Systems nicht auf die Bilder zugreifen konnte, die ich auf dem NAS gespeichert habe und ich umgekehrt nicht auf die Bilder des anderen Users. Dies blieb leider auch so, nachdem die Software in der Lage war, ein sauberes Gruppenkonzept für die Rechtevergabe anzubieten. Damals vermutete ich, dass bereits gesetzte Berechtigungen nicht aktualisiert werden, wenn man die Berechtigungen im Web-Frontend anpasst. Irgendwie habe ich mich aber nicht eingehend mit dem Problem beschäftigt.

Zufällig ergab es sich nun, dass ich auf dem NAS unterwegs war und da dachte ich mir, es wäre ja mal eine gute Gelegeneheit, auch bei die Rechte zu schauen. Im ersten Schritt habe ich mal das klassische ls bemüht. Diese zeigte aber an, dass die Gruppe, in der beide Benutzer sind, eigentlich die korrekten Rechte hätte:

$ ls -dal HDR
drwxrwx---+ 1 pvitt users 258 Nov 13  2013 HDR

Schaut man sich das an, sollte man meinen, dass die Gruppe user Leserechte hätte. Dem ist aber nicht so. Nach einigem Überlegen hat mich dann das kleine + auf die ACLs gebracht. Selbst hatte ich damit noch nicht viele Berührungen (zumindest in der Linux-Welt), daher musste ich erst mal nachlesen. Wie so oft, kam mir hier das ArchLinux-Wiki zu Hilfe. Im ersten Schritt habe ich mir die ACLs für einen Datei anzeigen lassen:

$ getfacl Moi.JPG
# file: Moi.JPG
# owner: pvitt
# group: users
user::rwx
user:admin:rwx
user:pvitt:rwx
group::---
group:admin:rwx
group:users:---
mask::rwx
other::---

Dort sieht man schön, dass sowohl der admin als auch mein User auf die Datei zugreifen dürfen. Auch die admin-Gruppe hat Zugriff. Die interessante Gruppe user allerdings nicht. Im Arch-Wiki ist anschaulich beschrieben, wie man nun für alle Dateien den Schreib- und Lese-Zugriff für eine Gruppe freigibt:

$ setfacl -m "g:users:rwx" -R *

Im Anschluss sieht die Sache dann so aus:

$ getfacl Moi.JPG
# file: Moi.JPG
# owner: pvitt
# group: users
user::rwx
user:admin:rwx
user:pvitt:rwx
group::---
group:admin:rwx
group:users:rwx
mask::rwx
other::---

Ziel erreicht, Zugriff für alle Mitglieder der Gruppe user freigegeben.