[Sammelthread] Proxmox Stammtisch

Du musst die Berechtigungen im Filesystem anpassen. Im Container den Order an den User geben unter dem Paperless läuft.
Gibt's dafür irgendwo nen pfiffiges tutorial? Habe wie der Fragesteller paperless unter docker. Auf dem host ist ein share eines Samba gemountet. Da möchte ich paperless neue Dokumente einsammeln lassen (consume Ordner). Ich bin allerdings frisch in proxmox und docker, weshalb ich nicht verstehe, wie ich das umsetzen kann. Ein tutorial könnte ich aber sicher auf meine Umgebung adaptieren.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich habe mal eine Frage an die Menge.
Traut ihr bei Updates den Community Repository von Proxmox oder macht bezahlt ihr für das Enterprise Repository?

Gibt es noch eine kostenlose Lösung um ggf. den Server auf halbwegs aktuellen Stand (aber stabil) zu halten? Ich brauch nicht immer das aller neuste im Homelab.
 
ich hatte nur einmal ein Problem, das nach einem Update inkl. Kernelupdate keine USB-Geräte mehr an die VMs durchgereicht wurden, einfach alten Kernel aktiviert und gut war.
Ansonsten bisher seit Jahren keine weiteren Probleme mit Updates aus dem no-subscriptions -Repository.
Ansonsten warte halt immer einige Tage, bzw. ich selbst schaue eh nicht jeden Tag nach, ob es neue Updates gibt.
 
@Senator Wurstbein
Ein Tutorial kenne ich nicht, kann aber ein paar Ausszüge aus meiner Konfig für Immich Posten ;)
Config auf dem Samba Server
Code:
root@pve:~# cat /etc/cockpit/zfs/shares/SSD_share_immich.conf
# COCKPIT ZFS MANAGER
# WARNING: DO NOT EDIT, AUTO-GENERATED CONFIGURATION
[immich]
        path = /SSD/share/immich
        comment = ZFS: SSD/share/immich
        browseable = yes
        read only = no
        guest ok = no

# ADD ADDITIONAL CONFIGURATION HERE
        valid users = <SMB-USER>
        force user = <SMB-USER>
root@pve:~# ls -ld /SSD/share/immich/
drwxrwxr-x 2 immich share 2 Nov  7 18:08 /SSD/share/immich/
root@pve:~# id immich
uid=51003(immich) gid=50000(share) groups=50000(share)

Config auf dem SMB Client
Code:
root@home:~# id immich
uid=1001(immich) gid=1001(immich) groups=1001(immich)
root@home:~# cat /etc/fstab |grep immich
//192.168.40.253/immich                 /immich         cifs    username=<SMB-USer>,password=<SMB-Password>,uid=immich 0 0

Und die Docker Compose Config vom immich bezogen auf den Pfad und User
Code:
name: immich

services:
  immich-server:
    environment:
      - PUID=1001
      - PGID=1001
    volumes:
      - /immich:/usr/src/app/upload

Ich hoffe das hilft
 
Zuletzt bearbeitet:
Ich habe mal eine Frage an die Menge.
Traut ihr bei Updates den Community Repository von Proxmox oder macht bezahlt ihr für das Enterprise Repository?
Das Community Repo ist völlig ausreichend. Das Support Paket bucht man eher, um zeitnahe Lösungen bei Problemen zu erhalten.
Gibt es noch eine kostenlose Lösung um ggf. den Server auf halbwegs aktuellen Stand (aber stabil) zu halten? Ich brauch nicht immer das aller neuste im Homelab.
In dem Fall kannst Du einen beliebigen Stand auch einfach so lange fahren, bis es neue Features gibt, wo Du sagst "das da, das will ich haben".
 
Sodale.
Habe mir ein 8" Full HD Monitörchen geholt (ziemlich nice, leicht, portabel mit Gehäuse, klebt jetzt mit Klettverschluss an meinem kleinen Serverschränkchen und habe so direkt die Möglichkeit zu gucken :d) und habe das Problem direkt gesehen

Anhang anzeigen 1058804

Die NVME wird ejected und read-only wieder eingehangen.

Scheint wohl ein nicht sooooo neues Problem zu sein

Werde dem dann mal auf die Spur gehen.
Smart Werte der NVME sehen gut aus.
So, die Kiste läuft nun stabil.

Es war wohl so, dass Linux die NVME in den Ruhemodus versetzt hat, dann neu gemountet aber read only.

Lösung:
Grub Config anpassen.
/etc/default/grub --> GRUB_CMDLINE_LINUX_DEFAULT="quiet nvme_core.default_ps_max_latency_us=0"
nvme_core.default_ps_max_latency_us=0 hinzugefügt.
 
Gibt's dafür irgendwo nen pfiffiges tutorial? Habe wie der Fragesteller paperless unter docker. Auf dem host ist ein share eines Samba gemountet. Da möchte ich paperless neue Dokumente einsammeln lassen (consume Ordner). Ich bin allerdings frisch in proxmox und docker, weshalb ich nicht verstehe, wie ich das umsetzen kann. Ein tutorial könnte ich aber sicher auf meine Umgebung adaptieren.

Wenn Paperless in einem LXC läuft, kannst du den Ordner vom Server auch als Mountpoint durchleiten. Aber wenn der Share nicht am Proxmox oder eine lokalen LXC gehostet wird, würde ich den Share innerhalb deiner Docker Umgebung mounten.
 
Zum Thema Write Amplification:
1736074267108.png
Haupt-SSD im Proxmox (da liegen die ganzen Service VMs drauf, die 24/7 laufen).
qcow2-files auf ZFS-Dataset...

Frage an die Mannschaft:
Wie bekomme ich die ganzen QCows am einfachsten in ZFS ZVOLs migriert?

//Edith:
Antwort:
1736075469497.png
1736075578684.png

Habs:
Einfach die Disk auf ein leeres Dataset bewegen, dann wird automatisch ein ZVOL erstellt.
Delete Source nicht vergessen. =)
 
Zuletzt bearbeitet:
Hi,

ich habe auf einem Lenovo M910q tiny Proxmox laufen und wollte die WLAN M2 Karte gegen eine 2.5GB Karte tauschen.
Nur leider ist das Netzwerk nach dem Tausch "tot" und ich kann mich nur noch lokal anmelden. Also sagen wir mal die lokale IP ist 192.168.0.10, WLAN wird nicht verwendet.
Nach dem Tausch, auch ohne dass ich ein Kabel in die 2. NIC mit 2.5GB stecke, lässt sich das Gateway unter 192.168.0.1 nicht mehr pingen.

Hier ist die /etc/network/interfaces:

Code:
auto lo
iface lo inet loopback

iface eno2 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.0.10/24
        gateway 192.168.0.1
        bridge-ports eno2
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

iface wlo1 inet manual

Das neue Interface hieß irgendwas wie "enp3s0" und ich habe es manuell reingenommen, wlo1 rausgenommen, hin- und hergetauscht aber nichts hilft.
Bin etwas lost, habe auch keine Lust Proxmox neu zu installieren.

Hat jemand eine Idee?
 
Die PCI Geräte werden fortlaufend durchnummeriert. Steckt man was dazu oder entfernt etwas (WLAN oder auch Nvme SSDs). ändert sich u.a. der generische Name der Netzwerkkarte.

Abhilfe: statische Namen für die Netzwerkkarte vergeben.

Dateien anlegen - für jedes Interface eine eigene Datei

Pfad: /etc/systemd/network

# Datei Parameter
NAME.lnk
zb: 10-en_lan2.link
maske 644
encoding uft-8 ohne BOM

### wichtig: keine Namen mit eth... verwenden, die namen sind reserviert!!
### Name muss mit "en" beginnen!

 
Die PCI Geräte werden fortlaufend durchnummeriert. Steckt man was dazu oder entfernt etwas (WLAN oder auch Nvme SSDs). ändert sich u.a. der generische Name der Netzwerkkarte.

Abhilfe: statische Namen für die Netzwerkkarte vergeben.

Dateien anlegen - für jedes Interface eine eigene Datei

Pfad: /etc/systemd/network

# Datei Parameter
NAME.lnk
zb: 10-en_lan2.link
maske 644
encoding uft-8 ohne BOM

### wichtig: keine Namen mit eth... verwenden, die namen sind reserviert!!
### Name muss mit "en" beginnen!

so hab es mir durchgelesen.
Aber daraus folgt ja, dass das System schon predictable Names bekommt und dort nichts getauscht wurde?
Erklärt für mich dann nicht das Problem dass dann quasi gar kein LAN mehr funktioniert, also das Gateway nicht pingbar ist. die neue Hardware wurde übrigens erkannt mit dem richtigen Chip

edit: hab in einem 2. Server übrigens auch die m2 eingebaut, eingerichtet und es läuft problemlos nach anpassen der /etc/network/interfaces Datei, denke also nicht dass ich ganz grundlegend etwas falsch mache
 
Zuletzt bearbeitet:
Hier nochmal die Checkliste:

Per default bekommen die Netzwerk Interfaces fortlaufend durch nummerierte Namen wie z.B. "enp35s0" , "enp3s0" , whatever...

Wenn man statische Namen haben möchte, sind 2 Änderungen notwendig:

1) Neue Datei "10-en_lan0.link" in /etc/systemd/network erzeugen, passend zur MAC der Netzwerkkarte

<-- Inhalt Text Datei--->

[Match]
MACAddress=77:88:99:13:14:15

[Link]
Name=10-en_lan0

<-------Ende --->

2) in /etc/network/interfaces den alten Interface Namen (enp35s0) durch "en_lan0" - passend zum o.g. Dateinamen ändern.

Und neustart nicht vergessen, oder den Dienst neu starten.
 
Das Community Repo ist völlig ausreichend. Das Support Paket bucht man eher, um zeitnahe Lösungen bei Problemen zu erhalten.

In dem Fall kannst Du einen beliebigen Stand auch einfach so lange fahren, bis es neue Features gibt, wo Du sagst "das da, das will ich haben".
Also du meinst dann nur die Debian und Debian Security Updates installieren und ceph und pve nur bei Bedarf installieren?
 
@Senator Wurstbein
Ein Tutorial kenne ich nicht, kann aber ein paar Ausszüge aus meiner Konfig für Immich Posten ;)
Config auf dem Samba Server
Code:
root@pve:~# cat /etc/cockpit/zfs/shares/SSD_share_immich.conf
# COCKPIT ZFS MANAGER
# WARNING: DO NOT EDIT, AUTO-GENERATED CONFIGURATION
[immich]
        path = /SSD/share/immich
        comment = ZFS: SSD/share/immich
        browseable = yes
        read only = no
        guest ok = no

# ADD ADDITIONAL CONFIGURATION HERE
        valid users = <SMB-USER>
        force user = <SMB-USER>
root@pve:~# ls -ld /SSD/share/immich/
drwxrwxr-x 2 immich share 2 Nov  7 18:08 /SSD/share/immich/
root@pve:~# id immich
uid=51003(immich) gid=50000(share) groups=50000(share)

Config auf dem SMB Client
Code:
root@home:~# id immich
uid=1001(immich) gid=1001(immich) groups=1001(immich)
root@home:~# cat /etc/fstab |grep immich
//192.168.40.253/immich                 /immich         cifs    username=<SMB-USer>,password=<SMB-Password>,uid=immich 0 0

Und die Docker Compose Config vom immich bezogen auf den Pfad und User
Code:
name: immich

services:
  immich-server:
    environment:
      - PUID=1001
      - PGID=1001
    volumes:
      - /immich:/usr/src/app/upload

Ich hoffe das hilft
Das hilft auf jeden Fall schon mal weiter, danke. Grundsätzlich sollte das reichen, um es auf meine Umgebung anzupassen.

Vorab muss ich aber wohl noch ein paar andere Dinge nachlesen - mir war als docker-neuling noch nicht bewusst, dass Container als root laufen. Das scheint normal, aber nicht sicher zu sein, nachdem was ich bisher so gelesen habe. Das sollte ich dann wohl erst korrigieren und dann den neuen User benutzen.

Und zweitens ist mir bei deinem Beispiel nicht ganz klar, warum sich uid/gid auf dem Samba ändern. Weil es id's eines anderen hosts sind? Und wenn ja wie finde ich raus, welche ID auf dem samba gültig ist bzw. welche dort ankommt, wenn ich den docker User nutze?
 
Für den Wechsel der UID/GID ist mein Beispiel auch nicht einfach, weil der User auf beiden Seiten gleich heißt, aber eine andere ID hat ;)

Die Magic passiert im Grunde in der FSTAB mit der username=<SMB-USer> und uid=immich
Hier steht frei interpretiert im Grunde folgendes:
Gebe dich als SMB-User am Samba Server aus um mit der UID SMB-User (UID 51003) auf die Daten zuzugreifen.
Aber hänge das Filesystem mit UID IMMICH (UID 1001) bei mir ein.

Ein kleines bisschen Magie entsteht noch durch das FORCE USER in der smb.conf, da hier unabhängig vom User der auf den Share Zugreift, alle Daten immer mit der UID des angegebenen Users erzeugt werden. Solange nur ein Nutzer verwendet wird ist das egal.
Greifen mehrere Nutzer oder Gruppen zu kann es zu interessanten Problemen kommen, siehe dazu auch das Ubuntu Wiki
 
Also du meinst dann nur die Debian und Debian Security Updates installieren und ceph und pve nur bei Bedarf installieren?
Ich meine das generell. Ein Proxmox hängt i.d.r nicht am Internet und da surft auch keiner drauf rum, der managt nur VMs, und hängt idealerweise im separaten Management vLAN. Wie heisst es so schön: never change a runnig System. Wenn alles läuft wie es soll, *muss* man nicht ständig Updates machen - mehr wie stabil laufen geht nicht. Welche Gefahr von ev. Sicherheitslücken ausgeht, hängt stark vom Einsatzszenario ab. In kleinen oder abgeschotteten Netzen würde ich mal sagen, das man den Punkt vernachlässigen kann. Sind die PVEs zentraler Bestandteil in einer großen Firma oder Rechenzentrum, sieht das anders aus.

Da ist dann die größere Gefahr, das durch Updates bzw neue Features irgendwas inkonsistent wird, so wie letztes Jahr mit den Kernel Updates, die nicht richtig gestestet wurden.
 
Der schnellste SMB Server unter Linux/Proxmox ist ksmbd
Mit Proxmox 8.3 gibt es ein Problem mit Shares auf ZFS (Dateien unsichtbar)

Bei servethehome habe ich einen Tipp erhalten um das zu beheben

Code:
echo "deb http://deb.debian.org/debian/ bookworm-backports main" > /etc/apt/sources.list.d/debian-backports.list
apt update
apt install -t bookworm-backports ksmbd-tools

In napp-it cs kann man jetzt damit wieder SAMBA deaktivieren und ksmbd nutzen
 
Ich hätte mal eine Frage zum Backup bei Proxmox im Homelab.

Klar kann ich auf dem PVE auch noch einen PBS als VM installieren und die zu sichernden Daten auf einen externen NAS auslagern, aber macht das so Sinn?
Reicht es mir dann im Backup-Notfall PVE und ein neue PBS VM zu installieren und das Backup in den PVE einspielen?
Oder brauche ich genau die PBS VM mit der das Backup erstellt wurde?
Für den Fall brächte ich noch ein Backup der PBS VM ... das würde es natürlich sehr unpraktisch machen.
 
Ich habe die Einstellungen, die ich für proxmox selbst vorgenommen habe, dokumentiert. Die VMs werden regelmässig aufs NAS gesichert, mittels Standard-Backup von PVE selbst. Wichtige VMs sichere ich darüber hinaus noch auf die Hetzner Storage Box. Ich behalte die 5 letzten Versionen.

Die NAS Backups laufen zügig durch. Die Offsite Backups bei Hetzner laufen in der Nacht und kommen durch. Ich sichere so 20-30 gb in der Nacht. 30 MBit Upload.

PBS ist aus meiner Sicht "overkill" für Homelabs.
 
Ich hab hier n PBS laufen, warum auch nicht. War auf 15 Minuten eingerichtet und macht Backups auf mein NAS und zu Tuxis. Läuft auch direkt als VM in meinem Proxmox.
 
Ich hab hier n PBS laufen, warum auch nicht. War auf 15 Minuten eingerichtet und macht Backups auf mein NAS und zu Tuxis. Läuft auch direkt als VM in meinem Proxmox.
Das heißt bei dir ist alles in einem PVE integriert.
Hast du dann von der PBS-VM noch ein separates Backup wie oben von @you beschrieben oder reicht es im Fall dann einfach nur den PVE und PBS neu zu installieren?
 
Das heißt bei dir ist alles in einem PVE integriert.
Ich habe das auch.

PBS als .deb Paket direkt mit auf dem PVE Host installiert. Dieser hat dadurch direkten Zugriff auf eine dedizierte SSD.
Allerdings ist das nur mein Sekundärer PBS, dieser hohlt sich immer die Daten vom primären, welcher von Tuxis ist.


Man muss bei einer neu installation die Keys von der Ersteinrichtung sichern (verschlüsselung der Backups etc.)
Ging so bei mir durch HW Wechsel ohne Probleme.

Allerdings kann ein eigener Test nicht schaden, um zu sehen worauf man achten muss, und was ggf extra gesichert werden muss - das würde ja, je nach HW Ressourcen mit einem nestet pve und PBS VM ja vergleichsweise einfach gehen. Oder zu Not am lokalen PC als VMs.
 
Ich habe das auch.

PBS als .deb Paket direkt mit auf dem PVE Host installiert. Dieser hat dadurch direkten Zugriff auf eine dedizierte SSD.
Also dein Ablauf wäre dann so?

PVE Installation
PBS VM aus Backup wiederherstellen
Kopieren des Keys aus PBS
Einrichten des PBS Backups in PVE inkl. der Keys
Backup in PVE einspielen

Liegen deine Backups (PVE-Datacenter inkl. VMs) von PBS dann auch auf der dedizierten SSD oder ist darauf nur der PBS und die Backups sind auf einem NAS das per SMB, NFS, etc. an PBS angebunden ist?
 
Also dein Ablauf wäre dann so?

PVE Installation
PBS VM aus Backup wiederherstellen
Glaube, Du bringst da was durcheinander.

Der PBS macht kein Backup vom PVE selbst, nur von den Gästen. Wer sich also den PBS auf den PVE-Host knallt, macht damit trotzdem nur Backups von den Gästen. Und der PBS ist dabei auch keine VM, sondern läuft einfach nebenher mit auf dem Host.
Natürlich könnte man den PBS auch als VM oder Container aufsetzen, gewinnen würde man damit aber nichts.
Eine integrierte Backup-Lösung für den Host selbst gibt es bei Proxmox nicht.
 
Der PBS ist einfachste und schnellste Möglichkeit Backups zu machen. ICH setze den PBS immer als VM auf, und reiche einen internen Speicher als raw-disk an die VM durch. Dort mache ich die Sicherungen, und habe einen externen Server der dann einfach den PBS Sync fährt.

Alternativ kann man Backups auch mit Veeam machen, die supporten Proxmox seit ein paar Monaten auch. Die Community Version kann nur kein Host Backup, sondern nur Gäste.
 
Der PBS macht kein Backup vom PVE selbst, nur von den Gästen. Wer sich also den PBS auf den PVE-Host knallt, macht damit trotzdem nur Backups von den Gästen.
Achso, danke für die Info.

Ich dachte man kann mit dem PBS und der Auwahl "All" beim Backup den ganzen Host sichern. :(
Wie kann man dann überhaupt ein Backup vom Host selbst machen und nicht nur den Gästen?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh