Search results

Hey, I configured a backup job on the Datacenter node, and set "keep-last=1", but it is ignored, backups keep piling up. Each affected node's logs just states 2024-03-18 21:05:07 INFO: prune older backups with retention: keep-last=1 2024-03-18 21:05:07 INFO: pruned 0 backup(s) What could be...

Where do I find this config? The setup is the default, with a single physical eth0. This only seems to affect Debian CT-s, I tried release 11 and 12, I don't have VMs atm. The problem only appears after 14-20h uptime. If I manually run dhclient eth0 the network becomes operational again...

Thanks for the response, but I simply performed a full reinstall since, so I can't research this anymore. I marked the thread as "solved" still, although it would be useful to know how to remedy this kind of situation.

Sure @Moayad, here it is Container is Debian 12 Standard 6.2.16-3-pve #1 SMP PREEMPT_DYNAMIC PVE 6.2.16-3 (2023-06-17T05:58Z) x86_64 Note that seemingly only Debian containers need DHCP ip settings, STATIC doesn't work (unlike Alpine containers) I couldn't see this problem yet with Debian 11...

All of my Debian Standard containers lose internet connection 1-2 times a day. They can ping local ip-s, but not internet ones. Only reboot solves it. Journalctl shows just this: E: Sub-process /lib/systemd/systemd-networkd-wait-online returned an error code (1)...

/etc/pve is empty, probably because the node can't connect (as per forum searches for the same problem). I've posted parts of status pve-cluster above, the full response is pve-cluster.service - The Proxmox VE cluster filesystem Loaded: loaded (/lib/systemd/system/pve-cluster.service...

Yes. The only unique lines in journalctl -b are: localhost pveproxy[1644]: /etc/pve/local/pve-ssl.key: failed to load local private key (key_file or key) at /usr/share/perl5/PVE/APIServer/AnyEvent.pm line 2009. localhost cron[1120]: (*system*vzdump) CAN'T OPEN SYMLINK (/etc/cron.d/vzdump)

Sadly doesn't seems so: ipcc_send_rec[1] failed: Connection refused ipcc_send_rec[2] failed: Connection refused ipcc_send_rec[3] failed: Connection refused Unable to load access control list: Connection refused

Using the latest proxmox, I changed the system time (to earlier) - I assume this is the problem, as this is the only change I did that could result in this - and after a restart PVE-Cluster fails to start. systemd[1]: pve-cluster.service: Scheduled restart job, restart counter is at 5...

Nur eine Nebenbemerkung, ich habe dieses Problem umgangen, ohne UID-mapping. Wie im OP angegeben, wollte ich nur Bind-Mounts zwischen Containern teilen, ohne dass die Möglichkeit besteht, dass Dateien für einige Container nicht verfügbar oder nur lesbar sind. Dazu sind keine bestimmten Benutzer...

Just a sidenote, I circumvented this issue, without UID mapping. As stated in OP, I just wanted to share Bind mounts between containers, without the possibility that files are unavailable or read only to some containers. This doesn't necessitate specific users, just preset rights. So I added...

I didn't had such problems (using the stock heatsink) - I also ran some stress tests back then. A typical personal homelab server is rarely running on extended periods of 100% CPU for this to be a big issue, depends on the use case.

There are downsides of enterprise products - HW might be more exotic, there might be less support (for a private user) if anything goes wrong - at least in terms of googleability. 2 options could be: A J4501-based motherboard + ITX case. It's not the latest, but still powerful enough for most...

I'm trying to do a very typical uid mapping. I have both a Guest and Host user id 5000. Just for reference I'm adding my config, it is valid, because it works. I see Bind mount files on Guest/Host owned by #5000 user as their respective users in Guest/Host. lxc.idmap: u 0 100000 5000 lxc.idmap...

Das ist mein sub{u,g}id config - share ist die Host #5000 user: root:100000:65536 share:165536:65536 root:5000:1 Ich hätte kein großes Problem damit, dies individuell für Containers zu tun - da ich es nur einmal tun müsste - solange es funktioniert... Ja, der schlimmste Fall ist SMB, aber...

Ich wollte gerade diese Gruppenidee schreiben. Problem ist, ich verwende mehrere Services (Syncthing, Nextcloud usw.), die alle verschiedene Benutzer verwenden. Die bessere Idee ist also, dass ich jede solche benutzer (eins pro container) auf uid/gid 5000 ändere. Ich habe diese id-s nun auf...

Aber.... wut... Kann man nicht zb user 999 (Gast) zu user 5000 (Host) mappen? Muss das immer gespiegelt sein? Wie ist das nutzbar wenn ich verschieden Gäste habe mit verschiedene users, die auf selber Mount points zugreifen?

Wie viele andere habe ich einige Bind-Mounts, die ich zwischen mehreren LXC-Containern teilen würde. Wie viele andere auch, bin ich über das Problem der kollidierenden UIDs gestolpert. Ich versuche, ein Mapping einzurichten, aber so viel ich auch lese, ich scheine ein großes Missverständnis zu...

Like so many here, my usecase is to have a number of containers share some common NFS bind mounts. However, when I do this - the container user's folder is suddenly owned by uid 65534. I don't understand why - I though UID maps only have an effect outside the container? (=files in the bind...

I also have this issue (and I saw others here asking similar questions as well). I think this user mapping config is a hard to understand problem of LXC, and sadly Proxmox wiki is not doing too much to uncover the big picture. How I intend to solve this: mount the data directory as a bind mount...