Unraid Audiobook Library Path Consolidation

System: Unraid media array Status: RESOLVED (eventually) Duration: Several hours Data Reviewed: 3.5TB of audiobooks Lesson Learned: Check your folder structure before you start moving 4,630 directories

This was a recovery and verification pass after a complex file reorganization. The goal was simple: reconstruct the exact state, verify the move, and avoid touching data until the path structure was understood.

The Discovery: Nested Library Paths

I had been working on the Unraid array, reorganizing the AudioBooks share. What looked like a simple cleanup was actually a three-level-deep legacy path problem:

What was actually happening: I was unwinding a three-level-deep folder structure that looked like this:

AudioBooks/
├── AudioBooks/           ← Level 2: 3,582 EMPTY FOLDERS + 2 duplicate files
│   └── AudioBooks/       ← Level 3: 4,630 ACTUAL AUDIOBOOKS (3.5TB)

That's right. AudioBooks/AudioBooks/AudioBooks/.

Best guess: a prior GUI-based copy or move operation happened without the full path visible. When identical folder names exist at multiple levels, it is easy to move a folder into a same-named parent and create path drift.

Reconstructing State

When I came back to the task, the first step was reconstructing state from logs and documentation. I needed to know:

What we were moving
Where we were moving it to
Whether the move was complete
Whether the database was updated

The important point: verify the array directly, not local assumptions.

The Investigation

Step 1: verify the host is reachable.

Step 2: verify the AudioBooks share exists.

Step 3: check the documentation from the earlier maintenance pass.

I found Meridian-Mako-Silo-LOG-FIX-BANDAID.md in my Documentation folder. Timestamp: 2026-01-20 (earlier today).

The doc said the work was COMPLETED:

Logs fixed (rsyslogd was holding a deleted 112MB file)
Synology getxattr spam suppressed
Audiobookshelf runaway stream killed
AudioBooks triple-nested structure FIXED

But was it?

The Verification

SSH'd into the Unraid host to check:

ls AudioBooks/ | wc -l
# 4638

du -sh AudioBooks/
# 3.5T

Good. That's the right number. Let me check if any nested folders still exist:

find AudioBooks/ -maxdepth 2 -type d -name "AudioBooks"
# (no results)

No nested folders. The move was complete.

Let me verify the actual content (not just placeholders):

ls AudioBooks/ | head -5
# 01-genesis
# 02-exodus
# 03-leviticus
# ...

ls AudioBooks/01-genesis/
# 01-genesis.m4b
# cover.jpg
# metadata.json

Real files. Real audiobooks. Not placeholders.

The data was safe. Past Me had successfully flattened the structure from three levels to one.

The Database Problem

But there was a catch. The Audiobookshelf container had been recreated with a fresh database.

ls -lh <appdata>/audiobookshelf/
# absdatabase.sqlite           356K  ← Current (empty)
# absdatabase.sqlite.bak-20260120  107M  ← Old (had all metadata)

The old database referenced the nested AudioBooks/AudioBooks/ path. The new database was empty and pointed to the flat /audiobooks path.

Options:

Start fresh (lose metadata, listening progress, but clean structure)
Restore old database (keep progress, but risk path mismatches)

I chose option 1. The path change was significant enough that a fresh metadata index was cleaner and safer than carrying forward stale absolute paths.

The WebUI Button Mystery

Final twist: The Unraid GUI no longer showed a WebUI button for Audiobookshelf.

Why? The container had been recreated via docker run instead of through the Unraid GUI, so Unraid didn't recognize it as "its" container.

The fix:

Remove the orphaned container
Recreate it through the Unraid Docker GUI using the existing template
The template was already updated with the correct flat AudioBooks/ path

Fortunately, Docker containers are ephemeral. The data (config, database, metadata) was still on disk under the appdata directory. I could recreate the container safely from the Unraid template.

The Resolution

What was moved:

4,630 audiobooks from AudioBooks/AudioBooks/AudioBooks/ → AudioBooks/
3.5TB of data

What was deleted:

3,582 empty placeholder folders at level 2
2 duplicate Duin mp3 files

What remains:

Flat structure: 4,638 items in AudioBooks/
Fresh database (need to rescan library)
Clean container template in Unraid GUI

Next steps:

Open the Audiobookshelf admin UI on the private LAN
Create new admin account
Add library pointing to /audiobooks
Start library scan (this will take a while — 4,638 folders to process)

Lessons Learned

Document as you go — The log file saved me when context was lost
Verify, don't assume — SSH in and check the actual state
Docker containers are ephemeral — The data is what matters
Empty folders are insidious — 3,582 placeholders masquerading as content
Remote systems evolve — verify current state before making changes.

And most importantly: verify with the filesystem before acting. The files were still there; the work was proving the path state before changing anything.

Session recovered from Claude Code conversation transcript AudioBooks structure: FLAT Database: FRESH Panic level: MINIMAL