Recent content by sive.host

We can also confirm that switchdev is the answer to this. You can also setup a Systemd Service to make sure it works everytime or on reboots. create a new systemd service file: nano /etc/systemd/system/switchdev.service Put in: #############START FILE CONTENTS BELOW################# [Unit]...

Hi, We deal with quite sensitive data, it would take us a long time to comb through it all eliminating any personal data. Could we rather do a screensharing session, where you can have a look together with us, this issue, without sending any data to you? Perhaps you can say do that, let us see...

Unfortunately, further tests in other VMs in other nodes show the leakage is still there.

This issue has gone away. We simply removed firewall from the network Device, then cloned the VM to a new VM, shutdown the old one and started up the clone, and there was no more leak. Not sure what difference that makes in the backend, but should point out that these VMs were restored from...

We have a similar situation, we changed the MAC address to auto so that they VMs and CTs get the 'BC:24:11' MAC address, but for some reason these two specific VMs still leak their connections to all the VMs in the same node as them. Interestingly enough when you migrate them to other nodes...

Try CPU type of `x86-64-v2-AES` on your VM.

Try SSH into the server or proxmox GUI using the IP address on the URL, then go to Shell, and stop firewall: pve-firewall stop Then try ordering the certificate again. Remember to start the firewall again: pve-firewall start Alternatively, add firewall rule to your Data center /and node...

-> apt update -> apt install parted -> fuser -v /mnt/datastore/ClusterDtStoreName -> umount -l /mnt/datastore/ClusterDtStoreName -> umount /mnt/datastore/ClusterDtStoreName -> parted /dev/sdb resizepart 1 100% -> mount /dev/sdb1 /mnt/datastore/ClusterDtStoreName -> xfs_growfs /dev/sdb1 Should...

If you do not want to edit the config file directly you can use: pct move-volume 100 mp0 --target-vmid 200 --target-volume mp1 It just reassigns owner of the volume at mount point mp0 on ct number 100 to mount point 1 on ct number 200.

Check the firewall on the server handing over emails to PMG. See if you can explicitly set port 26 as an allowed port to hand over things to other servers.

Yeah, 8GB RAM at the least usually solves this problem.

@Andrei9385 You have three options: 1. reduce the key size from 2048 to 1024, then you will get a single line for the p value 2. put it in the TXT content as one line with a single space between the 3rd line and 2nd line: "v=DKIM1; h=sha256; k=rsa; " "p=MIIBI...dA1d" ".....wIDAQAB" 3. put it in...

# Setting for the new UTF-8 terminal support in Debian, run the following: export LC_CTYPE=en_US.UTF-8 export LC_ALL=en_US.UTF-8

Setup: Proxmox 7; Disk model: QEMU HARDDISK; Ubuntu 20.04.3 LTS Expand the QEMU HARDDISK file via Proxmox as per Proxmox VM disk resize steps (VM->Hardware->Hard Disk->Disk Action->Resize) and then inside the VM: $ sudo fdisk -l See which partition is the current Ubuntu setup - should...

A similar error usually happens when you already have an external drive mounted onto /mnt folder directly instead of subfolder like /mnt/externaldrivemounted So perhaps check lsblk to see all mount points and umount /dev/sdeX to unmount the external drive mounted perhaps as /dev/sdeX, then try...