Proxmox: Shrinking disk of an LVM backed container

First, shut down the container and ensure it’s not running.

List out the LVM logical volumes:

  1. lvdisplay | grep "LV Path\|LV Size"

Choose the disk you want to resize – you’ll see they’re named by container ID and disk number. For example, /dev/vg0/vm-205-disk-1.

Check and fix the filesystem, just incase:

  1. e2fsck -fy /dev/vg0/vm-205-disk-1

Resize the file system. It is advisable, at this point, to set this to 1GB smaller than you actually want it (e.g. 7G when you want 8G):

  1. resize2fs /dev/vg0/vm-205-disk-1 7G

Resize the LVM LV to the actual size you want it to be:

  1. lvreduce -L 8G /dev/vg0/vm-205-disk-1

Resize the file system to fill the LVM LV:

  1. resize2fs /dev/vg0/vm-205-disk-1

Finally, edit the configuration for the container such that Proxmox reports the correct size for the disk. You will find this at /etc/pve/lxc/205.conf where 205 is your container ID.

You can now start your container and check the disks’ sizes:

  1. df -h

Configuring the permissions of a Samba share

Configuring the permissions of a Samba share

Samba share permissions can be a bit fiddly. The user and group IDs which own the file on the Samba server will propagate over to the client machines, which will enforce local permissions themselves.

Ideally, you want to have the same users/groups on all machines. This isn’t always practical but could be achieved with a config management tool such as Puppet or SaltStack, or indeed by backing your local users from an LDAP server.

If this is not possible, the following is suggested:

On your Samba server

  • Create a group which will own all the files, for example samba-users
  • Add all of your Samba users to the group you created – e.g. adduser downloader samba-users
  • Chown all of your shared files and folders to root:samba-users
  • Chmod all of your shared files to 660
  • Chmod all of your shared folders to 770
  • Add the below to the config for your share to enforce the above for all new files and folders:
  1. create mask = 0664
  2. force create mode = 0664
  3. directory mask = 0775
  4. force directory mode = 0775
  5. force group = samba-users

On your client server(s)

  • Create a group which will be able to access all the files on the share, for example samba-users
  • Obtain the group ID (GID) from /etc/group for this group
  • In the mount options of the share (in /etc/fstab) add the uid 0 (root) as in the below example
  • In the mount options of the share (in /etc/fstab) add the gid as in the below example where the GID is 1002
  1. // /mnt/downloads cifs username=downloader,password=foobarbaz,iocharset=utf8,uid=0,gid=1002 0 0

If you u(n)mount and remount the share you will see that all the files are now owned by the group you specified in fstab.


There might be a better way… feel free to comment if you know what it is.

SOLVED – “mount error(13): Permission denied” when doing cifs mount on LXC container (Proxmox)

When trying to do a command like this on a system running inside an LXC container on Proxmox:

  1. mount -t cifs '\\\downloads' -o username=myuser,password=mypass /mnt/downloads


Linux threw the error mount error(13): Permission denied. `tcpdump` showed that no traffic was leaving the container and `strace` didn’t throw up a lot of useful info.

dmesg said this:

  1. [171150.670602] audit: type=1400 audit(1471291773.083:167): apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-default" name="/run/shm/" pid=59433 comm="mount" flags="rw, nosuid, nodev, noexec, remount, relatime"

This reddit post finally yielded the answer. You need to edit /etc/apparmor.d/lxc/lxc-default and below the last deny mount line, add this:

  1. allow mount fstype=cifs,

The final config file will look something like this:

  1. # Do not load this file. Rather, load /etc/apparmor.d/lxc-containers, which
  2. # will source all profiles under /etc/apparmor.d/lxc
  4. profile lxc-container-default flags=(attach_disconnected,mediate_deleted) {
  5. #include <abstractions/lxc/container-base>
  7. # the container may never be allowed to mount devpts. If it does, it
  8. # will remount the host's devpts. We could allow it to do it with
  9. # the newinstance option (but, right now, we don't).
  10. deny mount fstype=devpts,
  11. allow mount fstype=cifs,
  12. }

Now restart apparmour:

  1. systemctl restart apparmor.service

Shut down your VM and start it again.

Your mount command might well work now. If not, check logs again to be sure it’s not a secondary problem (e.g. incorrect hashing algorithm).

Changing the outgoing SMTP (sending) IP address in Postfix

This is far easier than I thought it’d be. I had to change it to get around some blacklisting my primary IP obtained after an unfortunate spamming incident from a compromised user.

Just add the following to your postfix’s and restart Postfix:

  1. smtp_bind_address=

Where is your new outgoing IP address.

How to use Kernel GPIO interrupts on the Raspberry Pi

How to use Kernel GPIO interrupts on the Raspberry Pi

Presumably everyone knows what the Raspberry Pi is, by now, so I’ll not start there. You may or may not know that the RasPi has General Purpose Input/Output (GPIO) pins as standard. Some of these provide 3.3v power, some provide 5v power, some are grounded and the others can be used for input and output. Pins will output 3.3v when connected to ground and will be ‘raised’ as ‘on’ when 3.3v is supplied to them. You change, in software, whether a pin is input or output. Simplez.

The Raspbian distribution has, since around mid 2012, had a kernel which includes support for Kernel GPIO interrupts. The advantages of using these over a traditional poll loop are that response times are faster and CPU is not consumed whilst idle. To test this, I rigged up a small switch circuit on a breadboard. A diagram is as follows:

Raspberry Pi Switch Circuit Diagram

Raspberry Pi Switch Circuit Diagram

Details on the pinout of the RasPi’s GPIO can be found here. This should give you an idea on where to connect the circuit. The code described below uses GPIO 21 (GPIO 27 on rev 2 devices). This is mapped to GPIO 2 in the WiringPi library.

The C code to handle this can be found on my GitHub account under the Raspberry Pi GPIO Interrupt repo. Compilation instructions are in the readme. It’s designed to act as an example though should work out the box. Be sure to tweak the PIN and IGNORE_CHANGE_BELOW_USEC constants to suit your hardware. 10000 micro seconds worked well for my “switch” which was rather just 2 bits of wire touched together. Better switches may cause less jitter.