Samba-Storage deaktiviert - wird aber nicht unmounted

intecsoft

Member
Mar 9, 2021
25
4
8
33
Hallo zusammen,

wenn ich ich Storage vom Typ Samba anlege - alles funktioniert - erhalte ich folgenden Fehler von systemd-timesyncd,
sobald der Samba-Server aus ist:

Code:
Apr 19 09:15:34 foo systemd[1]: Starting Time & Date Service...
Apr 19 09:15:44 foo systemd[145027]: systemd-timedated.service: Failed to set up mount namespacing: /run/systemd/unit-root/: Host is down
Apr 19 09:15:44 foo systemd[145027]: systemd-timedated.service: Failed at step NAMESPACE spawning /lib/systemd/systemd-timedated: Host is down
Apr 19 09:15:44 foo systemd[1]: systemd-timedated.service: Main process exited, code=exited, status=226/NAMESPACE
Apr 19 09:15:44 foo systemd[1]: systemd-timedated.service: Failed with result 'exit-code'.
Apr 19 09:15:44 foo systemd[1]: Failed to start Time & Date Service.
ja ich weiß, Proxmox nutzt chronyd, wir haben das aber global umgstellt.

Jetzt war der Plan, das Storage einfach zu deaktivieren, wenn der Samba-Server aus ist,
da der Samba-Server für Offline-Backups da ist.
Allerdings wird mit Deaktivieren des Storages der mount nicht entfernt:

Code:
root@foo:~# mount | grep mnt
//bar/mnt on /mnt/pve/Offline-Backup type cifs (rw,relatime,vers=3.1.1,cache=strict,username=root,uid=0,noforceuid,gid=0,noforcegid,addr=172.20.0.133,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1)

Aktuell läuft Proxmox-Enterprise v7.4

Letzteres scheint mir ein Bug in Proxmox zu sein!?
 
Workaround:
Code:
root@foo:~# cat /etc/cron.d/samba_unmount_disabled
MAILTO=""
* * * * * root for CIFS_STORAGE in $(grep -E '^cifs:' /etc/pve/storage.cfg | cut -d ' ' -f 2); do if grep "cifs: ${CIFS_STORAGE}" /etc/pve/storage.cfg -A 1 | tail -n 1 | grep disable -q && mount | grep /mnt/pve/${CIFS_STORAGE} -q; then umount /mnt/pve/${CIFS_STORAGE}; fi; done

Dennoch sollte das mal behoben werden
 
Workaround:
Code:
root@foo:~# cat /etc/cron.d/samba_unmount_disabled
MAILTO=""
* * * * * root for CIFS_STORAGE in $(grep -E '^cifs:' /etc/pve/storage.cfg | cut -d ' ' -f 2); do if grep "cifs: ${CIFS_STORAGE}" /etc/pve/storage.cfg -A 1 | tail -n 1 | grep disable -q && mount | grep /mnt/pve/${CIFS_STORAGE} -q; then umount /mnt/pve/${CIFS_STORAGE}; fi; done

Dennoch sollte das mal behoben werden
Das ist kein Bug sondern jeder Virtualisierungshost verhält sich so. Wenn du einem ESXi sein Storage klaust, friert auch der ein. Deshalb Disable oder Unmount, egal welches OS.
 
Falk ich glaube du hast den Thread nicht ganz verstanden.
Dass man nicht einfach ein Sambaziel ausschalten kann, ist ärgerlich aber wenn ich ein Samba storage deaktiviere, dann sollte es aber auch unmounted werden statt aktiv zu bleiben
 
Also du willst einen autounmount beim deaktivieren?
Die meisten machen sich ein Script auf dem Host was nach dem Backup ein unmount den Remotespeicher runterfährt.
 
Wie willst den Mount automatisieren wenn das Storage beim deaktivieren unmounted ist und nicht mehr auftaucht. Hast du auch darüber nachgedacht?
 
Ich verstehe die Frage nicht Recht um ehrlich zu sein.

Aber wenn ich ein storage in einer GUI deaktiviere, es aber unter der Haube auf Konsolenebene aktiv bleibt, dann liegt hier meiner Meinung nach ein Bug vor.
 
Ich verstehe die Frage nicht Recht um ehrlich zu sein.

Aber wenn ich ein storage in einer GUI deaktiviere, es aber unter der Haube auf Konsolenebene aktiv bleibt, dann liegt hier meiner Meinung nach ein Bug vor.
Du kannst keine VMs drauf starten oder Backups drauf machen. Ist ja erst einmal richtig. Ein SMB oder NFS Mount muss man immer unmounten damit der Host gar keinen Zugriff hat. Wenn man beim deaktivieren gleich unmounten würde, dann kann man sich den Button auch sparen, dafür kann man ja unmounten. Du wünschst dir eine unmount, wo er sich die Mount Information speichert für einen späteren remount.
Dann solltest du einen solchen Featurerequest stellen.
 
Für mich sind das 2 paar Schuhe. Ich kann alles, was die GUI kann und mehr auf der Konsole.
Aber wofür gibt es die Funktion zum Deaktivieren des Storage, wenn das nicht das GUI-Pendant zum Unmounten ist?

Den Featurerequest brauche ich nicht, da das, was du beschreibst, da ist.
Die Informationen zum Storage behält er sich in unter /etc/pve.
 
Für mich sind das 2 paar Schuhe. Ich kann alles, was die GUI kann und mehr auf der Konsole.
Aber wofür gibt es die Funktion zum Deaktivieren des Storage, wenn das nicht das GUI-Pendant zum Unmounten ist?
Weil der Pendat dazu der Remove Button ist, der macht einen unmount.
Den Featurerequest brauche ich nicht, da das, was du beschreibst, da ist.
Die Informationen zum Storage behält er sich in unter /etc/pve.
Ich möchte das gerade nicht testen, aber bist du dir sicher, dass der PVE alle alten mountpoints, welche mal gemountet waren behält?
Meiner Meinung nach, sind die Infos nach einem sauberen unmount weg.
 
Also in meiner storage.cfg stehen nur die aktuellen Speicher, alte SMB und NFS shares, welche ich mal hatte, finde ich nirgendwo wieder.
 
Last edited:
In der /etc/pve/storage.cfg bleibt der Mount gelistet wenn ich Ihn deaktiviere und bekommt die Zeile 'disable' mit dazu:
Code:
cifs: Offline-Backup
        disable
        path /mnt/pve/Offline-Backup
        server foo
        share mnt
        content backup
        prune-backups keep-all=1
        username bar

mehr passiert aber nicht.
Wie gesagt wenn etwas deaktiviert wird, sollte es nicht aktiv bleiben

Danke @Neobin
https://bugzilla.proxmox.com/show_bug.cgi?id=1016 trifft es "leider" genau
 
Bei deaktiviert wird ja auch nur in der GUI ausgeblendet. Dafür ist das gedacht, sonst wäre es ja kein disable sondern unmount.
Eventuell mal einlesen was Mount eines Netzwerkshares bedeutet und dann sollte einem sofort klar werden, das ein disable niemals ein unmout sein kann.

P.S. das sind Funktionen für Enterprise Umgebungen, wo man nicht mal eben einen Netzwerkshare runterfährt.
 
Last edited:
Ich verstehe die Diskussion nicht.
Wir wissen, wie das aktuelle Verhalten ist. Aber es gibt Benutzer, die sich ein anderes Verhalten wünschen bzw. erwarten (würden). Ansonsten gäbe es das genannte Bugzilla-Ticket (als Enhancement-Request) nicht, welches sogar an @Stoiko Ivanov assigned ist...

Dass man bzw. PVE in dem Fall einen gemounteten Storage nicht blind unmounten sollte, ist auch klar. Aber dafür hat @fabian in dem Ticket ja bereits eine Idee zur Prozedur/Logik geschrieben:
https://bugzilla.proxmox.com/show_bug.cgi?id=1016#c9
 
Ich verstehe inzwischen den Gedanken dahinter, weswegen kein unmount erfolgt,
denke aber, dass es weiter zu Verwirrungen kommen wird, solange es Aktivieren/Deaktivieren in der GUI sichtbar ist.

Hat jemand einen Vorschlag, wie man am besten Images von VMs als Backupjob
in ein Storage laufen lassen kann, welches nicht permanent online ist, um ein Offline-Backup zu realisieren?
 
  • Like
Reactions: Falk R.
Ich verstehe inzwischen den Gedanken dahinter, weswegen kein unmount erfolgt,
denke aber, dass es weiter zu Verwirrungen kommen wird, solange es Aktivieren/Deaktivieren in der GUI sichtbar ist.

Hat jemand einen Vorschlag, wie man am besten Images von VMs als Backupjob
in ein Storage laufen lassen kann, welches nicht permanent online ist, um ein Offline-Backup zu realisieren?
hookscript das sowohl disable als auch unmount macht. das problem mit automatischem unmount ist ja hauptsaechlich, das PVE nicht wissen kann ob das "safe" ist. wenn du bzw. dein skript das macht, ist es deine verantwortung alle notwendigen checks zu machen ;)
 
Last edited:
  • Like
Reactions: Falk R.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!