Hello doron,
thanks for the input!
I was not aware that I also had to resize the LUKS, after some research I came up with the following cookbook so far.
Unfortunately currently I do not have a testsystem on which I can try this, in the other OMV NAS that I have all bays are already filled with disks 
Update 20170312: I was able to successfully grow my RAID5 using the following cookbook
1. Umount filesystem of the RAID5
umount /media/<xyz>
2. close the crypto device
cryptsetup luksClose <crypt device> (taken from /dev/mapper/<crypt device>)
3. Add new drives to RAID5 (before: 4x4TB, after:6x4TB, new drives: /dev/sdbX and /dev/sdbY)
mdadm --add /dev/mdX /dev/sdbX /dev/sdbY
mdadm --grow --raid-devices=6 --backup-file=/root/grow_mdX.bak /dev/mdX
Reshape of the RAID5 with the 2 new drives took around 26hrs to complete. Progress can be checked using cat /proc/mdstat
4. open the crypto device
cryptsetup luksOpen -d /path/to/keyfile /dev/mdX <crypt device>
5. resize the crypto device
cryptsetup resize <crypt device>
6. check and resize the ext4
e2fsck -fn /dev/mapper/<crypt device>
resize2fs -p /dev/mapper/<crypt device>
Note:
The size of the grown RAID5 would be ~19TB, therefore resize2fs gave the following error on my machine:
resize2fs: Size of device /dev/mapper/<crypt device> too big to be expressed in 32 bit susing a blocksize of 4096.
It seems like new ext4 filesystems automatically get created using the -O 64bit option, therefore allowing them to have maximzum size of1024 PiB.
If the ext4 has been created in "32bit" (which was the case on my OMV machine), then the maximum size of the filesystem is limited to 16TiB.
This topic has been adressed in e2fsprogs Version 1.43, unfortunately it seems this version has not made it yet into the jessie repository.
When running dpkg --list | grep e2fsprogs it would report e2fsprogs 1.42.12-2+b1 on my OMV machine.
In order to adress this, you have to build the e2fsprogs Version 1.43 from its sources and then resize the filesystem by running the following commands with the new e2fsprogs version
6.1 download and build e2fsprogs Version 1.43
apt-get install git
cd /usr/local/src
git clone git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
cd e2fsprogs
./configure
make
6.2 resize the filesystem using e2fsprogs Version 1.43
cd /usr/local/src/e2fsprogs/
./resize/resize2fs
Check whether resize2fs reports version "1.43.5-WIP" (or similar newer version)
./resize/resize2fs -b /dev/mapper/<crypt device>
This will convert the "32bit ext4" to a "64bit ext4". It took approx. 10mins to complete.
./resize/resize2fs -p /dev/mapper/<crypt device>
This will resize the ext4 to the size of the RAID5. It also took around 10min to complete.
./e2fsck/e2fsck -fn /dev/mapper/<crypt device
Check the filesystem for any errors.
7. mount the ext4 filesystem
mount /dev/mapper/<crypt device> /media/<xyz>
Note:
It seems like systemd was unlocking and automounting my RAID5 during the procedure from time to time. I did not investigate further into this, but I checked after each step that the filesystem was unmounted and the luks device was closed. When it was unlocked/mounted I would just run the command in 1. and 2.
Luckily it did not break anything when I grew my RAID, but maybe somebody has some input in how to prevent systemd (or whatever service was causing this behaviour) from unlocking/mounting the filesystem.
Regards,
raisOr