Hallo würe gerne mit meinem NX21 Storage Share Multimedia Dateien stream, ohne vorab herunter laden zu müssen. Eigentlich ist dieses NX21 Storage Share ein geiles Produkt, aber wirklich nichts für B2C. Keine Ahnug wie man sowas einrichtest, hatte mit keinem Cloudanbierter solche schwierigkeiten. Auch keine Ahnung warum unter Linux nur dieses Spiegeln in der App möglich ist, kann doch nicht so wahnsinnig schwer sein auch nur uploads oder nur downloads mit zu intergrieren, oder sehe ich es falsch.
Zwar fand ich eine Anfrage, war aber von 2021 und da hieß es geht so ohne weiteres nicht???
Wäre super wenn mir jemand weiterhelfen könnte.
Dankeschön, Webdav und Streaming sind nicht dasselbe. Habe zB Webdav im Dolphin eingerichtet aber VCL, sowie Haruna Streamen nicht, sondern laden trotz webdav schön erstmal komplett herunter und genau dieses wollte ich ja meiden. Auch wäre es schön wenn anstelle eines naja App Passwort echte 2 getrennte OTP gäbe. Da nicht umsonst viele sich von Webdav distanzieren, bzgl. des token. Wollte aber keine Diskusion aufmachen warum Flatz nicht gleich falt ist oder Webdav naja mit app PW umgangen wird befglich der 2fa. Mir gehts wirklich nur primär um echtes streaming und wenn machbar dennoch ohne meine Cloud in Gefahr zu bringen.
Ich fürchte die einzige möglichkeit wäre wirklich ne VM mit Windows drauf weil Linux zu blöde oder wegen Kernel-Zoo es nunmal keine bis kaum Viruelle Lafwerke kennt für privat user?
Du kannst auch lokal auf dem Nextcloud-Server einem WebDAV-Mount einrichten und diesen dann per NFS oder FUSE/sshfs von einem anderen Linux-Client aus nutzen. Wenn es eh nur lesend sein soll kann man auch per NFS oder FUSE/sshfs direkt auf auf das entsprechende Verzeichnis unterhalb von /var/nextcloud_data zugreifen. Geht dann aber nur lesen, wegen Eigentümer der Dateien dort (ist ja normal www-data).
Möglichkeiten gibt es da diverse zur Auswahl, ganz besonders mit Linux.
Zu deinen WebDAV-Sicherheitsbedenken:
Nutze dann halt einen eigenen User nur für die Files, die gestreamt werden sollen
dann sind im Zweifel nur die zu streamenden Inhalte gefährdet
Ist das so. Also wenn ich bei mir in GNOME meine Nextcloud via WebDAV verbinde, fängt ein Video sofort an zu laufen wenn ich es doppelcklicke, fast so als würde VLC es streamen
Kannst du erklären was du hier genau meinst?
Aha “man” distanziert sich also davon. Interessant.
App Passwörter sind gängige Praxis, wenn eine Client App halt den Login-Flow eines Dienstes nicht direkt unterstützt. Ist bei anderen Diensten wie Google oder Microsoft auch nicht anders.
Zudem kann man unter Linux Freigaben (egal ob WebDAV, Samba,FUSE/sshfs) auch via /etc/fstab direkt ins Filesystem einbinden. Dann sollten Anwendungen wie VLC gar nicht bemerken, dass es sich um eine Freigabe auf einem Server handelt. Als <options> empfiehlt sich dann die Angabe von user,noauto, damit das entfernte Filesystem nur bei Bedarf mit Rechten der normalen User eingebunden wird und den Boot-Vorgang nicht verzögert, sollte es sich um ein mobiles Gerät (Notebook) handeln, das nicht immer Zugriff auf die Freigabe haben kann.
@adelaar Ich denke, er mixt hier verschiedene Dinge durcheinander. Er meint einerseits den Nextcloud-Client bzw. dessen limitierte „Platzhalter-Virual-Files“-Funktion unter Linux. Und ja, damit muss das Video zuerst vollständig heruntergeladen werden.
Via WebDAV in KDE ist das nicht so. Aber ein App-Passwort braucht es wohl dafür, und das gefällt ihm auch nicht, weil es theoretisch unsicherer als 2FA ist.
@iniliner: Zum Thema „die Cloud in Gefahr bringen“: Ja, App-Passwörter sind theoretisch weniger sicher als eine Anmeldung mit 2FA. Damit daraus aber ein reales Sicherheitsproblem wird, müsste das App-Passwort zunächst einmal kompromittiert werden. Von außen lässt es sich praktisch nicht sinnvoll per Brute Force erraten.
Das realistischere Szenario wäre Schadsoftware – etwa ein Infostealer –, der das App-Passwort aus KWallet (oder einem anderen Passwortspeicher) ausliest und an einen Angreifer übermittelt.
Ansonsten bleibt dir im Moment leider nicht viel anderes übrig. Du könntest:
den offiziellen Sync-Client verwenden und bei begrenztem Speicherplatz nur ausgewählte Ordner synchronisieren,
einen separaten Nextcloud-Benutzer für das Streaming anlegen, wie es @adelaar bereits vorgeschlagen hat.
einen Videoplayer nutzen, der den Nextcloud-Login-Flow unterstützt (ich kenne allerdings keinen),
OAuth/OIDC mit Nextcloud und einem Videoplayer verwenden, der das unterstützt (noch unrealistischer ),
oder gleich eine dedizierte Streaming-Lösung wie Plex oder Jellyfin nutzen.
Aber ja, ich sehe das grundlegende Problem durchaus: Mit dem offiziellen Nextcloud-Client gibt es derzeit keine echte „Virtual Files“-Lösung für diesen Anwendungsfall. Und ehrlich gesagt glaube ich auch nicht, dass wir in naher Zukunft eine offizielle Lösung dafür sehen werden unter Linux. Also, WebDAV und App-Passwort “it is”.
Hallo @bb77, dass @iniliner da verschiedene Dinge vermischt ist mir auch schon aufgefallen, ebenso dass seine Bedenken hinsichtlich WebDAV und App-Passwörtern evtl. etwas übertrieben sein könnten.
Aus diesem Grund schlug ich ja bereits vor, eine WebDAV-Freigabe direkt auf dem Nextcloud-Server in dessen /etc/fstab einzurichten und eben (wie nun auch von dir vorgeschlagen) einen separaten User für das Streaming anzulegen.
Wer sich etwas mit WebDAV befasst hat, weiß, dass man die dafür erforderlichen Credentials eben nicht in der für alle lesbaren /etc/fstab ablegen muss, sondern es zwei sichere Optionen dafür gibt. Entweder man nutzt
die systemweite secrets-Datei oder
die lokalen secrets-Datei des/der User
In beiden Fällen setzt man die Zugriffsrechte auf 600. Macht man das nun nur auf dem NC-Server in dessen /etc/fstab und es gelingt irgendwem diese secrets-Datei zu lesen und so an das App-Passwort zu gelangen, dann wurde der Server derart kompromittiert, dass das dann auch irrelevant ist, denn der Server selbst ist dadurch als gehackt zu betrachten.
Hat man nun eine lokale Freigabe per WebDAV, kann man deren Mountpoint in der /etc/fstab z.B. per FUSE/sshfs freigeben. Diese Freigabe wirderum sollte dann Public-Key-Authentifizierung in der Datei ~/.ssh/authorized_keys des Zielsystems (Server) abgesichert werden. Zusätzlich kann der private Schlüssel des Benutzers noch per Passphrase gesichert werden. Das ist dann auch eine Art 2FA, denn man benötigt für den Zugang per FUSE/sshfs zum Server eben nicht nur den privaten Schlüssel (Datei) des Benutzers sondern auch das zugehörige Passwort.
Auch die FUSE/sshfs-Freigabe kann dann in die /etc/fstab eingetragen werden und einen lokalen Mountpoint bekommen..
PS: ist zwar alles ein wenig wie mit den berühmten “Kanonen auf Spatzen schießen”, aber wer große Angst vor Spatzen hat macht vielleicht auch das
Das Problem ist nicht der Server. Der kann realistisch nicht via App Passwort direkt von aussen gehackt werden (also ja ausser es gibt irgendeinen ZeroDay in der Serversoftware, die das ermöglicht).
Das Problem ist Infostealer-Malware auf dem Client-PC. Die kriegt man auf Linux z.B. dann, wenn man die #1 Distro auf Distrowatch installiert hat, und “random” (orphaned) Packages aus dem AUR installiert
EDIT: Aber ja, wenn man sich so etwas eingefangen hat, muss man sowieso jeden Account, bei dem man sich mit diesem PC eingeloggt hat, als kompromittiert betrachten. Diese Dinger können theoretisch auch Session-Cookies usw. klauen. Da hilft dann auch 2FA nicht mehr.
Wenn man Angst vor Infostealer-Malware auf dem Client-PC hat, muss man für den Zugriff per ssh und FUSE/sshfs auf den Nextcloud-Server auch echtes 2FA verwenden. Ich mache das mittels SSH-Login mit 2-Faktor-Authentifizierung per libpam-google-authenticator. Das greift dann auch beim Mounten einer FUSE/sshfs-Freigabe. Wer das Smartphone zur Erzeugung des TOTP nicht hat kommt nicht auf den Server.
Außer natürlich, du bist im Browser noch mit einer langlebigen Sitzung eingeloggt.
Aber ja, klar: Man kann den Client zusätzlich absichern und auf dem Server beispielsweise kürzere Session-Laufzeiten konfigurieren.
Ich selbst nutze für SSH übrigens WebAuthn mit meinem YubiKey über einen Jump Host. Gleichzeitig melde ich mich aber natürlich auch gelegentlich über den Browser bei Nextcloud an und nutze die GNOME-Online-Konten-Anbindung für Kalender und Kontakte, und auch den Nextcloud Client. Gnome Accounts verwendet inzwischen den Nextcloud-Login-Flow, und der Nextcloud Clinet sowieso.
Keine Ahnung, ob sich daraus theoretisch irgendwelche Tokens oder andere Anmeldedaten extrahieren ließen, die sich für einen Remote-Angriff missbrauchen ließen. Dafür stecke ich ehrlich gesagt nicht tief genug in der Materie.
