[SOLVED] can not 'chown' folder or file in unprivileged lxc container proxmox ve 6.2

Nov 10, 2020
5
0
1
61
Hello,
I recently created an lxc container in the proxmox 6.2 gui and installed a freeipa server on it.
I used a centos 7 template for this. The ipa-server runs fine, but I see some unexpected behaviour in the logs and I found that I as root can not change owner or group from any created file or folder in the container. I can create file and folders as root, those are created with uid=0
I also see "ntpd[1018]: adj_systime: Operation not permitted" in the logs. After searching the forum, I think it also has to do with permissions for other than root user.
There is no nfs mount involved and I don't have this problem with other lxc containers on the same host that are "privileged" containers.

I can't put my finger on the origin of these issues.
I would appreciate it if anybody could point me to some documentation that explains this behaviour.
I found the wiki page on unprivileged containers, unfortunately this is a quit compact explanation and I could not link it to 'chown' "invalid argument" error I get

Any help is welcome.

My config.

arch: amd64
cores: 2
hostname: my-ipa.example.com
memory: 2976
nameserver: x.x.x.y
net0: name=eth0,bridge=vmbr2,firewall=1,gw=x.x.x.r,hwaddr=x:x:u:u:j:w,ip=x.x.x.f/24,ip6=auto,type=veth
onboot: 1
ostype: centos
rootfs: local-lvm:vm-num1-disk-0,size=8G
searchdomain: example.com
startup: order=1
swap: 2048
unprivileged: 1
lxc.cap.drop:
lxc.cap.drop: mac_admin mac_override sys_module sys_rawio
 
Hi,
about the ntp error: Normally you don't want a container to change the system clock (especially not unprivileged ones). Please have a look here for an alternative.

About the chown error: Could you post the exact command and error message? Can you at least chown files created as root, i.e. change the owner to some other user and back to root again?
 
Thanks Fabian. Also found http://doc.ntp.org/4.1.0/miscopt.htm explaining options for ntp.conf file.
Will experiment with "disable ntp" , this keeps the daemon running but does not adjust time. Unfortunately, also makes clients not to synchronize with the ntp server anymore.

About the chown error. This is what I get.
Try to change /home/admin with following permissions: drwxrwxrwx 2 root root 4096 Oct 20 15:39 admin

home]# chown -R admin:admins /home/admin
chown: changing ownership of ‘/home/admin’: Invalid argument

The outcome of the chown command is the same on every location I try. so mkdir /tmp/my_dir and chown admin /tmp/my_dir results in same error.

Kind regards,

Rob
 
Did the problem only occur after installing freeipa? It might very well be related to the permission management/LDAP interacting badly with the containers id mapping. Can you run su - admin -c "mkdir /tmp/new_dir"?
 
Acually , don't know. I installed only a few packages after the container was created, did it all as root.
freeipa server-install created the admin user and others. No errors or warnings were flagged during installation of freeipa-server.

Have had freeipa server installed on proxmox VE 4.3, also CentOS 7 and same version freeipa that did not have this issue.

# su - admin -c mkdir /tmp/new_dir
su: cannot set groups: Invalid argument

I get the same error when # su admin
 
What if you create a normal PAM user and try to chown something to that user?
Was the old instance also an unprivileged container? I think back then the default was privileged.
 
Had not thought of that , thanks. Yes that will work. chown with PAM user.
chown with LDAP users generate ": Invalid argument" error. Also chown <LDAP-userID>

The old instance was privileged lxc container.

Do you think there is any chance, that this behaviour is related to the unprivileged container. ?
If so It may resolve the issue to convert this instance to a privileged container.
If I have read correct, a default backup and restore should restore the instance in a privileged container.

Kind regards,

Rob.
 
Yes, I do think that might be the reason. After all unprivileged containers use id maps and that seems to be clashing with the LDAP. Still, what might be worth a try is to map the LDAP users to their real IDs.

I also found another user with similar issues (warning: it's a rather long thread and the solution there was to switch to a full VM instead).
 
I have solved both by converting the Unprivileged lxc container to a Privileged lxc container,
using the pct restore <nieuw_container_id> <my_backup_file> --storage <my_storage>

By running freeipa in a privileged container, I was enable to chown again to ldap-users, and it also solved the ntp errors in the log.
I was also able to use the ntp servers again from the ntp-pool in this container , which resulted in a stratum 4 time synchonization. with the ipa-clients. ( this was stratum 11 when I used 127.127.1.0, which is your local clock, as a clock source )

Thanks for all the help. With the info supplied , I was able to find a solution.

Kind regards,

Rob.
 
Glad to hear that it works now. Could you please mark the thread as [SOLVED]? This helps others with similar problems to find working solutions more easily.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!