I fear this is going to be ridiculously complex. Even if your file is "contiguous", it is still going to spread over many of the ~465 block groups in that filesystem. The Overview section of the Ext4 Disk Layout shows what you are up against. The nonstandard block size and possibility of Flexible Block Groups means I can't calculate where those group descriptors might be located or what their size might be. It is all information that I'm sure can be dug out from the super block. I see that the filesystem features do include "flex_bg" and "sparse_super", so it is apparent that this is the most complex case. It's still not something I could calculate without spending a huge amount of time with a hex editor examining those ext4 metadata structures.

Here's a thought. If you have another disk at least as large as that sda4 partition, you could put it in the NAS, create a partition of that size, and create an ext4 filesystem there with the same features as the current filesystem. You could then proceed to fill that filesystem with a file having blocks containing a recognizable mark and a block number. That would allow a program to build a map of where the user data blocks are. Due to possible inode indirect blocks it won't be a 100% match to the blocks available to your LUKS file, but it should be a place to get started. If you can once figure out just where the blocks of your "contiguous" file actually were, it's then a fairly simple matter to create dmsetup mapping that would extract your file.

I know I'm grasping at some very long, thin straws here, but I'm at a loss for other ways to proceed. I don't think that photorec is going to be very useful at rebuilding a huge file of apparently random data.

Suggestions, anyone??

If it can help, I do have an earlier backup of the encrypted content. The probably only thing I'll loose if I can't rescue data from this drive (as far I can remember) is another LUKS file, encapsulated in the first LUKS file.

I'm pretty sure almost data is still there: fsck should have deleted inodes but not content, right?

Since encrypted file size is not stored in LUKS header and encryption is only based on block position on disk, is there not a way to decrypt a whole raw device, and then try to rebuild deleted inodes based on raw content or rescue files by reading apparently free space?

What I tried is to dd from LUKS header to end of disk, then decrypt that file, and then, on the decrypted mapped device I tried to:
1) photorec it: aborted since it estimated a month just to read inodes...
2) mount it: failure
3) e2fsck it: deleted almost everything and then resulting filesystem is still unmountable
I know that this method assumed original luks_file is contiguous, which is certainly not true; but since I have no more idea, I had to try.

Thanks!

The problem is that what matters is not the block position on the disk but the block offset in the LUKS container. When that container is a raw disk or a partition, then it's easy to determine where any given offset apears on the underlying media. An LVM logical volume would be somewhat harder, but still doable. But, your container is a file in an ext4 filesystem. You have found where that file begins on the disk, so some number of blocks immediately follow. However, at some point, call it block N, you run into a group descriptor in that outer filesystem, and then your file's blocks resume with block N+1 after that group descriptor. You don't know where that group descriptor begins or what its size is. You can go searching/calculating, but you will have to do that 400+ times to find all of your file's segments. That's just not practical unless your data is extremely valuable (e.g., your PhD thesis, or perhaps a large Bitcoin wallet).