Adam Weremczuk's picture

Hi all,

I'm using it with the latest Proxmox/PVE:

pve-kernel-4.15                      5.3-3
pve-manager                          5.3-11


I'm logged in as root@pam.

My error log:

Using default stripesize 64.00 KiB.
Logical volume "vm-100-disk-0" created.
mke2fs 1.43.4 (31-Jan-2017)
Discarding device blocks: 4096/2097152 done
Creating filesystem with 2097152 4k blocks and 524288 inodes
Filesystem UUID: 12268137-c4f9-4936-b17b-08c5142aadc2
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables:  0/64 done
Writing inode tables:  0/64 done
Creating journal (16384 blocks): done
Multiple mount protection is enabled with update interval 5 seconds.
Writing superblocks and filesystem accounting information: 0/64     done

extracting archive '/var/lib/vz/template/cache/debian-9-turnkey-openldap_15.0-1_amd64.tar.gz'
tar: ./var/spool/postfix/dev/urandom: Cannot mknod: Operation not permitted
tar: ./var/spool/postfix/dev/random: Cannot mknod: Operation not permitted
Total bytes read: 817786880 (780MiB, 94MiB/s)
tar: Exiting with failure status due to previous errors
  Logical volume "vm-100-disk-0" successfully removed
TASK ERROR: unable to create CT 100 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar xpf - -z --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' -C /var/lib/lxc/100/rootfs --skip-old-files --anchored --exclude './dev/*'' failed: exit code 2

# ls -al /var/spool/postfix/dev/random
crw-rw-rw- 1 root root 1, 8 Mar 25 15:48 /var/spool/postfix/dev/random

I've tried adding permissions under corresponding zfs pool:
Permissions -> Add -> User Permission -> User: root@pam -> Role: Administrator
but when I click "Add" nothing appears on the list.

Any ideas?


Jeremy Davis's picture

Unfortunately this is a known issue with our current Proxmox (LXC) builds. The quickest (and dirtiest) workaround is to allow the container to be initiated as a "privileged" container.

As noted on our issue tracker if you want to run it as an "unprivileged" container, you'll then need to remove the /var/spool/postfix/dev/random & /var/spool/postfix/dev/urandom files. Then create a Proxmox backup of the container. Then launch a new "unprivileged" instance from the backup.

Postfix should still work ok, although it will no longer support integration with LDAP. If you want/need LDAP integration with Postfix, then please try mount binding from /dev/random to /var/spool/postfix/dev/random and same for urandom. I haven't got around to testing that yet, so I can't confirm it will work, but fingers crossed. Alternatively, continue running it as a "privileged" container.

A bit of a pain I know sorry... We do hope to resolve this in a future release. Although as I say, unless I can get the mount bind working (and implement a service which recreates it at boot time) we may have to choose between supporting LDAP Postfix integration and the possibility of running "unprivileged" (the former is likely my preference).

FWIW, your post prompted me to do a little more research on the cause of the issue and I've posted an update to the issue here. I hope that assists you to understand the underlaying issue. Good luck.

Add new comment