Search results

So, I also upgraded again to corosync3 on my pve5 system ... if it stays stable till sunday I will upgrade the first host to pve6 :-)

Thank you, then I also try them that way ;-)

Now that the problems are basically solved my question is if for a 7 node cluster your changes are still "best practice"?! ;-) My current corosync config for the totem part looks like: totem { cluster_name: apollon-pm config_version: 9 interface { bindnetaddr: 192.168.178.76...

Hm ... I think I will jsut stay with the "container raw images" I have set up now stored on glusterfs ... Only a Redis sentinel setup is running inside them at the moment, so should be acceptable ;-) Thank you!

why not? I have read that performance shpuld be ok in the meantime?

Hm... thank ypu for that answer ... could it be that this is the reason (found while googling): The /etc/fuse.conf in my Proxmox hosts looks like: # /etc/fuse.conf - Configuration file for Filesystem in Userspace (FUSE) # Set the maximum number of FUSE mounts allowed to non-root users. # The...

For me it is directory (and mounted by PVE) and you see the logs and tries from above. The permission error were mostly done as I changed ownership and such from the dirs, but still some were tere ... and in the end it was still not working. So I think there is more strange :-(

I also read about that but then I found that "simply create a Directory Storage on the gluster PVE mountpoint as base diretcory" and basically this works well (or, ok I would not expect that this is part of the problem). I have an NFS share from my NAS (basically for images ad backups) already...

All cases, but minimum rootfs only also ... Done https://bugzilla.proxmox.com/show_bug.cgi?id=2431

The reason for this error is that he wants to return to the "current" path where the command was executed where this unprivileged user has no access too (assumption because it changed as soon as I started the command out of an directory which was owned by the 10000.10000 user

Yes it will create stuff, but then still an error, see https://forum.proxmox.com/threads/setting-up-lxc-container-with-multiple-directory-storages.59323/post-273840

Ok, I removed mp0, now it is: extracting archive '/mnt/pve/apollonnas-nfs/template/cache/ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz' tar: ./var/lib/apt/lists/partial: Cannot change ownership to uid 105, gid 0: Operation not permitted tar: ./var/lib/apt/lists/auxfiles: Cannot change ownership...

Ok, and next try ... I now changed to the 302 directory (that I gave to ownership 100000.100000 before) ... now it brings: extracting archive '/mnt/pve/apollonnas-nfs/template/cache/ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz' tar: ./sbin/pam_extrausers_chkpwd: Cannot change ownership to uid...

But then all files would be "root" ... this will not really work, or? I have used the same container template several times to setup "raw image based" containers and in general this is working, so yes I think it is because the directory is owned by root and "Other users" are not allowed to...

So that would mean that I need to make a "chown" to that unprivileged user (whats his name?) or make a "chmod 777" on this directory? What I need to do?

I tried with root@pm7:~# pct create 302 apollonnas-nfs:vztmpl/ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz --cores 2 --cpuunits 1024 --memory 1024 --swap 512 --hostname redis3 --net0 bridge=vmbr0,name=eth0,ip=dhcp,ip6=dhcp,firewall=1 --rootfs...

Ok, so path to be /mnt/pve/glusterfs-container/my/own/path/structure/ ?!

Nope, Result: unable to create CT 301 - unable to parse volume filename 'rootdir' I also tried the short form with "glusterfs-container:0": extracting archive '/mnt/pve/apollonnas-nfs/template/cache/ubuntu-18.04-standard_18.04.1-1_amd64.tar.gz' tar: failed to return to initial working...

Great to hear then my next upgrade try will come soon ;-))

Thank you. I will try that later. Do you have an idea how to call it to get two separate directories for system and data?