NFS mount füllt nach update von Debian 12 auf 13 das root Verzeichnis

Twitch5788

Hallo zusammen,

ich habe zwei VPS Server mit Debian 12 am laufen. Beide greifen über ein NFS Share auf einen Storagespace zu.

Eingebunden wurde das ganze über /etc/fstab

Code

AAA.ZZZ.YYY.XXX:/volnaabbccdd /mnt/storagespace nfs nolock,nfsvers=3,_netdev,x-systemd.automount,x-systemd.mount-timeout=30,defaults 0 0

Seit ich die Server auf Debian 13 aktualisiert habe, startet sich beim Boot ein copy Befehl der wie folgt ausschaut:

Code

cp -r /mnt /root

Dadurch laufen dann nach ein paar Minuten die internen Festplatten der VPS Server voll. Ich habe im Internet bereits geschaut, es sieht so aus, dass er den Mount einhängen will wenn das Netzwerk noch nicht da ist. Dadurch erstellt er dann lokal den Share. Sobald das Netzwerk dann da ist, kopiert er den Inhalt des NFS Shares auf das lokale Verzeichnis.

Ich habe bereits folgende Parameter hinzugefügt, haben aber nichts gebracht:

Code

_netdev,x-systemd.automount,x-systemd.mount-timeout=30

Hat jemand das gleiche Problem und kann mir sagen wie ich das lösen kann.

Bin für jede Hilfe dankbar.

Gruß
Daniel

webdesignheld

und das ist nicht eine cron oder systemd service Leiche?

Code

grep -R "cp -r /mnt" /etc/systemd /etc/init.d /usr/local /root /home -n

Twitch5788

Mir ist kein job bekannt der so was machen würde:

Code

:~#grep -R "cp -r /mnt" /etc/systemd /etc/init.d /usr/local /root /home -n
grep: /etc/systemd/system/multi-user.target.wants/systemd-resolved.service: No such file or directory
grep: /etc/systemd/system/multi-user.target.wants/nullmailer.service: No such file or directory
grep: /etc/systemd/system/multi-user.target.wants/snapd.aa-prompt-listener.service: No such file or directory
grep: /etc/systemd/system/cloud-init.target.wants/cloud-init.service: No such file or directory
grep: /etc/systemd/system/dbus-org.freedesktop.resolve1.service: No such file or directory

-Manu-

Ich habe hier einen RS2000 G12 mit Debian 13 aus dem netinstall.iso.

Die Netzkonfiguration ist in meinem Fall statisch.

Hierbei nutze ich den Storage-Space als Backup-Ziel per NFS.

meine /etc/fstab sieht so aus

11.22.333.444:/volx777777b2 /wichtiger-ordner nfs defaults 0 0

Auf dem System läuft derzeit nichts außer Docker mit 6 Containern.

Wenn es tatsächlich an der Netzwerkkonfiguration liegt, ist die bei dir statisch oder beziehst du per DHCP?

Twitch5788

Die Netzwerkkonfiguration ist auch statisch. Liegt unter

Code

/etc/network/interfaces.d/50-cloud-init.cfg

So sah mein Eintrag unter Debian 12 auch aus in der /etc/fstab

Dann hab eich mich auf die Suche gemacht und im Wiki Ergänzungen gefunden: https://helpcenter.netcup.com/de/wiki/server/storagespace

Hab ich dann auf das hier abgeändert:

Code

IP:/STORAGEPFAD /mnt/storagespace nfs nolock,nfsvers=3,defaults 0 0

Hat aber an meinem Problem nichts geändert. Komisch ist auch, dass es bei meinen beiden Servern auftritt.

Die Server laufen schon über 3 Jahre so. Sie wurden initial mit Debian Bullseye installiert dann auf Bookworm aktualisiert, und es gab nie Probleme.

Jetzt beim Update auf Trixie treten die Probleme das erste mal auf.

-Manu-

~~Wenn nach deiner Recherche die Ursache darin besteht, dass das Netzwerk noch nicht verfügbar ist, könntest du den Parameter " _netdev" testen.~~

~~Der sorgt dafür, dass der Mount erst dann durchgeführt wird, wenn das Netzwerk vollständig verfügbar ist.~~

~~Also Bspw.:~~

~~IP:/STORAGEPFAD /mnt/storagespace nfs _netdev,nolock,nfsvers=3,defaults 0 0~~

EDIT: Sorry, hattest du ja im Eingangspost bereits aufgeführt, dass du das verwendest.

webdesignheld

Zitat von Twitch5788

Mir ist kein job bekannt der so was machen würde:

doch ich hab sowas schon mal gesehen.

Zitat von Twitch5788

startet sich beim Boot ein copy Befehl der wie folgt ausschaut:
Code cp -r /mnt /root

irgendwo kommt der job ja her

gh7531

Hallo zusammen,

ich habe das selbe Problem wie OP. Nach einem reboot wird der Inhalt von `/mnt` nach `/mnt/root` kopiert. Da ich unter `/mnt/sb-01` meine StorageBox mounte wird mir dadurch die Platte voll geschrieben. Ich hab ebenfalls mein Debian von bullseye über bookworm auf trixie geupdated.

Ich habe dann gesucht ob ich in den logs irgendwas finde und habe das hier gefunden.

Code

root@xxxx:~# journalctl -b | grep "/root/mnt"
Feb 22 15:22:32 xxxx cloud-init[1132]: bash: /root/mnt/boot.sh: No such file or directory

Daraufhin hab ich in den cloud-init files gesucht und habe dort dann einiges gefunden

Code

root@xxxx:~# grep -r "/root/mnt" /etc/cloud/cloud.cfg* /var/lib/cloud/instance/
/var/lib/cloud/instance/cloud-config.txt:- bash /root/mnt/boot.sh
/var/lib/cloud/instance/cloud-config.txt:- bash /root/mnt/start.sh &
/var/lib/cloud/instance/scripts/runcmd:bash /root/mnt/start.sh &
/var/lib/cloud/instance/user-data.txt.i:  - bash /root/mnt/boot.sh
/var/lib/cloud/instance/user-data.txt.i:  - bash /root/mnt/start.sh & 
grep: /var/lib/cloud/instance/obj.pkl: binary file matches
/var/lib/cloud/instance/user-data.txt:  - bash /root/mnt/boot.sh
/var/lib/cloud/instance/user-data.txt:  - bash /root/mnt/start.sh &

Code

root@xxxx:/var/lib/cloud/instance# cat /var/lib/cloud/instance/cloud-config.txt 
#cloud-config

# from 1 files
# part-001

---
apt:
    preserve_sources_list: true
bootcmd:
- mount -t iso9660 /dev/sr0 /mnt || mount -t cd9660 /dev/cd0 /mnt
- cp -r /mnt /root
- umount /dev/cdrom || umount -f /mnt
- bash /root/mnt/boot.sh
disable_root: false
growpart:
    mode: auto
locale: en_US.UTF-8
package_update: true
package_upgrade: true
runcmd:
- bash /root/mnt/start.sh &
ssh_deletekeys: true
timezone: Europe/Berlin
users: []
...
root@xxxx:/var/lib/cloud/instance# cat /var/lib/cloud/instance/user-data.txt
#cloud-config
bootcmd: 
  - mount -t iso9660 /dev/sr0 /mnt || mount -t cd9660 /dev/cd0 /mnt 
  - cp -r /mnt /root 
  - umount /dev/cdrom || umount -f /mnt 
  - bash /root/mnt/boot.sh
ssh_deletekeys: true
disable_root: false
package_update: true
package_upgrade: true
apt:
  preserve_sources_list: true
growpart:
  mode: auto
runcmd:
  - bash /root/mnt/start.sh & 
locale: en_US.UTF-8
timezone: Europe/Berlin
users: []
root@xxxx:/var/lib/cloud/instance# cat /var/lib/cloud/instance/user-data.txt.i 
Content-Type: multipart/mixed; boundary="===============6268134565720684235=="
MIME-Version: 1.0
Number-Attachments: 1

--===============6268134565720684235==
MIME-Version: 1.0
Content-Type: text/cloud-config
Content-Disposition: attachment; filename="part-001"

#cloud-config
bootcmd: 
  - mount -t iso9660 /dev/sr0 /mnt || mount -t cd9660 /dev/cd0 /mnt 
  - cp -r /mnt /root 
  - umount /dev/cdrom || umount -f /mnt 
  - bash /root/mnt/boot.sh
ssh_deletekeys: true
disable_root: false
package_update: true
package_upgrade: true
apt:
  preserve_sources_list: true
growpart:
  mode: auto
runcmd:
  - bash /root/mnt/start.sh & 
locale: en_US.UTF-8
timezone: Europe/Berlin
users: []

--===============6268134565720684235==--
root@xxxx:/var/lib/cloud/instance# cat /var/lib/cloud/instance/scripts/runcmd 
#!/bin/sh
bash /root/mnt/start.sh &

Alles anzeigen

Was es damit auf sich hat weis ich leider nicht, aber ich vermute das hier irgendwo das Problem ist.

Hat diesbezüglich jemand mit mehr Ahnung als ich eine Idee?