Aktualisiert am 31.10.2025 um 08:10:34 Uhr | muellda
19. Oktober 2024durch
Christian Lisec
Um die Meldung „Du hast kein gültiges Abonnement für diesen Server“ beim Einloggen zu entfernen, führe den folgenden Befehl aus. Verbinde dich per SSH mit deinem Proxmox-Server oder einfach die Node-Konsole über die Proxmox-Weboberfläche ausführen.
Falls du Probleme hast und die Änderungen rückgängig machen möchtest, findest du die Anweisungen am Ende dieser Seite. Wenn du deinen Proxmox-Server aktualisierst und das Update das proxmox-widget-toolkit-Paket enthält, musst du diese Änderung erneut durchführen.
Führe den folgenden Befehl aus und leere dann den Cache deines Browsers. Je nach Browser musst du möglicherweise einen neuen Tab öffnen oder den Browser neu starten:
NEUER BEFEHL SEIT 04.08.2025: sed -Ezi.bak "s/(checked_command: function \(orig_cmd\) \{)/\1\n\torig_cmd();\n\treturn;/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.service
VERALTET: sed -Ezi.bak "s/(function\(orig_cmd\) \{)/\1\n\torig_cmd\(\);\n\treturn;/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.service
Warnmeldung permanent deaktivieren
Um Deinen Befehl nach jedem Proxmox-Update automatisch auszuführen, kannst Du ein eigenes Skript erstellen und einen Hook dafür einrichten:
Eigenes Skript erstellen
Erstelle ein Shell-Skript.
nano /usr/local/bin/post-proxmox-update.sh
Das Skript soll folgenden Inhalt haben:
#!/bin/bash
# File to be modified FILE="/usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js"
# Check if the unique comment already exists if grep -q "$UNIQUE_COMMENT" "$FILE"; then echo "The modification has already been applied. No changes made." else # Apply the modification by adding the comment, orig_cmd call, and return statement sed -i.bak "/checked_command: function (orig_cmd) {/a \\ $UNIQUE_COMMENT\\ \torig_cmd();\\ \treturn;" "$FILE"
# Restarting the pveproxy service systemctl restart pveproxy.service
echo "Modification applied and pveproxy service restarted." fi
Füge die Berechtigung hinzu, sodass das Skript ausführbar ist:
chmod +x /usr/local/bin/post-proxmox-update.sh
Einen Hook für installierte APT-Updates erstellen
Um sicherzustellen, dass dein Skript nach jeder Paketinstallation oder jedem Upgrade-Vorgang ausgeführt wird, welches Proxmox-Pakete betrifft, erstellst du eine neue Datei im Verzeichnis /etc/apt/apt.conf.d/.
When you first install Proxmox, it will set whatever initial IP you give it to be that IP forever (wow is that annoying). If you SSH into the Proxmox box and have a look at /etc/network/interfaces it probably looks something like this:
auto lo
iface lo inet loopback
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet static
address 10.0.20.210/24
gateway 10.0.20.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
iface wlp0s20f3 inet manual
source /etc/network/interfaces.d/*
What you’ll want to do is set the iface vmbr0 inet static to be iface vmbr0 net dhcp and then comment out a few lines (see below) that give the box the static IP:
auto lo
iface lo inet loopback
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet dhcp
# address 10.0.20.207/24
# gateway 10.0.20.1
bridge-ports eno1
# bridge-stp off
# bridge-fd 0
iface wlp0s20f3 inet manual
Then reboot and DHCP should get picked up this time!
I just learned that the new version of Proxmox (9.0 and greater) seems to have „broken“ the ability to set DHCP the way I describe above. I became aware of this when I ran ifreload -a I got this error:
error: vmbr0; cmd '/sbin/dhclient -pf /run/dhclient.vmbr0.pid -lf /var/lib/dhcp/dhclient.vmbr0.leases vmbr0' failed ([Error 2] no such file or directory: '/sbin/dhclient')
After trying a lot of things that didn’t work, I was able to resolve this by installing dhclient:
and install D:\guest-agent\qemu-ga-x86_64.msiShutdown the system.On the Proxmox system, head to Options > QEMU Guest Agent > Use QEMU Guest Agent (tick the box)Power up the VMOpen devmgmt.msc – look for PCI Simple Communications Controller and right-click it, then click Update DriverSelect Browse my computer for drivers and feed it the path of D:\vioserial\YOUR-WINDOWS-VERSION\amd64\Per Proxmox docs
, check if the service is running in PowerShell:
Get-Service QEMU-GA
Additionally, from Proxmox command line you can run qm agent xxx ping to make sure an empty prompt is returned back (if you get QEMU guest agent is not running start at step 1 and double check everything).
#Network connectivity issues for Linux VMs tagged with VLANs
I had a super frustrating problem where after moving Linux VMs from one host to another, they weren’t pulling DHCP or not able to route traffic or both. This post
and ChatGPT nudged me towards making a /etc/netplan/01-netcfg.yaml file that looks something like this:
Once the resizing is done, you can do the extending portion from the Linux command line. Using the latest Ubuntu OS as an example, here’s what I did. First find the partion that needs growing:
sudo fdisk -l
Then grow it (in this example the target is dev/vda1:
# Check how much memory is free
free -h
# Stop the VM that needs a RAM facelift
qm stop (VMID)
# Set to 8 gigs
qm set (VMID) -memory 8192
# Set to 16 gigs
qm set (VMID) -memory 16384
I have now run into several instances where my pentest boxes suddenly appear to go offline – both VMs show down at the exact same date/timestamp. My assumption was that there was potentially a hardware issue that was creeping up. But on a recent pentest I remoted back into the Windows VM after the suspected crash, and found that event viewer showed the VM humming away but throwing many errors about DNS lookup and connectivity failures.
Fast-forward through a lot of Proxmox forum searching and ChatGPT chatting and I found out that my NUC and hardware and driver version seem to have a common issue where the card seizes up and basically the whole NUC needs a reboot to get back online.
This is how I figured out there was a problem:
# journalctl logs around the time in question
journalctl --since "2025-09-23 17:15:00" --until "2025-09-23 17:30:00" -p 3..6
Below are a temporary and permanent fix that might help:
At the time of this writing I have not tried this yet, but ChatGPT thinks if the temporary fix does it for you, you can edit your /etc/network/interfaces to include the tso command fix. For example:
auto lo
iface lo inet loopback
iface eno1 inet manual
post-up /sbin/ethtool -K $IFACE tso off gso off gro off
post-down /sbin/ethtool -K $IFACE tso on gso on gro on
auto vmbr0
iface vmbr0 inet dhcp
bridge-ports eno1
bridge-stp off
bridge-fd 0
iface wlp0s20f3 inet manual
source /etc/network/interfaces.d/*
Access this page by simply typing in „cs proxmox“ in your browser address bar if you have bunnylol configured.
Commands
VM Management
Basics
# list VMs
qm list
# Create or restore a virtual machine.
qm create <vmid>
# Create or restore a virtual machine with core, memory, disks specified.
qm create <vmid> --name <vm-name> --cores <number-of-cores> --memory <memory-size-in-bytes> --scsi0 file=<vg-name>:<size-in-gb> --cdrom local:<iso-name> --net0 virtio,bridge=<bridge-name>
# start a VM
qm start <vmid>
# Suspend virtual machine.
qm suspend <vmid>
# shutdown a VM
qm shutdown <vmid>
# reboot a VM
qm reboot <vmid>
# reset a VM
qm reset <vmid>
# stop a VM
qm stop <vmid>
# Destroy the VM and all used/owned volumes.
# Removes any VM specific permissions and firewall rules
qm destroy <vmid>
# Enter Qemu Monitor interface.
qm monitor <vmid>
# Get the virtual machine configuration with both current and pending values.
qm pending <vmid>
# Send key event to virtual machine.
qm sendkey <vmid> <key> [OPTIONS]
# Show command line which is used to start the VM (debug info).
qm showcmd <vmid> [OPTIONS]
# Unlock the VM.
qm unlock <vmid>
# Clone a VM
qm clone <vmid> <newid>
# Clone a VM in full clone mode and also set the name.
qm clone <vmid> <newid> --full --name <name>
# Migrate a VM
qm migrate <vmid> <target-node>
# Show VM status
qm status <vmid>
# Clean up resources for a VM
qm cleanup <vmid> <clean-shutdown> <guest-requested>
# Create a Template.
qm template <vmid> [OPTIONS]
# Set virtual machine options (synchrounous API)
qm set <vmid> [OPTIONS]
Cloudinit
# Get automatically generated cloudinit config.
qm cloudinit dump <vmid> <type>
# Get the cloudinit configuration with both current and pending values.
qm cloudinit pending <vmid>
# Regenerate and change cloudinit config drive.
qm cloudinit update <vmid>
Disk
# Import an external disk image as an unused disk in a VM.
# The image format has to be supported by qemu-img(1).
qm disk import <vmid> <source> <storage>
# Move volume to different storage or to a different VM.
qm disk move <vmid> <disk> [<storage>] [OPTIONS]
# Rescan all storages and update disk sizes and unused disk images.
qm disk rescan [OPTIONS]
# Extend volume size.
qm disk resize <vmid> <disk> <size> [OPTIONS]
# Unlink/delete disk images.
qm disk unlink <vmid> --idlist <string> [OPTIONS]
# rescan volumes
qm rescan
Snapshot
# List all snapshots.
qm listsnapshot <vmid>
# Snapshot a VM
qm snapshot <vmid> <snapname>
# Delete a snapshot.
qm delsnapshot <vmid> <snapname>
# Rollback a snapshot
qm rollback <vmid> <snapname>
# Open a terminal using a serial device
# (The VM need to have a serial device configured, for example serial0: socket)
qm terminal <vmid> [OPTIONS]
# Proxy VM VNC traffic to stdin/stdout
qm vncproxy <vmid>
Others
# Execute Qemu Guest Agent commands.
qm guest cmd <vmid> <command>
# Executes the given command via the guest agent
qm guest exec <vmid> [<extra-args>] [OPTIONS]
# Gets the status of the given pid started by the guest-agent
qm guest exec-status <vmid> <pid>
# Sets the password for the given user to the given password
qm guest passwd <vmid> <username> [OPTIONS]
PV, VG & LV Management
# Create a PV
pvcreate <disk-device-name>
# Remove a PV
pvremove <disk-device-name>
# List all PVs
pvs
# Create a VG
vgcreate <vg-name> <disk-device-name>
# Remove a VG
vgremove <vg-name>
# List all VGs
vgs
# Create a LV
lvcreate -L <lv-size> -n <lv-name> <vg-name>
# Remove a LV
lvremove <vg-name>/<lv-name>
# List all LVs
lvs
Storage Management
# Create a new storage.
pvesm add <type> <storage> [OPTIONS]
# Allocate disk images.
pvesm alloc <storage> <vmid> <filename> <size> [OPTIONS]
# Delete volume
pvesm free <volume> [OPTIONS]
# Delete storage configuration.
pvesm remove <storage>
# List storage content.
pvesm list <storage> [OPTIONS]
# An alias for pvesm scan lvm.
pvesm lvmscan
# An alias for pvesm scan lvmthin.
pvesm lvmthinscan
# List local LVM volume groups.
pvesm scan lvm
# List local LVM Thin Pools.
pvesm scan lvmthin <vg>
# Get status for all datastores.
pvesm status [OPTIONS]
Template Management
# list all templates
pveam available
# list all templates
pveam list <storage>
# Download appliance templates
pveam download <storage> <template>
# Remove a template.
pveam remove <template-path>
# Update Container Template Database.
pveam update
Container Management
Basics
# List containers
pct list
# Create or restore a container.
pct create <vmid> <ostemplate> [OPTIONS]
# Start the container.
pct start <vmid> [OPTIONS]
# Create a container clone/copy
pct clone <vmid> <newid> [OPTIONS]
# Suspend the container. This is experimental.
pct suspend <vmid>
# Resume the container.
pct resume <vmid>
# Stop the container.
# This will abruptly stop all processes running in the container.
pct stop <vmid> [OPTIONS]
# Shutdown the container.
# This will trigger a clean shutdown of the container, see lxc-stop(1) for details.
pct shutdown <vmid> [OPTIONS]
# Destroy the container (also delete all uses files).
pct destroy <vmid> [OPTIONS]
# Show CT status.
pct status <vmid> [OPTIONS]
# Migrate the container to another node. Creates a new migration task.
pct migrate <vmid> <target> [OPTIONS]
# Get container configuration.
pct config <vmid> [OPTIONS]
# Print the list of assigned CPU sets.
pct cpusets
# Get container configuration, including pending changes.
pct pending <vmid>
# Reboot the container by shutting it down, and starting it again. Applies pending changes.
pct reboot <vmid> [OPTIONS]
# Create or restore a container.
pct restore <vmid> <ostemplate> [OPTIONS]
# Set container options.
pct set <vmid> [OPTIONS]
# Create a Template.
pct template <vmid>
# Unlock the VM.
pct unlock <vmid>
Disk
# Get the container’s current disk usage.
pct df <vmid>
# Run a filesystem check (fsck) on a container volume.
pct fsck <vmid> [OPTIONS]
# Run fstrim on a chosen CT and its mountpoints.
pct fstrim <vmid> [OPTIONS]
# Mount the container’s filesystem on the host.
# This will hold a lock on the container and is meant for emergency maintenance only
# as it will prevent further operations on the container other than start and stop.
pct mount <vmid>
# Move a rootfs-/mp-volume to a different storage or to a different container.
pct move-volume <vmid> <volume> [<storage>] [<target-vmid>] [<target-volume>] [OPTIONS]
# Unmount the container’s filesystem.
pct unmount <vmid>
# Resize a container mount point.
pct resize <vmid> <disk> <size> [OPTIONS]
# Rescan all storages and update disk sizes and unused disk images.
pct rescan [OPTIONS]
# Launch a console for the specified container.
pct console <vmid> [OPTIONS]
# Launch a shell for the specified container.
pct enter <vmid>
# Launch a command inside the specified container.
pct exec <vmid> [<extra-args>]
# Copy a file from the container to the local system.
pct pull <vmid> <path> <destination> [OPTIONS]
# Copy a local file to the container.
pct push <vmid> <file> <destination> [OPTIONS]
Snapshot
# Snapshot a container.
pct snapshot <vmid> <snapname> [OPTIONS]
# List all snapshots.
pct listsnapshot <vmid>
# Rollback LXC state to specified snapshot.
pct rollback <vmid> <snapname> [OPTIONS]
# Delete a LXC snapshot.
pct delsnapshot <vmid> <snapname> [OPTIONS]
Web GUI
# Restart web GUI
service pveproxy restart
Important File/Dir Path
PVE
/etc/pve/authkey.pub
Public key used by the ticket system
/etc/pve/ceph.conf
Ceph configuration file (note: /etc/ceph/ceph.conf is a symbolic link to this)
/etc/pve/corosync.conf
Corosync cluster configuration file (prior to Proxmox VE 4.x, this file was called cluster.conf)
/etc/pve/datacenter.cfg
Proxmox VE data center-wide configuration (keyboard layout, proxy, …)
/etc/pve/domains.cfg
Proxmox VE authentication domains
/etc/pve/firewall/cluster.fw
Firewall configuration applied to all nodes
/etc/pve/firewall/<NAME>.fw
Firewall configuration for individual nodes
/etc/pve/firewall/<VMID>.fw
Firewall configuration for VMs and containers
/etc/pve/ha/crm_commands
Displays HA operations that are currently being carried out by the CRM
/etc/pve/ha/manager_status
JSON-formatted information regarding HA services on the cluster
/etc/pve/ha/resources.cfg
Resources managed by high availability, and their current state
/etc/pve/nodes/<NAME>/config
Node-specific configuration
/etc/pve/nodes/<NAME>/lxc/<VMID>.conf
VM configuration data for LXC containers
/etc/pve/nodes/<NAME>/openvz/
Prior to PVE 4.0, used for container configuration data (deprecated, removed soon)
/etc/pve/nodes/<NAME>/pve-ssl.key
Private SSL key for pve-ssl.pem
/etc/pve/nodes/<NAME>/pve-ssl.pem
Public SSL certificate for web server (signed by cluster CA)
/etc/pve/nodes/<NAME>/pveproxy-ssl.key
Private SSL key for pveproxy-ssl.pem (optional)
/etc/pve/nodes/<NAME>/pveproxy-ssl.pem
Public SSL certificate (chain) for web server (optional override for pve-ssl.pem)
/etc/pve/nodes/<NAME>/qemu-server/<VMID>.conf
VM configuration data for KVM VMs
/etc/pve/priv/authkey.key
Private key used by ticket system
/etc/pve/priv/authorized_keys
SSH keys of cluster members for authentication
/etc/pve/priv/ceph*
Ceph authentication keys and associated capabilities
/etc/pve/priv/known_hosts
SSH keys of the cluster members for verification
/etc/pve/priv/lock/*
Lock files used by various services to ensure safe cluster-wide operations
Aktualisiert am 12.10.2025 um 07:49:42 Uhr | muellda
Hier sind die Schritte:
1. System-Paketlisten aktualisieren
Aktualisieren Sie zuerst die lokalen Paketlisten, um sicherzustellen, dass Sie die aktuellsten Informationen zu den verfügbaren Softwareversionen erhalten:
Bash
sudo apt update
2. Git installieren
Installieren Sie Git, indem Sie den folgenden Befehl ausführen:
Bash
sudo apt install git
Geben Sie J (Ja) ein und drücken Sie die Eingabetaste, wenn Sie zur Bestätigung aufgefordert werden.
3. Installation überprüfen
Überprüfen Sie nach Abschluss der Installation, ob Git erfolgreich installiert wurde und welche Version läuft:
Bash
git --version
Dies sollte die installierte Git-Version anzeigen. ✅
4. Git konfigurieren (optional, aber empfohlen)
Um Ihre Commits korrekt zuzuordnen, sollten Sie Ihren Namen und Ihre E-Mail-Adresse konfigurieren:
Firstly, enable the plugin at System Settings -> Features and Plugins.
Check the box next to Git repositories , then click the Save button.
If this plugin does not appear, you may need to first install it.
On a Redhat, Fedora or CentOS system, you can install plugin with the following commands, run as root.
On CentOS or RHEL, the install command is :
yum install wbm-virtualmin-gitCopy Code For Debian or Ubuntu, the command is : apt-get install webmin-virtualmin-gitCopy Code If activating the plugin fails due to Git not being installed on your Virtualmin system, you will need to install it first. On Redhat, Fedora or CentOS the commands for this are as follows : rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
yum install git gitweb
sed -e 's/^/#/' -i /etc/httpd/conf.d/git.conf
apachectl gracefulCopy Code While on Debian or Ubuntu, the command is : apt-get install git gitwebCopy Code If neither of those work, you can install the plugin from a Webmin module package as follows : Firstly, go to Webmin -> Webmin Configuration -> Webmin Modules. In the From ftp or http URL field, enter the URL http://download.webmin.com/download/plugins/virtualmin-git.wbm.gz Then, click the Install Module button. Once the plugin is installed, you can enable it in Virtualmin as follows : Go to System Settings -> Features and Plugins. Check the box in the left hand column next to Git repositories Click Save. Enabling Git For A Domain Once the plugin is installed, you can allow a virtual server to create Git repositories as follows : Below are the steps followed by our Support Techs to enable Git for Domain. Firstly, select the domain from the left menu, and click Edit Virtual Server In the Enabled features section check the box next to Allow Git repositories? Then, click Save Virtual Server This will perform the setup needed for repositories to be accessed under the /git URL path on this domain, but will not yet create any Git repositories. Creating A Git Repository Once a domain has Git enabled, you can add a repository to it like so : Firstly, select the domain from the left menu, then open the Services category and click Git Repositories In the Create Git Repository form, enter a name likemyprojectinto the Repository name field. Enter something likeMy cool programinto the Repository description field. Select at least one existing user in the domain to have access to the new repository in the Grant access to users field. Click the Create button. Once this is done your new repository will appear in the list on the Git Repositories page. It can then be accessed using the Git client with a URL like http://yourdomain.com/git/myproject.git . For more information on exactly which commands to use, click the Repository Commands button. Granting Access To A Repository All Git repositories created using Virtualmin allow write access only to authenticated users. Accounts can create in the same way that you would create mailbox or FTP users, and existing users can grant access to Git repositories. When creating or editing a user, the Other user permissions section of the Edit Mailbox page will have a field named Git login enabled?. Just select Yes, and in the Read/write access to repositories field select one or more repos to grant full access to. As soon as the user will save or create his login and password will be able to checkin to and checkout from the selected repositories. When logging in you only need to use the user’s short username, which is the part to the left of the @ in his email address. Managing Repositories Once you create a repository you can manage it using buttons on the Git Repositories page. These are : Delete : Removes the repository, including all files within it and all user permissions. Browse Repository : Allows the contents and checkins to navigate using a browser. This page is password-protected, but you can login using any access that has been granted Git access. Repository Commands : Shows example commands for pulling from and pushing to the repository [Need more help with Virtualmin? We are available 24*7] Conclusion In short, today we saw steps followed by our Support Techs for Enabling Git on Virtualmin.
Aktualisiert am 05.10.2025 um 08:46:53 Uhr | muellda
setup.exe /product server nutzen für ein Upgrade
Eine Variante, wenn man mit einer ISO ein Inplace Upgrade machen möchte, ist über die Eingabeaufforderung. Und so geht es:
Als Hinweis vorab: In der Windows 11 27xxx.xxxx Canary funktioniert dieser Trick nicht mehr.
ISO bereitstellen und in dem Ordner ein Rechtsklick machen „In Terminal öffnen“
Sollte PowerShell starten, dann einfach cmd eingeben und Enter drücken.
Sollte man die Eingabeaufforderung über das Startmenü starten, dann einfach (Beispiel) D: eingeben Enter drücken
Jetzt setup.exe /product server eingeben und Enter drücken.
Das war es auch schon. Nun startet die Setup.exe als Server und umgeht damit die Hardwarevoraussetzungen für Windows 11. Installiert wird aber Windows 11 Home, Pro etc. Nur das Setup wird von der Server genutzt, die keine Hardwarevoraussetzungen prüft.
Dieser Trick wurde von AveYo im Skip_TPM_Check_on_Dynamic_Update Skript genutzt.
Eine weitere Variante ist die setupprep.exe im Ordner sources
Auch hier die ISO bereitstellen
In den Ordner sources wechseln
Rechtsklick öffnen mit Terminal
Falls PowerShell offen ist cmd eingeben und Enter drücken
Den Befehl setupprep /product server eingeben und Enter drücken
Das Upgrade startet als Windows-Server -Setup. Installiert wird aber die Home, Pro etc.
Danke an Harry für den Hinweis.
Rufus oder Ventoy nutzen
Es gibt auch die Möglichkeit eine ISO mit Rufus auf einen Stick schreiben zu lassen. In der Auswahl werden dann alle Varianten angezeigt, um eine Neuinstallation, oder ein Inplace auch auf alter Hardware durchzuführen.
Als Hinweis: Mit Rufus 4.5 und höher kann Windows 11 24H2 neu installiert werden. Für ein Inplace Upgrade ist die Version 4.6 oder höher notwendig.
Die selben Voraussetzungen bietet auch Ventoy. Der Vorteil hier, ist der Stick mit Ventoy vorbereitet, reicht es aus, eine ISO auf den Stick zu kopieren, oder auch wieder zu löschen. Ohne dass der Stick jedesmal neu erstellt werden muss.
Wer ein Upgrade über Windows Update von Windows 10 auf Windows 11 machen möchte, braucht nur einen Registrykey hinzufügen. Danach sollte, auch wenn die Hardwarevoraussetzungen nicht gegeben sind ein Upgrade durchlaufen und installiert werden.
Den Registrykey in eine Textdatei kopieren und als Upgrade.reg abspeichern und dann per Doppelklick ausführen und den Anweisungen folgen. Danach einen Neustart und Windows Update starten, oder mit einer ISO als Inplace Upgrade.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\Setup\MoSetup]
"AllowUpgradesWithUnsupportedTPMOrCPU"=dword:00000001
Danach wird dann zum Beispiel bei einem Inplace Upgrade mit einer ISO dieser Text angezeigt, den man bestätigen muss.
Danke an abbodi für den Tipp Dieser Registryeintrag wurde von Microsoft temporär hinzugefügt, der aber noch nicht entfernt wurde.
Mit einem Registry-Eintrag alle Richtlinien für ein Inplace ausschalten
Eine weitere Variante für ein Inplace Upgrade von Windows 10 auf Windows 11, oder von Windows 11 auf eine höhere Version, ist eine Änderung in der Registry, die sämtliche Vorgaben (TPM, Securebase, Speicherplatz etc.) deaktiviert.
Danach kann man eine ISO bereitstellen und die setup.exe starten. Die Installation wird die Überprüfung überspringen und Windows 11 kann installiert werden.
Aktualisiert am 04.10.2025 um 10:08:04 Uhr | muellda
Es existieren zwei gängige Hauptmethoden, um die TPM-Anforderung zu umgehen:
1. Registrierungs-Hack (Registry-Anpassung) 🛠️
Sie können während des Installationsprozesses von einem bootfähigen USB-Stick die Windows-Registrierung ändern, um die TPM-Prüfung zu deaktivieren.
Starten Sie die Windows 11 Installation von einem bootfähigen Medium.
Wenn die Meldung erscheint, dass der PC die Mindestanforderungen nicht erfüllt, drücken Sie Shift + F10, um die Eingabeaufforderung zu öffnen.
Geben Sie regedit ein und drücken Sie Enter, um den Registrierungs-Editor zu starten.
Navigieren Sie zu folgendem Pfad: HKEY_LOCAL_MACHINE\SYSTEM\Setup
Klicken Sie mit der rechten Maustaste auf den Ordner Setup, wählen Sie Neu → Schlüssel und nennen Sie ihn LabConfig.
Im neu erstellten Schlüssel LabConfig erstellen Sie folgende DWORD-Werte (32-Bit) und setzen den Wert jeweils auf 1:
BypassTPMCheck
BypassSecureBootCheck (optional, um Secure Boot zu umgehen)
BypassRAMCheck (optional, um die RAM-Prüfung zu umgehen)
Schließen Sie den Registrierungs-Editor und die Eingabeaufforderung. Sie können nun die Installation fortsetzen.
2. Nutzung von Tools (z.B. Rufus) 💾
Programme wie Rufus (ab Version 3.19) bieten beim Erstellen des bootfähigen USB-Sticks die Option, die TPM-, Secure Boot- und RAM-Anforderungen direkt in das Installationsmedium zu integrieren und somit zu umgehen.
Wichtige Hinweise
Beachten Sie jedoch folgende Konsequenzen bei einer Installation auf nicht unterstützter Hardware:
Kein offizieller Support: Microsoft gewährt keinen offiziellen Support für inoffiziell installierte Systeme.
Updates: Es besteht das Risiko, dass Microsoft Feature-Updates (neue Windows 11 Versionen) blockiert oder einschränkt. Kumulative Sicherheitsupdates wurden in der Vergangenheit meist weiterhin bereitgestellt.
Sicherheitsfunktionen: Sicherheitsrelevante Funktionen, die auf einem TPM aufbauen (z.B. BitLocker), könnten eingeschränkt sein oder erfordern bei jedem Start manuelle Eingaben.
Aktualisiert am 17.05.2025 um 19:34:10 Uhr | muellda
Ah, du möchtest also Ordner auf deinem Ubuntu Server per NFS freigeben, um von anderen Rechnern im Netzwerk darauf zuzugreifen? Kein Problem, das ist eine gängige und praktische Methode! Hier ist eine Schritt-für-Schritt-Anleitung, wie du das bewerkstelligen kannst:
1. NFS Server installieren:
Falls der NFS-Server noch nicht installiert ist, musst du das zuerst erledigen. Öffne dein Terminal auf dem Ubuntu Server und führe folgende Befehle aus:
Der erste Befehl aktualisiert die Paketlisten, und der zweite installiert den NFS-Kernel-Server.
2. Freizugebende Ordner erstellen (optional):
Wenn du die Ordner, die du freigeben möchtest, noch nicht hast, erstelle sie jetzt. Zum Beispiel, um einen Ordner namens gemeinsam im Home-Verzeichnis des Benutzers zu erstellen:
Bash
mkdir ~/gemeinsam
Du kannst natürlich jeden beliebigen Ordner auf dem System freigeben.
3. Exportdatei konfigurieren (/etc/exports):
Die Datei /etc/exports enthält die Konfiguration der freigegebenen Ordner und die Zugriffsrechte für die Clients. Öffne diese Datei mit einem Texteditor deiner Wahl (z.B. nano):
Bash
sudo nano /etc/exports
In dieser Datei definierst du für jeden freizugebenden Ordner eine Zeile mit folgender Syntax:
<freigegebener_ordner> <client(s)>(<optionen>)
Lass uns das anhand einiger Beispiele verdeutlichen:
Freigabe für einen bestimmten Client (z.B. mit der IP-Adresse 192.168.1.100):/home/deinbenutzer/gemeinsam 192.168.1.100(rw,sync,no_subtree_check)
Freigabe für ein ganzes Subnetz (z.B. 192.168.1.0 bis 192.168.1.255):/home/deinbenutzer/gemeinsam 192.168.1.0/24(rw,sync,no_subtree_check)
Freigabe für alle Clients im Netzwerk (Vorsicht!):/home/deinbenutzer/gemeinsam *(rw,sync,no_subtree_check)
Erläuterung der Optionen:
rw: Erlaubt dem Client Lese- und Schreibzugriff.
ro: Erlaubt dem Client nur Lesezugriff (read-only).
sync: Erzwingt, dass Änderungen auf der Festplatte gespeichert werden, bevor die Anfrage als abgeschlossen gilt. Dies ist sicherer, kann aber die Performance beeinträchtigen.
async: Erlaubt dem Server, Anfragen als abgeschlossen zu melden, bevor die Änderungen auf der Festplatte sind. Das ist schneller, birgt aber bei einem Serverabsturz ein höheres Datenverlustrisiko.
no_subtree_check: Deaktiviert die Subtree-Überprüfung, was in den meisten Fällen die Performance verbessert.
root_squash: Verhindert, dass der root-Benutzer auf dem Client Root-Rechte auf dem freigegebenen Ordner hat. Stattdessen wird er dem anonymen Benutzer auf dem Server zugeordnet (standardmäßig nobody).
no_root_squash: Deaktiviert die root-Unterdrückung. Der root-Benutzer auf dem Client hat volle root-Rechte auf dem freigegebenen Ordner. Sei hier sehr vorsichtig!
all_squash: Ordnet alle Benutzer-IDs und Gruppen-IDs auf dem Client dem anonymen Benutzer und der anonymen Gruppe auf dem Server zu.
anonuid=<uid> und anongid=<gid>: Ermöglichen die explizite Angabe der Benutzer- und Gruppen-ID für anonyme Zugriffe.
Nachdem du die gewünschten Freigaben in der /etc/exports-Datei hinzugefügt hast, speichere die Datei und schließe den Editor.
4. NFS-Server neu starten oder Exportliste aktualisieren:
Damit die Änderungen in der /etc/exports-Datei wirksam werden, musst du den NFS-Server neu starten oder die Exportliste aktualisieren. Führe einen der folgenden Befehle aus:
Bash
sudo systemctl restart nfs-server.service
oder
Bash
sudo exportfs -ra
Der Befehl exportfs -ra aktualisiert die Exporttabelle, ohne den gesamten Server neu zu starten.
5. Firewall konfigurieren:
Wenn deine Ubuntu Server Firewall (UFW) aktiviert ist, musst du den NFS-Port (standardmäßig 2049) und möglicherweise weitere zugehörige Ports öffnen, damit Clients auf die Freigaben zugreifen können. Du kannst die NFS-Regel in UFW aktivieren:
Bash
sudo ufw allow nfs
Alternativ kannst du die spezifischen Ports freigeben:
Bash
sudo ufw allow 111/tcp # Portmapper
sudo ufw allow 111/udp # Portmapper
sudo ufw allow 2049/tcp # NFS
sudo ufw allow 2049/udp # NFS
sudo ufw allow 32768:60000/tcp # Für zusätzliche Mount-Daemons (kann je nach Konfiguration variieren)
sudo ufw allow 32768:60000/udp # Für zusätzliche Mount-Daemons (kann je nach Konfiguration variieren)
Nachdem du die Regeln hinzugefügt hast, aktiviere UFW falls noch nicht geschehen:
Bash
sudo ufw enable
Überprüfe den Status der Firewall mit:
Bash
sudo ufw status
6. Zugriff vom Client testen:
Nun kannst du von einem anderen Rechner in deinem Netzwerk versuchen, auf die freigegebenen Ordner zuzugreifen. Stelle sicher, dass der NFS-Client auf dem anderen Rechner installiert ist (z.B. nfs-common unter Debian/Ubuntu).
Auf dem Client-Rechner kannst du den freigegebenen Ordner mounten. Erstelle zuerst einen Mountpunkt (einen leeren Ordner):
Bash
mkdir /mnt/nfs_share
Ersetze /mnt/nfs_share durch den gewünschten Mountpunkt.
Mount dann den freigegebenen Ordner vom Server (ersetze <IP_des_Servers> durch die tatsächliche IP-Adresse deines Ubuntu Servers und /home/deinbenutzer/gemeinsam durch den freigegebenen Pfad):
Bash
sudo mount -t nfs <IP_des_Servers>:/home/deinbenutzer/gemeinsam /mnt/nfs_share
Wenn alles funktioniert hat, solltest du nun auf die Dateien und Ordner im Mountpunkt /mnt/nfs_share auf deinem Client zugreifen können.
7. Automatisches Mounten beim Systemstart (optional):
Wenn du möchtest, dass der freigegebene Ordner automatisch beim Starten des Client-Rechners gemountet wird, kannst du einen Eintrag in der /etc/fstab-Datei des Clients hinzufügen. Öffne die Datei mit einem Editor:
user: Erlaubt normalen Benutzern das Mounten und Unmounten.
noauto: Verhindert das automatische Mounten beim Systemstart. Du musst es manuell mounten. Wenn du es automatisch mounten möchtest, verwende auto.
_netdev: Stellt sicher, dass das Netzwerk verfügbar ist, bevor versucht wird, das NFS-Share zu mounten. Dies ist wichtig für Netzwerk-Dateisysteme.
Nachdem du die Zeile hinzugefügt hast, speichere die Datei und schließe den Editor. Du kannst den Mountpunkt testen, indem du den Befehl sudo mount -a ausführst.
Das war’s! Du hast erfolgreich Ordner auf deinem Ubuntu Server per NFS freigegeben. Denke daran, die Zugriffsrechte in der /etc/exports-Datei sorgfältig zu konfigurieren, um die Sicherheit deines Servers zu gewährleisten. Viel Erfolg!
Ah, du möchtest also die NFS-Freigabe so einschränken, dass nur Benutzer mit gültigen Benutzerkonten auf deinem Ubuntu Server darauf zugreifen können? Das ist ein wichtiger Sicherheitsaspekt! NFS selbst bietet keine direkte Benutzerauthentifizierung im Sinne von Passwörtern. Es basiert hauptsächlich auf der IP-Adresse des Clients und optionalen UID/GID-Zuordnungen.
Um den Zugriff auf Benutzer zu beschränken, die auch auf deinem System existieren, musst du die Art und Weise, wie NFS Benutzer-IDs (UIDs) und Gruppen-IDs (GIDs) behandelt, konfigurieren. Hier sind die wichtigsten Punkte und Optionen, die du dabei berücksichtigen kannst:
1. Vermeidung von no_root_squash:
Wie bereits erwähnt, erlaubt no_root_squash dem root-Benutzer auf dem Client, als root auf dem Server zu agieren. Das ist ein enormes Sicherheitsrisiko und sollte in den meisten Fällen vermieden werden. Stelle sicher, dass du root_squash (die Standardeinstellung) verwendest oder explizit in deinen Exportoptionen angibst:
Mit root_squash wird der root-Benutzer auf dem Client dem anonymen Benutzer (meist nobody) auf dem Server zugeordnet.
2. Verwendung von konsistenten UIDs und GIDs:
Die effektivste Methode, den Zugriff auf bestimmte Benutzer zu beschränken, besteht darin sicherzustellen, dass die Benutzer auf den Client-Rechnern, die Zugriff benötigen, die gleichen Benutzer-IDs (UIDs) und Gruppen-IDs (GIDs) haben wie die entsprechenden Benutzer auf dem Server.
Herausforderung: Standardmäßig weisen verschiedene Linux-Distributionen und sogar verschiedene Installationen derselben Distribution Benutzern oft unterschiedliche UIDs und GIDs zu.
Lösung: Du musst sicherstellen, dass die relevanten Benutzerkonten auf den Client-Rechnern, die Zugriff benötigen, exakt dieselben numerischen UIDs und GIDs haben wie die Benutzer auf dem Server, denen du Zugriff gewähren möchtest.
Du kannst die UID und GID eines Benutzers auf einem Linux-System mit dem Befehl id <benutzername> herausfinden.
Um die UID und GID eines Benutzers auf einem Client-Rechner zu ändern, kannst du den Befehl usermod -u <neue_uid> <benutzername> und groupmod -g <neue_gid> <gruppenname> verwenden. Sei hier extrem vorsichtig! Das Ändern von UIDs und GIDs kann zu Problemen mit Dateiberechtigungen auf dem Client-System führen. Es ist oft einfacher, neue Benutzer mit spezifischen UIDs/GIDs zu erstellen, wenn das System neu aufgesetzt wird oder wenn du genau weißt, was du tust.
Export-Optionen für UID/GID-Mapping:
all_squash: Wie bereits erwähnt, ordnet diese Option alle Benutzer- und Gruppen-IDs auf dem Client dem anonymen Benutzer/der anonymen Gruppe auf dem Server zu. Das ist nicht das, was du möchtest, da es den Zugriff nicht auf bestimmte Benutzer beschränkt.
anonuid=<uid> und anongid=<gid>: Diese Optionen erlauben dir, die UID und GID festzulegen, denen anonyme Zugriffe (einschließlich des „gesquashten“ root-Benutzers) zugeordnet werden sollen. Das hilft nicht direkt bei der Beschränkung auf bestimmte existierende Serverbenutzer.
3. Zusätzliche Sicherheitsmaßnahmen (nicht direkt NFS-Benutzerbeschränkung):
Obwohl NFS selbst keine Passwort-Authentifizierung bietet, kannst du zusätzliche Sicherheitsmaßnahmen auf Netzwerkebene in Betracht ziehen, um den Zugriff weiter einzuschränken:
Beschränkung auf bestimmte IP-Adressen oder Netzwerke: In deiner /etc/exports-Datei solltest du die Freigaben immer auf die spezifischen IP-Adressen oder Netzwerke beschränken, von denen du Zugriffe erwartest. Vermeide die Verwendung von * für alle Clients, wenn möglich.
Verwendung eines sicheren Netzwerks: Stelle sicher, dass sich deine Server und Clients in einem vertrauenswürdigen und sicheren Netzwerk befinden.
Firewall-Regeln: Konfiguriere deine Firewall (UFW) so, dass nur Verbindungen von den erlaubten IP-Adressen oder Netzwerken zum NFS-Port zugelassen werden.
Zusammenfassend lässt sich sagen:
Die direkteste Methode, den Zugriff auf NFS-Freigaben auf Benutzer zu beschränken, die auch auf deinem System existieren, ist die Sicherstellung konsistenter UIDs und GIDs zwischen Server und Clients. Wenn ein Benutzer auf dem Client dieselbe UID hat wie ein Benutzer auf dem Server, greift er auf die Dateien und Ordner auf dem Server mit den entsprechenden Berechtigungen dieses Benutzers zu (vorausgesetzt, die Exportoptionen erlauben dies).
Es ist wichtig zu verstehen, dass NFS keine Authentifizierung im herkömmlichen Sinne durchführt. Es vertraut darauf, dass der Client die korrekte Benutzer-ID sendet. Daher ist die physische Sicherheit deines Netzwerks und die Kontrolle über die Clients, die auf den NFS-Server zugreifen dürfen (mittels IP-Beschränkungen in /etc/exports und Firewall-Regeln), ebenfalls entscheidend.
Wenn du eine stärkere Benutzerauthentifizierung benötigst, solltest du alternative oder ergänzende Technologien wie Kerberos für NFS in Betracht ziehen. Die Konfiguration von Kerberos ist jedoch deutlich komplexer.
Für die meisten einfachen Anwendungsfälle in einem vertrauenswürdigen lokalen Netzwerk ist die Konfiguration von root_squash und die sorgfältige Verwaltung der UIDs und GIDs der relevanten Benutzer auf den Clients die praktikabelste Methode, um den Zugriff auf Benutzer zu beschränken, die auch auf deinem System existieren.
