I'm writing this as an answer as I need the space..
Quoting from TJ- (IRC #lubuntu-devel, https://launchpad.net/~tj)
EXT4_ENCRYPT_FLAG is apparently set... so deliberate or corruption
Best to find out if there is a separate /boot/ file-system or if
/boot/ is part of the root file-system - because GRUB is presumably
trying to read its /boot/grub/* files and failing
I'd suggest boot from LiveISO and do an fsck initially plus use
'dumpe2fs -h ...' on that block device to grab the FS metadata
The 'LiveISO' would mean any Lubuntu/Ubuntu install media and selecting 'try ubuntu', then
fsck your drive.
Please though read the full detail below :-
<TJ-> ./grub-core/fs/ext2.c::grub_ext2_iterate_dir() ...
<TJ-> if (diro->inode.flags & grub_cpu_to_le32_compile_time (EXT4_ENCRYPT_FLAG))
<TJ-> grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET, "directory is encrypted");
<TJ-> return 0;
<TJ-> So, EXT4_ENCRYPT_FLAG is apparently set... so deliberate or corruption
<TJ-> Best to find out if there is a separate /boot/ file-system or if /boot/ is part of the root file-system - because GRUB is presumably trying to read its /boot/grub/* files and failing
<TJ-> I'd suggest boot from LiveISO and do an fsck initially plus use 'dumpe2fs -h ...' on that block device to grab the FS metadata
<TJ-> From what I can see this is per-directory not per-filesystem. There's a tool in e2fsprogs "e4crypt" but its man-page is quite opaque on how to use, but looks like this has to be done deliberately. If this is not corruption and is not done by the user then I'd suspect Malware or some malicious person with access to the PC
<TJ-> Unfortunately GRUB isn't telling us which directory is encrypted
<TJ-> Invstigate from a LiveISO for sure
<TJ-> This page is useful https://loune.net/2018/12/ext4-encryption-multiple-filesystems-and-salt/
<TJ-> apparently if there are some directories/files encrypted the superblock will contain:
<TJ-> # sudo dumpe2fs /dev/sdb2 | grep Salt
<TJ-> Encryption PW Salt: d24c7f08-5092-4b3a-9180-6ed8244513e8
<TJ-> So I'd think that'd appear in the '-h' superblock summary output I mentioned earlier
<TJ-> more interesting, the Arch wiki contains this "Note: Ext4 forbids encrypting the root (/) directory and will produce an error on kernel 4.13 and later"
<TJ-> So that would infer the encrypted directory isn't / but possibly /boot/ or /boot/grub/
<TJ-> and apparently it is an FS feature since you can do "tune2fs -O encrypt /dev/device"
<TJ-> There's a tool in the archive for generic handling of this kernel-level file-system encryption, the package is "fscrypt" and it's a single GoLang binary. The package description suggests it handles PAM for user log-in to add the keys.
<guiverc> if the OP was correct in not having encryption; i doubt the fscrypt would help (it'll be corruption or user doesn't know their own system..)
<TJ-> Well, it would be an easy check to see if that package is installed
<TJ-> e2fsprogs will always be installed so we can't deduce usage of e4crypt from its presence, but if fscrypt is installed, we can
the full discussion can be found when it appears, - https://irclogs.ubuntu.com/2019/08/16/%23lubuntu-devel.txt ; I've only provided parts