This does not seem to be officially documented but makes sense that an overlay on an overlay does not work and is considered an unsupported filesystem as is even NTFS .  Some admins/organizations try to use ecyptfs as a simple solution to encrypt the contents of Docker.  Instead, you could probably use something like Luks to encrypt it all.

One other half measure that you can use, is to do mount a volume that is encrypted to your container.  If all the sensitive data is located on the volume alone, that would provide a better level of security than no encryption.  However, if during the operation of the container, data is copied to portions of the container that are not part of the encrypted mount volume, then this does expose any of those portions of data.  It also won't help protect any secrets that are stored in Docker, since those will live in unencrypted /var/lib/docker, so keep that in mind.

You'll get errors like this when trying to run on ecryptfs or another overlayfs system:

[graphdriver] trying configured driver: overlay2
failed to mount overlay: invalid argument     storage-driver=overlay2
failed to start daemon: error initializing graphdriver: driver not supported: overlay2

overlayfs: filesystem on '/home/docker/overlay2/check-overlayfs-support130645871/upper' not supported as upperdir

Basically Docker mainly supports and recommends overlayfs, so this does create a limitation if the data directory for docker (by default /var/lib/docker) is already using overlayfs for any reason.

References:

https://github.com/moby/moby/pull/23121

https://github.com/moby/moby/issues/22577

https://forums.rancher.com/t/overlayfs-filesystem-on-not-supported-as-upperdir/20690

docker, overlayfs, filesystems, ecryptfs, filesystem, overlay, supported, upperdirthis, documented, unsupported, ntfs, admins, organizations, ecyptfs, encrypt, contents, luks, ll, errors, upperdir, mainly, supports, recommends, limitation, directory, default, var, lib, references, https, github, moby, forums, rancher,

Latest Articles