sshfs Rechte auf dem mountdir ändern schlägt fehl

Probleme mit Samba, NFS, FTP und Co.
Antworten
Benutzeravatar
speefak
Beiträge: 449
Registriert: 27.04.2008 13:54:20

sshfs Rechte auf dem mountdir ändern schlägt fehl

Beitrag von speefak » 22.08.2023 12:30:11

Moin,

Ich habe mein NAS von Debian 10 auf Debian 12 aktualisiert ( Neuinstallation ). Der Webserver läuft in einer Virtualbox VM. In dem Webserver benötige ich 2 Verzeichnisse des NAS ( Backups, und Archiv ) mit unterschiedlichen Rechten auf dem Webserver aber ein Benutzerkonto auf dem Host. Auf dem Host ( NAS ) ist das Benutzerkonto "webserver" .In der Webserver VM wird das webserver home auf dem NAS als Netzlaufwerk über sshfs eingebunden.

Unter Debian 10 konnte ich auf dem WebserverVM Netzlaufwerk innerhalb der VM die Rechte ändern, sodass Datei/Verzeichnis 1 in der VM 755 root:root und Datei/Verzeichnis 2 731 root:root und Datei 3 Verzeichnis 3 755 www-data:www-data gesetzt war. Alles aus der VM heraus. Jetzt bekomme ich die Meldung, dass eine Berechtigung beim Ändern des Benutzers der Datei fehlt.

Mounte ich als user kann ich die Rechte nicht auf www:data oder root ändern. Unter D10 ging das noch.

Das sshfs Backupverzeichnis der WebserverVM soll mit einfachem User über sshfs gemountet werden. In der VM werden mit root rechten Backups in der Verzeichnis kopiert und dann die Rechte der Dateien geändert. Dabei erhalte ich folgende Fehlermeldungen:

Autofs/sshfs optionen:
ntab_Webserver_Storage -fstype=fuse,rw,allow_other,follow_symlinks,noatime,nodev,max_read=65536,IdentityFile=/home/user/.ssh/id_rsa,UserKnownHostsFile=/home/user/.ssh/known_hosts :sshfs\#webserver@NAS:

Code: Alles auswählen


chown: der Eigentümer von '/mnt/autofs/ntab_Webserver_Storage/Backups/Websites/www.website.de/daily' wird geändert: Keine Berechtigung
chown: der Eigentümer von '/mnt/autofs/ntab_Webserver_Storage/Backups/Websites/www.website.de/weekly wird geändert: Keine Berechtigung
chown: der Eigentümer von '/mnt/autofs/ntab_Webserver_Storage/Backups/Websites/www.website.de/monthly' wird geändert: Keine Berechtigung

cp: der Eigentümer für '/mnt/autofs/ntab_Webserver_Storage/Backups/Websites/www.website.de/daily/www.website.de/restore.sh' konnte nicht beibehalten werden: Keine Berechtigung
cp: der Eigentümer für '/mnt/autofs/ntab_Webserver_Storage/Backups/Websites/www.website.de/daily/www.website.de' konnte nicht beibehalten werden: Keine Berechtigung

user allow_other ist in /etc/fuse.conf gesetzt.

Rechte der Verzeichnisse in der VM :

Code: Alles auswählen

drwxr-xr-x 1 speefak speefak 4,0K 22. Aug 10:45 daily
drwxr-xr-x 1 speefak speefak 4,0K 22. Aug 02:06 monthly
drwxr-xr-x 1 speefak speefak 4,0K 22. Aug 02:06 weekly
Rechte der Verzeichnisse auf dem Host/NAS :

Code: Alles auswählen

drwxr-xr-x 9 webserver webserver 4,0K 22. Aug 10:45 daily
drwxr-xr-x 2 webserver webserver 4,0K 22. Aug 02:06 monthly
drwxr-xr-x 2 webserver webserver 4,0K 22. Aug 02:06 weekly

Shared Folder aus der VM über Virtualbox selbst funktioniert in meinem Fall auch nicht fehlerfrei. Das Hauptverzeichnis des Hosts wird korrekt auf dem Gast eingebunden ( /mnt/sf_Main ). Das zweite Verzeichnis ( /mnt/sf_Seconds ) allerdings nicht. Es scheint ein Problem mit den Parsern der sfvbox mounts zu sein, wenn ein Shared Folder mehrfach mit verschiedenen Rechten eingebunden werden soll. Erstelle ich die Mountpoints für die SF Shared Folder manuell und mounte diese manuell funktioniert es manchmal und manchmal ich. Habe ich beide sf Shares manuell gemountet und reboote die VM sind beide Verzeichnisse nach dem reboot nicht mehr vorhanden ( obwohl manuell erstellt ). Verschwindende Verzeichnisse sind mir ein wenig suspekt gerade wenn es um Backups geht. Zudem kann man die Shared Folder auch nicht auf 755 setzen ( XX0 geht ) was o.g. Problem wie bei sshfs verursacht. Das NAS hatte sich einige male komplett aufgehängt als ich mit den Shared Foldern herumprobierte und was mich noch mehr wunderte : Als ich mit den Shared Foldern und deren Konfiguration herumprobierte streikte nach einem Reboot erst Virtualbox ( segmentaition fault ) und nach einem weiteren Reboot dann auch noch der Apache. Ich konnte im journal keinen Fehlermeldung des Apache finden und habe ihne daher kurzerhand einfach neu installiert. Nun läuft alles wieder - komisch ist o.g. Sachverhalt trotzdem.
Fazit zu den Virtualbox Shared Foldern => in meinem Fall so nicht nutzbar ( oder ich habe noch nicht alle Optionen durch )

Da bleibt dann nur sshfs/autofs.

Benutzeravatar
jph
Beiträge: 1049
Registriert: 06.12.2015 15:06:07
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Greven/Westf.

Re: sshfs Rechte auf dem mountdir ändern schlägt fehl

Beitrag von jph » 24.08.2023 13:42:53

Aus deiner Beschreibung entnehme ich, dass du den Webserver in einer VM betreiben willst, um ihn ein Stück weit vom Rest des Systems zu isolieren. Kenne ich, mache ich genau so.

Wenn das NAS und somit die VM in irgendeiner dunklen Ecke headless vor sich hin werkeln, dann erscheint mir die Lösung mit VirtualBox ziemlich kompliziert. KVM/Qemu können das genau so gut; aber unter der Annahme, dass sowohl Host-Betriebssystem auf dem NAS als auch Gast-Betriebssystem für deine VM jeweils Debian (allgemeiner: ein Linux mit gleicher Architektur) sein sollen, ginge das mit LXC am einfachsten und ressourcenschonendsten. Das sshfs fiele dann ebenfalls weg.

Sag Bescheid, wenn du mehr Infos haben möchtest.

Benutzeravatar
speefak
Beiträge: 449
Registriert: 27.04.2008 13:54:20

Re: sshfs Rechte auf dem mountdir ändern schlägt fehl

Beitrag von speefak » 24.08.2023 14:15:52

"Aus deiner Beschreibung entnehme ich, dass du den Webserver in einer VM betreiben willst, um ihn ein Stück weit vom Rest des Systems zu isolieren. Kenne ich, mache ich genau so."

Genau darum geht es ;) SSHFS ist eine Sicherheitslücke, denn die sshfs Mounts erfordern eine sshkey Verbindung ohne PW Abfrage. Aus dem Grund und um Leistung zu sparen ( sshfs benötigt mehr CPU als Shared Folder ) dachte ich an die Shared Folder. /bin/bash für den user auf false zu setzen funktioniert mit sshfs nicht. Man könnte den Webserveraccound auf dem NAS in einen Chroot sperren oder in der .bashrc ein "sleep 2 && exit" ans Ende setzen. Für versierte Hacker wird das kein Hindernis sein aber für viele Scriptkiddies etc. schon. Dazu läuft noch fail2ban und Email Versandt bei SSH Login. Es gibt nur 1 Account für den SSH mit mind. 20 stelligem PW aus allen Zeichen. Das ist schon recht Sicher ;)

Docker, LXC und co Verwende ich aus folgenden Gründen nicht :
- Hardwaredefekt auf dem Server => VM einfach auf einen Host/OS kopieren und Starten ( geht nur mit Hypervisor Class 2 )
- Administration nur über SSH - SSH zugriff ist aber nicht aus jeden Netzwerk möglich - HTTP(S) meist schon

Hypervisor Class 1 ( ESXI / Proxmox ) ist für meine Zwecke eher kontraproduktiv denn für einen HV Class 1 benötige ich eine VM zur Kontrolle des Host/Clusters und auf dem Host läuft nichts außer dem Hypervisor. Da ich aber ein natives OS auf dem Host haben benötige um Kernservices wie NAS, VDR, Backupserver nicht in einer VM laufen lassen möchte, macht KVM/Qemu/Proxmox/ESXi für mich keinen Sinn. Ein HV Class 1 braucht also mindestens 2 VMs mehr als HV Class 2.. Abgesehen davon ist ein natives OS bei der Fehlersuche sehr vorteilhaft.

SSHFS hat auch den Vorteil, wenn ich die Webserver VM auf einen Anderen Host packe sind die SSHFS Mounts im Gegensatz zu den Shared Foldern weiter nutzbar.

Die Shared Folder von Virtualbox habe ich mittlerweile abgeschrieben. Beim einfachen Herumprobieren hats mir den Apache zerschossen und VT-X deaktiviert - Wie und Warum ist ne gute Frage. Bei solchen Fehlern lasse ich die Finger von wilden Testaktionen auf Produktivsystemen und nehme Altbewährtes ;)

Dennoch wundert mich der o.g. SSHFS-mount-Rechtefehler unter D12. Unter D11 konnte ich die Rechte der Dateien und Ordner auf dem SSHFS mount ändern. Unter D12 nicht mehr.

Aktuell habe ich daher versch. SSHFS Mounts mit versch. Rechten am laufen. Funktioniert bis auf die Änderung der Rechte der SSHFS mounts.

Antworten