Can I convert unprivileged to privileged container or otherwise allow use of security.* namespace?

[EBCF]

I have set up an unprivileged container and set up an application in it, only to find that application wants to use the security.* namespace which is not available to an unpriv container.

(It's Samba, as discussed in this previous thread: https://forum.proxmox.com/threads/s...setting-acls-with-smbcacls-fails-partly.62380 )

Can I convert the container to privileged, and if so how? I've found lots of information on making a privileged container unprivileged, but nothing about doing it the other way round?

If not, is there another way I can enable Samba in the container to access the namespace it needs? I'd rather not have to remake the container from scratch.

 

[wolfgang]

Hi,

Can I convert the container to privileged, and if so how? I've found lots of information on making a privileged container unprivileged, but nothing about doing it the other way round?

The official Proxmox VE way is backup and restore.

 

[BrandonN]

Hi, if someone need the command
1. Backup your container.
2. Go to container bakcup folder.
3. Excute from proxmox console as root.

pct restore "container_id "backup_file."tar.xx -storage "new_location"

"- storage" just specific the restore location and when you don't specific "- unprivileged" option, the restore result in a container with privileged.

God Blees you!

 

[medicineman25]

Hi,

The official Proxmox VE way is backup and restore.

That's so janky... why is proxmox like this?

There are so many things that can be done one way but not the other. Like disk expansion, but can't shrink. What are the reasons?

 

[fabian]

switching from privileged to unprivileged or vice-versa requires rewriting all the file metadata, so it's not really possible to do that in-place. shrinking a disk is always risky and depends on the filesystem/.., so we can't do that safely from the PVE side..

 

[medicineman25]

That's so janky... why is proxmox like this?

There are so many things that can be done one way but not the other. Like disk expansion, but can't shrink. What are the reasons?

I was just doing a small restore over my morning cup of tea and came to this exact conclusion haha... containers are what they are... and sure, it is kinda janky but so is shrinking disk space willy nilly through the GUI!

 

[wavewrangler]

That's so janky... why is proxmox like this?

There are so many things that can be done one way but not the other. Like disk expansion, but can't shrink. What are the reasons?

Because....ohmuh gerddd ZFS?

 

[wavewrangler]

I was just doing a small restore over my morning cup of tea and came to this exact conclusion haha... containers are what they are... and sure, it is kinda janky but so is shrinking disk space willy nilly through the GUI!

It's not willy-nilly though, it's like-for-like to the command line. Without GUIs , none of us would have jobs. Respekk the GUI hehehe

 

[malypetu]

Just as an example, executed from proxmox console as root:

root@pve:~#
root@pve:~# pct restore 301 /var/lib/vz/dump/vzdump-lxc-301-2022_11_22-17_02_20.tar.zst -ignore-unpack-errors 1 -unprivileged

Where:
Backup File-name: vzdump-lxc-301-2022_11_22-17_02_20.tar.zst
Backup Files Location: /var/lib/vz/dump/

You will see your container appear on "pve" with a padlock indicating is being restored.

 

[RolandK]

instead of backup/restore, you can also use a tool like this:

https://tbrink.science/blog/2017/06...ed-lxc-containers-to-unprivileged-containers/

 

[sdettmer]

I tried this on Proxmox 7.4 following this nice thread.

I'd like to update it since it way my first Google Hit in case it could help others.

I had to destroy the container before restoring (pct destory container_id) and most notably to specify -unprivileged false. The man page says this would be the default (actually "0", which in programming usually is false, expect in shell programming), so I think possibly a default changed but documentation is not yet updated.

Here my steps for reference:

root@csdpve:~# pct destroy 102
root@csdpve:~# pct config 102|grep privi
Configuration file 'nodes/csdpve/lxc/102.conf' does not exist

root@csdpve:~# pct restore 102 $TARZST -storage local-zfs
recovering backed-up configuration from '$TARZST'
restoring '$TARZST' now..
extracting archive '$TARZST'
Total bytes read: 984791040 (940MiB, 63MiB/s)
Detected container architecture: amd64
merging backed-up and given configuration..
root@csdpve:~# pct config 102|grep privi
unprivileged: 1

We see "unprivileged: 1".
The Web GUI show the same ("Unpriviledged: Yes").

root@csdpve:~# pct destroy 102
root@csdpve:~# pct restore 102 $TARZST -storage local-zfs -unprivileged false
recovering backed-up configuration from '$TARZST'
restoring '$TARZST' now..
extracting archive '$TARZST'
Total bytes read: 984791040 (940MiB, 60MiB/s)
Detected container architecture: amd64
merging backed-up and given configuration..
root@csdpve:~# pct config 102|grep privi
root@csdpve:~#

We don't see "unprivileged: 1" and thus are privileged.
The Web GUI now show the same ("Unpriviledged: No").

 

[SInisterPisces]

switching from privileged to unprivileged or vice-versa requires rewriting all the file metadata, so it's not really possible to do that in-place. shrinking a disk is always risky and depends on the filesystem/.., so we can't do that safely from the PVE side..

Thank you for the concise explanation of why this is the way it is.

Still, I wish there were another way. Having to backup, destroy, and re-create something like the database server LXC that backs a bunch of other VMs and CTs just to, e.g., enable NFS so I can connect to a remote server and backup my database there, is spectacularly non-trivial.

This is not the first time, as a hobbyist/home/home office user, that I've felt like I'm only able to learn certain things by having to destroy work I've already done and redo it the right way (without any documented warning ahead of time that I was doing it wrong).

In the alternative, it would be great if we could mount "raw storage" over NFS in Proxmox itself (in the Datacenter --> Storage area), pass that through to a CT as a bind mount, and let it go to town. Then we could use unprivileged LXCs and easily mount shares from servers.

EDIT: I just realized my NAS supports iSCSI. If I add an iSCSI storage target to Proxmox, can I pass that into an LXC-based container? That might be a good alternative to destroying and re-creating the whole CT--which is a bit complex for containers where there's more than one underlying backing storage with different block sizes, for example.

 

[alexskysilk]

CTs just to, e.g., enable NFS so I can connect to a remote server and backup my database there, is spectacularly non-trivial.

A vm doesnt need to be privileged to mount nfs. all you need to do is allow it to have access by assigning it the proper apparmor profile. there are literally dozens of threads describing how to do this.

In the alternative, it would be great if we could mount "raw storage" over NFS in Proxmox itself (in the Datacenter --> Storage area), pass that through to a CT as a bind mount,

You can do exactly that.

pct set [ctid] -mp0 /mnt/pve/your_nfs_mount,mp=/path/in/container

 

[alexskysilk]

This is not the first time, as a hobbyist/home/home office user, that I've felt like I'm only able to learn certain things by having to destroy work I've already done and redo it the right way (without any documented warning ahead of time that I was doing it wrong).

The thing about that has more to do with lack of preparation/understanding then anything else. you can always start by searching/asking for what it is you're trying to accomplish before rushing in and get better results.

 

[SInisterPisces]

The thing about that has more to do with lack of preparation/understanding then anything else. you can always start by searching/asking for what it is you're trying to accomplish before rushing in and get better results.

That's true in the abstract, but when starting from zero, it's very difficult to know what questions to ask.

I'm not a professional network admin, so I don't have deep knowledge of NFS/CIFS/etc. except for what I've learned to do specific things with my NAS.

I don't deploy virtualization solutions professionally, so I don't have deep knowledge on the inner workings of QEMU or LXCs beyond what I've learned through research and trial and error to do specific things.

There as nothing in the GUI or the getting started level of tutorials to tip me off about the actual limits of LXCs, or that I couldn't elevate an unprivileged container to a privileged container later (which is, by comparison, something you can do in docker, so subsconsciously I was probably assuming I could do the same with an LXC).

As for doing my research, I'd already gone through a 30 minute tutorial on setting up an NFS share, which I'd never done before, but of course it wasn't in an LXC-based container and didn't warn me about that issue. So I didn't discover the problem until I was halfway through implementing what I learned in the tutorial and had to figure out why I was suddenly getting NFS permission denied errors.

I know your reply was almost certainly meant to be helpful, but really it came off as condescending. I didn't rush in. I'm trying to learn as I go with very limited free time, starting from zero, and replies like this make it no fun to ask for help.

I might submit a bug report on this. The easiest way to make this less of an issue would be to include an extra bit of help text when setting up CTs, at the moment when you have the option to make it privileged. Something along the lines of: "If you want to use any of the following services, select privileged, but be aware of certain security risks," and then expand on that in the docs. If I'd seen something like that, I could have spent 5 minutes reading the docs, clicked a checkbox, and avoided the last two hours of figuring out why I couldn't mount an NFS share to backup my database.

 

[alexskysilk]

I know your reply was almost certainly meant to be helpful,

It was.

but really it came off as condescending.

So what?

didn't rush in. I'm trying to learn as I go with very limited free time, starting from zero,

How is that of any relevance in this conversation/context?

and replies like this make it no fun to ask for help.

If you're asking for help for "fun," I suggest this may not be the hobby for you. Proxmox (and to a lesser extent, virtualization as a whole) is a complex set of tools that are meant to be flexible and powerful. consequently, to get maximal use out them require some understanding and imagination that cannot be handed to you.

Something along the lines of: "If you want to use any of the following services, select privileged, but be aware of certain security risks," and then expand on that in the docs. If I'd seen something like that, I could have spent 5 minutes reading the docs, clicked a checkbox, and avoided the last two hours of figuring out why I couldn't mount an NFS share to backup my database.

There are a TON of resources, on here, on reddit, or youtube that show you step by step how to accomplish things with very fine detail, all you have to do is ask the question and spend time understanding the answers. everything you asked for exists.

 

[onethree7]

Here my steps for reference:

Thanks for this, using these steps i converted some LXC with this from unprivileged to privileged successfully and decided to make a little helper script for it,

you can select menu driven what container to work on, select the backup storage, select the target storage for the new LXC, then perform via snapshot backup, restores to new LXC, allows to shutdown old and power up the new LXC (no ip conflict on webservers etc), and then cleans up the temp files if you wish so.

Works for me to convert privileged to unprivileged as well.
https://github.com/onethree7/proxmox-lxc-privilege-converter

 

[SInisterPisces]

Thanks for this, using these steps i converted some LXC with this from unprivileged to privileged successfully and decided to make a little helper script for it,

you can select menu driven what container to work on, select the backup storage, select the target storage for the new LXC, then perform via snapshot backup, restores to new LXC, allows to shutdown old and power up the new LXC (no ip conflict on webservers etc), and then cleans up the temp files if you wish so.

Works for me to convert privileged to unprivileged as well.
https://github.com/onethree7/proxmox-lxc-privilege-converter

Thank you both for this.

 

[RolandK]

That's true in the abstract, but when starting from zero, it's very difficult to know what questions to ask.

I'm not a professional network admin, so I don't have deep knowledge of NFS/CIFS/etc. except for what I've learned to do specific things with my NAS.

I don't deploy virtualization solutions professionally, so I don't have deep knowledge on the inner workings of QEMU or LXCs beyond what I've learned through research and trial and error to do specific things.

There as nothing in the GUI or the getting started level of tutorials to tip me off about the actual limits of LXCs, or that I couldn't elevate an unprivileged container to a privileged container later (which is, by comparison, something you can do in docker, so subsconsciously I was probably assuming I could do the same with an LXC).

As for doing my research, I'd already gone through a 30 minute tutorial on setting up an NFS share, which I'd never done before, but of course it wasn't in an LXC-based container and didn't warn me about that issue. So I didn't discover the problem until I was halfway through implementing what I learned in the tutorial and had to figure out why I was suddenly getting NFS permission denied errors.

I know your reply was almost certainly meant to be helpful, but really it came off as condescending. I didn't rush in. I'm trying to learn as I go with very limited free time, starting from zero, and replies like this make it no fun to ask for help.

I might submit a bug report on this. The easiest way to make this less of an issue would be to include an extra bit of help text when setting up CTs, at the moment when you have the option to make it privileged. Something along the lines of: "If you want to use any of the following services, select privileged, but be aware of certain security risks," and then expand on that in the docs. If I'd seen something like that, I could have spent 5 minutes reading the docs, clicked a checkbox, and avoided the last two hours of figuring out why I couldn't mount an NFS share to backup my database.

i feel your pain

lxc containers imho is something which is more complicated from a management , feature and issue/caveats standpoint and there is not an easy entry into this.

for example/there is no easy/straightforward and secure way to have kernel based nfs server and the same applies to userspace based nfs (ganesha).

uid/gid handling of filesystem passthrough is complicated, too.

i would not recommend lxc for beginners.

 

[onethree7]

i feel your pain

lxc containers imho is something which is more complicated from a management , feature and issue/caveats standpoint and there is not an easy entry into this.

for example/there is no easy/straightforward and secure way to have kernel based nfs server and the same applies to userspace based nfs (ganesha).

uid/gid handling of filesystem passthrough is complicated, too.

i would not recommend lxc for beginners.

Setting up Hardware Passthrough of iGPU into a VM was hours and hours and hours of fiddling in Bios, guessing settings - reading tutorials and testing out stuff. Then i still would need to get it running inside the VM itself...

Getting it to run properly in LXC was just a few clicks though on 6.2 kernel and PVE 8 for me. However i dont do uid/gid handling and all that. I really guess it depends on what you are trying to do in the end. My workflow lets me completly switch to using containers and since then, life is easy