I moved my main Eden build from stable to nightly. They use different package names, so both can coexist, and every game launched fine. But once inside, none of my saves loaded — every game behaved like a first run. My first thought was that nightly had wiped its data directory or overwritten the saves, so I went to check the files.

The files were all there. What was missing was that nightly was looking in the wrong place.

The two builds share games but not user profiles

Eden keeps Switch saves under nand/user/save/ in its data directory. That path is not a single level; roughly, it is nand/user/save/0000000000000000/<user profile ID>/<TitleID>/, and the middle level is the user profile. Stable and nightly are two separately installed apps with separate data directories, and more importantly: nightly generates a brand-new user profile ID on first launch, unrelated to the stable one.

On my device the stable active profile was D2AE7D815565D5C93F432C7C74A7DD6A, while nightly generated 173CB8FB1F16348366B4CABB88A445D9. The saves were physically present in nightly’s data directory (after copying from stable), but nightly only looks for game saves inside its own active profile folder, so it saw none.

Where the folder name comes from

That random-looking hex directory name is not random. The logs show it comes from the user profile UID, arranged as the byte-reverse of the UID — the same identity data, with the bytes in the opposite order. As soon as two builds generate separate UIDs, the folder names necessarily differ, which is why switching builds, or even nightly reinitialising itself, makes saves “not line up”. Understanding this rules out the fear that the files are corrupted.

Why copying the saves directly fails

The obvious trap is copying stable’s whole save/ into nightly’s save/ and calling it done. Nightly still finds nothing. The reason is that the directory copied from stable is named D2AE7D..., while nightly’s active profile is 173CB8FB...; the data is in the library, but not in the drawer nightly actually queries. Migration therefore needs two overwrites: bring stable’s whole save root over first, then copy the contents of stable’s active profile into nightly’s active profile directory.

flowchart TB
    A["Stable<br/>active profile D2AE7D..."] --> B["Copy save root<br/>into nightly"]
    C["Nightly<br/>auto-generates profile 173CB8FB..."] --> D["Nightly only looks in its own active profile"]
    B --> E["Copy the contents of D2AE7D<br/>into 173CB8FB"]
    D --> E
    E --> F["Fix 777 / 666 permissions"]
    F --> G["Saves in place"]

The actual migration commands

In practice it is three steps. The first copies all of stable’s profiles into nightly’s save root (same-named profiles merge naturally); the second copies the contents of the D2AE7D... profile into the 173CB8FB... profile nightly actually uses; the third fixes permissions, because files under Android/data end up owned by shell after copying and the app needs read/write access.

# 1. all stable profiles -> same-named nightly profiles
cp -rf <stable>/nand/user/save/. <nightly>/nand/user/save/

# 2. main profile contents -> nightly's active profile
cp -rf <nightly>/nand/user/save/0000000000000000/D2AE7D815565D5C93F432C7C74A7DD6A/. \
       <nightly>/nand/user/save/0000000000000000/173CB8FB1F16348366B4CABB88A445D9/

# 3. permissions: dirs 777, files 666, or the app cannot open or write them
find <nightly>/nand/user/save -type d -exec chmod 777 {} \;
find <nightly>/nand/user/save -type f -exec chmod 666 {} \;

Afterward I verified a few games: stable and nightly both reported 72 saves, and I compared file counts for NieR, Breath of the Wild, Tears of the Kingdom and Mario Kart 8 — all matched. That check matters, because a copy can look successful while quietly dropping files.

A separate cause that looks identical

There is a second phenomenon that looks exactly the same but has a completely different cause, worth separating. If, in a game’s Add-ons screen, the Update or DLC rows get unchecked too, Eden disables the game update and DLC, the game runs at its base version, and it can no longer read saves created by a newer version — which also shows up as “my save is gone”. In that case not a single save file is missing; only the game version is wrong. The way to tell them apart is to look under nand/user/save/ first: if the files are there, it is a version problem and re-enabling Update/DLC fixes it; if not, the migration genuinely did not land.

One more expectation to set: nightly’s active profile ID is generated the first time it launches and has nothing to do with stable. If nightly ever regenerates its profile — say after clearing app data — the saves will mismatch again and need the same double overwrite. That is why keeping a backup of nand/user/save/ is the safe move, so migration can be repeated at any time.

On this handheld, most save problems were never “the data is gone” but “the data is still there, and the app is looking in the wrong directory”. Once the user-profile layer is clear, switching back and forth between stable and nightly stops being a problem.

Article Link: