Posts by blumenwiese

Quote from Timmeyable

Ich möchte den Speicherort auf den eingesteckten USB Stick verlagern. Dadurch kann ich dann auch über Samba Dateien in den Ordner schmeißen, welche dann auch in Owncloud angezeigt werden.

Ich hoffe ihr versteht was ich meine.

Gruß

Greife doch einfach per WebDAV auf dein Owncloud-Verzeichnis zu, das ist auf jeden Fall die sauberere Lösung, oder muss es unbedingt Samba sein (Windows unterstützt übrigens auch WebDAV)?
Und wenn du deinen USB-Stick permanent angesteckt hast, dann ist das einfachste wahrscheinlich ihn direkt über die fstab immer beim booten gleich mit zu mounten und per bind-Option einen Ordner direkt an der passenden Stelle zu mounten. So hab ichs mit meiner externen Festplatte gemacht.

Also .htacces kanst du, wenn du nginx als Webserver verwendest, gleich mal komplett vergessen, nginx interessiert sich nicht dafür, man hat es aus Sicherheits- und Performance-Gründen anders gelöst.
Die Beispielkonfiguration in dem Link entspricht aber ja im Wesentlichen der hier im Tutorial angegebenen.
Der erste Block sorgt im wesentlichen dafür, dass von http auf https umgeleitet wird, und der zweite konfiguriert den Server dann für https.

Mir ist jetzt aufgefallen, dass wenn ich im Browser direkt Server-IP/core/doc/admin/index.html aufrufen kann, wenn ich das index.html weglasse kommt jedoch ein 403.
Meine Vermutung war jetzt, dass es nicht geht, weil er nach einer index.php sucht, es aber nur eine index.html gibt. Da im owncloud-Verzeichnis neben der index.php auch eine index.html liegt, die, wenn ich sie mir mit meinen kaum vorhandenen html-Kenntnissen mal in einen Editor ansehe, so aussieht, als würde sie nur auf die index.php verweisen, dachte ich mir, es wäre mal einen Versuch wert in der /etc/nginx/sites-available/default mal index index.html; anstatt index index.php; zu schreiben.
Und siehe da, es funktioniert. Die html scheint wirklich nur zu verweisen, weil in der Adresszeile vom Browser steht dann nach wie vor wieder index.php
Vielleicht wäre es sogar eine Überlegung wert, das im Tutorial auch anzupassen

Quote from dreamshader

Das Problem sehe ich eher darin, dass Du es imho nicht geregelt bekommen wirst, dass nur der Benutzer, der auch ein Verzeichnis gemountet hat, es wieder unmounten kann.

Bewirkt die Option "user" in der fstab nicht genau dass normale User die Partition einhängen und nur der, der sie eingehängt hat, wieder aushängen kann? Im Gegensatz zu "users" wo sie jeder wieder aushängen kann und "nouser" wo nur der root was machen kann?

Wenn du es mit Raspbian nicht hinbekommen solltest, kannst du auch mal ipfire ausprobieren. Das ist ein fertiges Linux-System, das schon alle Funktionen, die eine Firewall und ein Router so braucht, mitbringt und auch ein recht komfortabel zu bedienendes Webinterface bietet. Es gibt auch massenweise Plugins für weitere Funktionen. Es gibt dafür ein Image für die ARM-Architektur, das auch auf dem Raspberry Pi läuft. Ich hab das bereits mal ausprobiert. Habe aber nicht viel damit gemacht, weil ich dafür eigentlich keinen Bedarf habe, ich wollte mir das nur mal anschauen

Naja, dass der Pi einfriert, wenn die Festplatte wieder aufwacht, sollte eigentlich nicht sein, das Ziel sollte eher sein die Ursache dafür zu finden und zu beheben

Hast du mal probiert, in der fstab vor der Option "user" zusätzlich noch die Option "noauto" anzugeben? Dann wir der Eintrag nicht beim booten direkt angewendet. Ich weiß nicht genau, wie sich das bei Raspbian verhält, aber wenn es so eingestellt ist, dass es externe Speichermedien sofort mountet, wenn sie angeschlossen (oder eingeschaltet) werden, müsste eigentlich, wenn ein fstab-Eintrag mit der noauto-Option für den Datenträger existiert, es automatisch an der dort angegebenen Stelle eingehängt werden.
Was auch vielleicht noch interessant sein könnte, ist anstatt "user" als Option "users" zu verwenden, das heißt dann dass jeder Benutzer den Datenträger einhängen und jeder ihn auch wieder aushängen darf.
Und wie machst du das mit dem Ausschalten der Platte? Hängst du sie vorher ordnungsgemäß aus, oder schaltest du sie einfach ab? Wenn du sie einfach abschaltest, solltest du noch die Option "sync" verwenden, dann wir der Pufferinhalt immer sofort auf den Datenträger geschrieben. Das ist zwar weniger Effizient, aber dafür kann es nicht passieren dass beim Ausschalten noch Daten im Puffer hängen, die dann verloren gehen.

Stimmt, hätte ich auch drauf kommen können

Aber wenn man das macht, meckert Owncloud erstmal (zu recht), dass das Dateiverzeichnis nicht mehr vor Zugriffen geschützt ist. Das löst man, in dem man hier

location ~ ^/owncloud/(data|config|\.ht|db_structure\.xml|README) {


   deny all;


 }

das "owncloud/" entfernt.

Mir ist aber aufgefallen, dass in Owncloud unter Hilfe die Dokumentation für Benutzer und die Dokumentation für Administratoren sich nicht aufrufen lassen. Stattdessen kommt ein 403. Das Ganze liegt offenbar unter core/doc/. Ich komm jetzt aber nicht drauf, was man an der Konfiguration ändern müsste, um das zu beheben. Es ist jetzt zwar nicht sonderlich schlimm, wenn man da nicht drauf kommt, aber ich hab eigentlich den Anspruch ein System zu haben, das keine Fehlermeldungen ausgeben muss

Ein sehr schönes Tutorial.

Ich habe es jetzt, bevor ich das ganze auf meinen Pi klatsche, es mal auf einem virtuellen Ubuntu-Server ausprobiert und es läuft eigentlich (fast) alles problemlos. Ich habe auf https verzichtet, da er sowieso nur über das Heimnetz und später vielleicht noch über eine verschlüsselte VPN-Verbindung erreichbar sein wird. Meine nginx-Konfiguration sieht jetzt so aus:

server {
listen 80;
  server_name 192.168.178.9;
  
root /var/www;
index owncloud/index.php;
client_max_body_size 1000M; # set maximum upload size
fastcgi_buffers 64 4K;




location ~ ^/owncloud/(data|config|\.ht|db_structure\.xml|README) {
  deny all;
}




location / {
  try_files $uri $uri/ index.php;
}


location @webdav {
  fastcgi_split_path_info ^(.+\.php)(/.*)$;
  fastcgi_pass 127.0.0.1:9000;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_param HTTPS off;
  include fastcgi_params;
}


location ~ ^(?<script_name>.+?\.php)(?<path_info>/.*)?$ {
  try_files $script_name = 404;
  include fastcgi_params;
  fastcgi_param PATH_INFO $path_info;
  fastcgi_param HTTPS off;
  fastcgi_pass 127.0.0.1:9000;
}
}

Ich wollte nicht immer im Browser hinter der IP noch "/owncloud" eingeben müssen und habe deshalb in die Zeile "index index.php;" noch das "owncloud/" eingefügt. Es funktioniert jetzt zwar, dass man nur die IP eingibt (dafür kommt jetzt wenn man das "/owncloud" eingibt den 403-Fehler), allerdings wird man jetzt, wenn man sich im Webinterface ausloggt (Link: http://Server-IP/owncloud/index.php?logout=true), trotzdem noch auf http://Server-IP/owncloud geleitet und bekommt entsprechend einen 403.
Kann man da noch was einstellen um das zu beheben, oder ist es doch besser zur ursprünglichen Konfiguration zurückzukehren?