After installing the FairPhone OpenSoure OperatingSystem following http://code.fairphone.com guide (in fact, https://gitlab.com/fposos/builder), I was unable to encrypt the phone. When I try to encrypt the phone it reboots without any changes.
Can you encrypt the phone?
Yes, I can confirm I have an encrypted FPOSOS.
Same for me, it also just reboots, but actually I cannot say whether it’s encrypted afterwards or not. And I don’t know how to find out …
How do you know that it’s encrypted? How can I verify this?
Well, I need to enter the PIN to decrypt “userdata” before Android will boot. After booting, I enter the PIN for each SIM card. And then I once again need to enter the system PIN to unlock the device - this is standard behavior for an encrypted Android handset. I have to admit I did not try to hack it yet…
Ok, this doesn’t happen for me, so the encryption was indeed not successful. Though I have no idea why it didn’t work. 
I confirm: encryption did not work for me either with FP OSOS.
So it works with the regular ROM but not with FP-OSOS? I thought they were basically the same…
I started to investigate the issue and got some debugging information and a possible solution. I think, the issue is a bug caused by wiping the userdata partition (more precisely by formatting it) and the solution is to do a factory reset or explicitly flash the userdata image in addition to the other images (see below for more details).
First of all, in adb logcat the following two lines are relevant for the erroneous encryption process:
E/Cryptfs ( 236): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs ( 236): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.
An internet search brought a blog post which linked to this xda forum topic. According to these sources, the problem probably is as follows: For the encryption to work, you need some free space at the end of the userdata partition right behind the userdata filesystem (the “crypto footer” from the adb error message, see this technical blog post for more information about it in general). However, when flashing another ROM, the userdata partition gets wiped, reformatted and equipped with a new filesystem. It seems that in this process no crypto footer is left and the filesystem fills the whole partition (i.e. it “overlaps crypto footer” as described in the adb error message).
CAUTION: The xda thread provides two zip files and suggests to flash them to solve the problem. I do not advice to flash these zips, as it’s not clear how trustworthy they are and they might contain malware/viruses. However, note that this is just precaution (due to the small amount of answers and userbase over there; also I don’t see the source code documented) - I have no evidence and do not claim that the zip files contain stuff they shouldn’t! If you like to try it out, go ahead, but do it on your own risk (as with all the other stuff you flash or install on your phone from some random source/website 
). Anyway, there is a more natural solution below.
As wiping the userdata partition seems to cause the issue, I tried out different flashing scenarios. Essentially, there are two common flashing procedures (the -w in brackets means you can insert it or leave it out):
Flash all images at once: fastboot [-w] flashall
Flash boot, recovery and system image sequentially:
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot [-w] flash system system.img
fastboot flashall flashes the boot, recovery and system images (erasing the system image before). The -w option (in both cases) does the following with both the userdata and cache partition: it erases the image, then formats the partition and finally flashes the new image. And it seems as if this wiping process causes the problem. Don’t ask me why.
Note: Once the problem occurs, flashing a new ROM (more precisely: a new system image) without touching the userdata partition (i.e. without wiping or flashing a userdata image) won’t change anything concerning the issue. As in that case all user data is preserved, this behaviour completely makes sense - remember that encrypting the phone only encrypts the userdata partition! Therefore, to solve the issue one definitely needs to do something with the userdata partition.
As wiping didn’t solve but rather cause the issue in the first place, I tried another variation and flashed the userdata image as well:
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot [-w] flash system system.img
fastboot flash userdata userdata.img
And now it worked! Note that it didn’t matter whether I used the -w option or not before flashing the userdata image.
Moreover, if you don’t want to flash the whole ROM again, you can also just
Settings --> Backup & reset --> Factory data reset
fastboot flash userdata userdata.img
to solve the issue. But remember to carefully backup your apps and data before and to make a plan for restoring it!
I really cannot explain why this works in contrast to fastboot -w flash system system.img - I guess it’s the formatting and flashing process that is somehow responsible - but I don’t know why.
Anyway, it works this way, I can reproduce it and I hope it will help you as well!
Interesting, thanks for your research! Do you want to add something to the compilation guide? Is there something that could be added to the build scripts somewhere?
Well, it might be possible to fix this bug in the build scripts or somewhere else, but I’m not used to bash scripting and don’t know how to fix it. Nevertheless, I can add the workaround to the wiki.
Cool input, thanks a lot. 
But did not work for me. I found another solution that works for me.
FP2# dd if=/dev/zero of=$PATH_TO_YOUR_USERDATA
The previous suggestions did not work for me. I was still getting the following error in adb logcat:
E/Cryptfs ( 237): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.
I had to reduce the size of the userdata partition, using this guide: https://forum.cyanogenmod.org/topic/82292-cm102-encryption-does-not-start-stuck-at-splash-screen/?do=findComment&comment=439000
UPDATE
You can also resize the userdata partition without losing your data:
e2fsck -y -f /dev/block/mmcblk0p20resize2fs /dev/block/mmcblk0p20 6790139The last number is the number of 4K blocks and makes sure that there is enough space for the encryption footer (appended at the end of the partition).
I received my Fairphone a couple of days before FPOS OS was released. I installed the officially available build from code.fairphone.com and could encrypt the smartphone without any problems. The phone rebooted and the encryption animation was shown. Maybe the problem has been fixed in the meantime?
Is there a way to verify that the encryption worked as expected? TWRP cannot mount /data, and I have to enter the passcode when booting, so I guess that the phone is indeed encrypted.
(It should be noted that this was actually the second time I encrypted the phone. I first installed FPOS OS, encrypted it and did some configuration. In the end, I resetted the phone in TWRP and re-encrypted it afterwards. I am not sure whether the encryption animation was shown during the first encryption, but /data could also not be accessed, and the passcode had also to be entered during boot.)
I can confirm that. Data encryption of the official FPOSOS release works without problems.
Strange, the encryption did not work for me with the official FP OSOS release. @freibadschwimmer did you flash FP OSOS over the self-built OSOS or the proprietary version of the Fairphone OS (with Google services)? Could it be that the partitions are sized differently on our phones?
Neither.
I flashed it over Sailfish OS 
(which was flashed over 1.2.8)
Interesting
My journey was as follows:
E/Cryptfs ( 237): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.
Do you know if flashing changes the size of the userdata paritition if the userdata partition already exists?
This is a good question, though I don’t have an answer for that.
It would make sense if flashing a whole system also rewrites the partition table/scheme, but I don’t know if that is actually the case.
When you tried encrypting, how full was your data partition? I think that the system may first make a copy of your files before starting the encryption process, so it might be necessary (though I don’t know that) that you need at least as much free space as the data needs. But this is just an assumption. I usually always encrypted at the very beginning of using a new OS install, before pulling any backups on the phone.
I encrypted practically right after flashing FP OSOS.
The system does not make a copy of your files when encrypting but rather encrypts them on the fly. In order to encrypt a partition Android adds a crypto-footer (additional space after the partition) and this space was missing/not enough. So the problem was not that the filesystem was too full but that the size of the partition was too large and the crypto footer could not be added anymore.
EDIT
The relevant piece of code which causes the encryption to be aborted is located here:
https://android.googlesource.com/platform/system/vold/+/lollipop-mr1-release/cryptfs.c#2994
If less there are less than 32 (CRYPT_FOOTER_OFFSET / CRYPT_SECTOR_SIZE) sectors available after the filesystem, the encryption is aborted.
Now the question remains: Why are there less than 32 sectors available on some installations? How can the partition be different when the same image is used?
Unfortunately the update to the 16.05 version didn’t work for me, so I flashed the whole system. Then I ran also into the problem that I couldn’t encrypt the device anymore.
Anyhow, following @tphysm’s workaround I was able to encrypt the device again! So thanks for that tips. I can confirm now that this workaround also worked for me.