Short answer: probably not. The longer answer requires some background.
To simplify heavily, a file system has two components:
- The actual file data. These are simply blobs of data without names or types or anything attached to them. They are placed end-to-end but typically aligned to start at the boundaries of "blocks" of storage, so a file that's not an integer multiple of the block size will have some unused space at the end before the next file starts (this is part of why Windows' file properties window will sometimes report different values for "file size" and "size on disk").
- The file system directory (sometimes called an "allocation table" or "file table" or similar). This is not the same as the "directories" (or "folders") in the file system - you can build a really primitive file system without that kind of directories being represented at all, or even existing, but you cannot avoid having the file system directory. The directory is stored at a known location and records the name (and sometimes the path) of each file, the blocks of the storage where the file's data is found, and various file metadata (size, timestamps, access permissions, etc.). Many file systems, where directories/folders also can have metadata, store records for each directory - as well as for each file - in the file system directory table. This directory also typically stores file system metadata, such as how much total free space there is, lists of blocks of free space, and so on.
When you "delete" a file, all that is actually happening (most of the time), is that the file's record is removed from the directory table (and various cleanup, like the file's blocks being added back to the list of free blocks and the file's size being added to the total free space). Critically, the file's data is unaffected (until some other file overwrites it). Thus, file undelete utilities basically do the following to try and find deleted files:
- Check the start of each "unused" block for data. If there's data - that is, if it's not all null bytes - check for the "magic number" (or string) that most file types have at their beginning, which indicate what kind of file it is. (For example, all Windows executable files start with "MZ", all Zip archives - including things like .APK files - start with "PKZIP", etc.)
- If it finds the start of a file format that it recognizes, the tool checks the rest of the block (and sequential ones, if needed) to verify that all the data makes sense. Determining the end of the file can be tricky; if there's a bunch of null bytes starting somewhere in a block and ending at a block boundary, then the file probably ended right before those byes, but the data between the end of the file and the block boundary might be old, partially-overwritten data instead. Files can also be "fragmented" across non-contiguous blocks, in which case the recovery tool might be able to recognize the start of the file but not the rest of it.
Essentially, the tool tries to find files that it can recognize by their data alone. This poses an obvious problem when trying to recover encrypted files: the output of any decent cipher is indistinguishable from random noise, so nothing is going to be recognizable! Depending on exactly how the file system encryption works, it might be possible to guess where files start and end, but recognizing the individual files is going to be impossible without knowing the algorithm and the key they were encrypted with.
Now, if you happen to know the key and algorithm used for at least some of the encrypted data, you could decrypt that data and see if the recovery tool can recognize it. There might be tools that can do that for encryptfs, if you supply them with the key. A run-of-the-mill tool won't cut it, though.