Let's quickly start with the general purpose of the OEM environment: it allows the creation and customization of a single machine or a small batch of machines at a time. This is (relatively) similar to the Windows concept of audit mode. A typical OEM workflow would look like this:
- An OEM boots up a device and installs OEM mode to the device.
- The OEM will configure the device, install any applications, load drivers, so on.
- After configuration, the OEM will prepare the device to the end-user for shipping. The system will shut down/restart. [I assume this was the step that the user ran, triggering this entire situation.]
- If the device is a "gold-master" and is part of a larger batch of devices, the device will be imaged out and cloned to other devices.
- A prepared device is shipped to end-users.
- The user receives a prepared device, turns it on, and goes through OOBE setup (username, password, etc.).
Most home or small workshops offering Ubuntu installation would use OEM installation on a per-device basis without any imaging. The end user would receive the device, and on first-boot they'd be prompted to create their account and configure everything.
So, what happens to the
oem user when the device is prepared for shipping? Well, when a device is prepared for shipping, it kicks off a number of tasks that delete the OEM user and prepares the environment (uninstalling packages, updating systemd unit files, and so on). All of the scripts for preparation are located in
/usr/sbin/oem-config*, and can be viewed here. The user is them dumped back into Ubiquity (the setup screens), where they go through account setup.
The bad news here is that all of these tasks are pretty write-intensive. A lot of the (recently-)freed blocks that was occupied by
/home/oem will now be used for the new user's configurations and the changes made by the new system and the OOBE configurations.
With all this being said, you're fighting an uphill battle trying to recover this data. The files lost are (relatively) small, and as such are very easy to get overwritten when the new account is created. Tools like
autopsy would likely be your best bets, as you've already tried. If these tools can't recover anything, there likely isn't much more that can be done save for some very expensive and/or very powerful recovery tools that people don't usually have access to.
You did mention the existence of a
/home/oem file as well as a folder. This may be causing data recovery tools to get a bit confused - a file can't have subfiles, so any attempts to piece together a file tree will fail at this point. When running a disk recovery tool, be sure to look for any files that are "orphaned" or otherwise don't belong to a specific directory.
I'm going to go back to my recommendation from the comments of using
photorec. Instead of focusing on partition- or filesystem-level recovery like
testdisk, it tries to pull and recover individual files while disregarding the directory or filesystem structure. This is suboptimal (paths and potentially file names are lost), but having the raw data recovered is better than having nothing recovered. I suspect
autopsy has a similar "miscellaneous" output bin, but I'm not familiar enough with the tool to tell you where to look for that.
photorec can't recover the files themselves, it's likely that they were (mostly) overwritten during the personalization phase initiated by the user. In this case, it might be best to contract the services of a data forensics expert with access to the necessary tools and knowhow to recover data like this.