So I've been having this issue every couple weeks where the Plex database is getting corrupted. DVR recordings don't show up and they are shown in the DVR schedule with "An Unknown Error Occurred", but the recordings are present in the DVR pool. The Plex logs give database errors such as:

SQLITE3:0x80000001, 779, statement aborts at 12: [DELETE FROM 'main'.'fts4_metadata_titles_icu_segdir' WHERE level = ?] database disk image is malformed

Following the SpaceInvaderOne Video, I can fix the corruption, at least temporarily, but it re-corrupts a few weeks or even days later. I see several threads about corruption occurring in UNRAID docker containers, and a few have instructions/scripts for repairing the corruption, but I haven't found any that address the underlying problem. What is causing the corruption, & how can the corruption be prevented in the first place?

I asked on the Plex forums and they seem to want to blame the UNRAID cache (where the docker appdata and therefore the database is stored). Is this not the best place for the docker appdata? My understanding was it was best to place this on fast storage to speed up library navigation.

Thanks

unraid-diagnostics-20251119-2234.zip

Probably unrelated, but this pool should be scrubbed:

Nov 19 22:30:32 Unraid kernel: BTRFS error (device sdg1): parent transid verify failed on logical 1985725661184 mirror 2 wanted 476336 found 452822

Nov 19 22:30:32 Unraid kernel: btrfs_repair_io_failure: 26 callbacks suppressed

Nov 19 22:30:32 Unraid kernel: BTRFS info (device sdg1): read error corrected: ino 0 off 1985725661184 (dev /dev/sdg1 sector 1464548480)

Nov 19 22:30:32 Unraid kernel: BTRFS info (device sdg1): read error corrected: ino 0 off 1985725665280 (dev /dev/sdg1 sector 1464548488)

I tried to scrub that pool, not sure how to interpret these results, but now sdg is spun down and will not spin back up.

UUID:             337e481b-5b2d-4830-855b-2324b53c31cb
Scrub started:    Thu Nov 20 07:20:08 2025
Status:           finished
Duration:         6:27:49
Total to scrub:   1.31TiB
Rate:             58.96MiB/s
Error summary:    read=175727184 super=3
  Corrected:      175597814
  Uncorrectable:  129370
  Unverified:     0

I pulled the disk and I'm running a Hard Disk Sentinel test on it now. I suspect the drive has failed, and at 77536 POH, I don't suppose it owes me anything.

All that being said, this disk is part of my NVR pool so should be unrelated to Plex. but Thanks for catching that, Not sure why there was nothing shown on the UNRAID web UI.

Edited November 21, 2025Nov 21 by BNoyes1

There were uncorrectable errors, so those files should be deleted/restored from a backup, until errors = 0. The corrupt files should have been listed in the syslog during the scrub.

So this database corruption is occurring about every 2 weeks, I need to solve this. Those on the Plex forums seem to be blaming the Unraid Cache.

I’m sure their is plenty of glowing testimony in the UNRAID forums for placing Plex on the cache disk but unless special care is taken with regard to the db files this will happen.

I do have my Plex data files on a cache of 2 NVMe drives with the idea that this would be fast and reliable for loading metadata and artwork from.
The database is already trying to cache data and putting an abstraction layer between it and its files (including the -shm and -wal ) is likely to lead to your condition. If you need that speed it would be better to place it on dedicated NVMe storage.

Is there a way to use a 'dedicated NVMe' in Unraid? It seems like my options are the array or a cache, but I've been using Unraid for less than a year so there's much I don't know.

Any way to prevent it or do I just need to ditch Unraid?

Edited December 31, 2025Dec 31 by BNoyes1

I don't think that would be the reason, I would expect most Plex users to use a pool for that.

18 minutes ago, BNoyes1 said:

Is there a way to use a 'dedicated NVMe' in Unraid?

Not sure what you mean; you can limit any share to use a specific pool.

Also, post new diags to see if there are new btrfs corruptions.

It was a user on the Plex forums that said If you need that speed it would be better to place it on dedicated NVMe storage. I have my docker appdata/config setup on the NVMe cache pool. I used to have the secondary storage set as the array because I wanted a 'backup' incase the NVMe drives failed but when I started having db issues, I turned that off and have the secondary set as none, but that didn't seem to help the issue. I will note that the binhex-plexpass folder in the appdata share lists 'Cache', 'Disk3', 'Disk4', 'Disk5', & 'Disk6' under Location even with secondary storage turned off.

logs are attached.

Thanks

unraid-diagnostics-20251231-1030.zip

Syslog is full of these:

Dec 29 09:17:03 Unraid kernel: SQUASHFS error: xz decompression failed, data probably corrupt

Dec 29 09:17:03 Unraid kernel: SQUASHFS error: Failed to read block 0xab2440: -5

These are typically a bad flash drive, or bad RAM. I recommend starting with the flash drive

OK, I ran a single pass of MemTest and there were no errors, so I replaced the flash drive, moved my license, updated Unraid, and repaired the database. Hopefully that is the source of the DB corruption.

Also recommend monitoring the syslog for any errors.

Database is corrupted again,

Jan 19, 2026 19:19:53.364 [22692467936056] ERROR - [Req#3af8a2] SQLITE3:0x80000001, 11, statement aborts at 10: [SELECT (SELECT max(idx) FROM 'main'.'fts4_metadata_titles_icu_segdir' WHERE level = ?) + 1] database disk image is malformed

Only thing 'concerning' I see in the logs is

php-fpm[10850]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

a few times over.

and this just popped up recently:

Jan 19 19:36:20 Chopper kernel: block nvme0n1: the capability attribute has been deprecated.

Jan 19 19:36:20 Chopper kernel: mpt3sas 0000:05:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM

Note: I changed the name of the server to "Chopper" when I replaced the USB/Updated UNRAID

chopper-diagnostics-20260119-1936.zip

Edited January 20Jan 20 by BNoyes1

6 hours ago, BNoyes1 said:

Jan 19 19:36:20 Chopper kernel: block nvme0n1: the capability attribute has been deprecated.

Jan 19 19:36:20 Chopper kernel: mpt3sas 0000:05:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM

These are harmless.

6 hours ago, BNoyes1 said:

php-fpm[10850]: [WARNING] [pool www] server reached max_children setting (50), consider raising it

This should also not cause any corruptions.

OK, I'm gonna try a different Plex container. I read several recommendations for the binhex-plexpass back when I set it up but it looks like more people actually use the Linuxserver.io Plex container, so I tried to migrate to that one using the guide here: https://www.reddit.com/r/unRAID/comments/1kbh0d2/how_to_migrate_from_binhexplex_to_plex_from/

but what I ended up with was 2 identically named servers on my Plex account; One that was offline/inaccessible, and one with no media 🤦‍♂️.

I guess I'll try again tomorrow.

Database is corrupted again even after switching to the Linuxserver Plex container. I do see BTRFS errors in the log for sdd1 (and sdb1 on the same lines?) both are part of the dvr_pool. In another thread it says to run "btrfs dev stats" and that returns all 0s:

root@Chopper:/mnt# btrfs dev stats /mnt/dvr_pool
[/dev/sdd1].write_io_errs    0
[/dev/sdd1].read_io_errs     0
[/dev/sdd1].flush_io_errs    0
[/dev/sdd1].corruption_errs  0
[/dev/sdd1].generation_errs  0
[/dev/sdf1].write_io_errs    0
[/dev/sdf1].read_io_errs     0
[/dev/sdf1].flush_io_errs    0
[/dev/sdf1].corruption_errs  0
[/dev/sdf1].generation_errs  0
[/dev/sdb1].write_io_errs    0
[/dev/sdb1].read_io_errs     0
[/dev/sdb1].flush_io_errs    0
[/dev/sdb1].corruption_errs  0
[/dev/sdb1].generation_errs  0
[/dev/sde1].write_io_errs    0
[/dev/sde1].read_io_errs     0
[/dev/sde1].flush_io_errs    0
[/dev/sde1].corruption_errs  0
[/dev/sde1].generation_errs  0
[/dev/sdc1].write_io_errs    0
[/dev/sdc1].read_io_errs     0
[/dev/sdc1].flush_io_errs    0
[/dev/sdc1].corruption_errs  0
[/dev/sdc1].generation_errs  0

Is this related to the DB corruption? It is completely separate pool from the NVMe cache that contains the DB.

chopper-diagnostics-20260302-2001.zip

Run an extended self-test on dvr_pool3

Feb 20 02:18:35 Chopper kernel: ata1.00: exception Emask 0x0 SAct 0x1000 SErr 0x0 action 0x0
Feb 20 02:18:35 Chopper kernel: ata1.00: irq_stat 0x40000008
Feb 20 02:18:35 Chopper kernel: ata1.00: failed command: READ FPDMA QUEUED
Feb 20 02:18:35 Chopper kernel: ata1.00: cmd 60/80:60:40:be:af/07:00:21:00:00/40 tag 12 ncq dma 983040 in
Feb 20 02:18:35 Chopper kernel:         res 41/40:80:48:be:af/00:07:21:00:00/40 Emask 0x409 (media error) <F>
Feb 20 02:18:35 Chopper kernel: ata1.00: status: { DRDY ERR }
Feb 20 02:18:35 Chopper kernel: ata1.00: error: { UNC }
Feb 20 02:18:35 Chopper kernel: ata1.00: configured for UDMA/100
Feb 20 02:18:35 Chopper kernel: sd 0:0:0:0: [sdb] tag#12 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s
Feb 20 02:18:35 Chopper kernel: sd 0:0:0:0: [sdb] tag#12 Sense Key : 0x3 [current] 
Feb 20 02:18:35 Chopper kernel: sd 0:0:0:0: [sdb] tag#12 ASC=0x11 ASCQ=0x4 
Feb 20 02:18:35 Chopper kernel: sd 0:0:0:0: [sdb] tag#12 CDB: opcode=0x28 28 00 21 af be 40 00 07 80 00
Feb 20 02:18:35 Chopper kernel: I/O error, dev sdb, sector 565165640 op 0x0:(READ) flags 0x80700 phys_seg 33 prio class 2
Feb 20 02:18:35 Chopper kernel: ata1: EH complete

dvr_pool3 failed SMART, so I swapped it out and I am waiting for the drive to preclear & and the pool to resilver, although I don't think that'd cause the DB corruption.

Additionally, someone on reddit recommended changing the Plex container's '/config' path to "/mnt/cache/appdata/plex" instead of "/mnt/user/appdata/plex". Something about the appdata share listing "Exclusive Access" as 'No'.

Edited March 3Mar 3 by BNoyes1

2 hours ago, BNoyes1 said:

Additionally, someone on reddit recommended changing the Plex container's '/config' path to "/mnt/cache/appdata/plex" instead of "/mnt/user/appdata/plex". Something about the appdata share listing "Exclusive Access" as 'No'.

You do need to work on your Docker related shares - appdata, system.

Ideally, appdata and system would have all files on cache with nothing on the array, so Docker will perform better, and so array disks can spin down since these files are always open. And, after you get appdata all on cache, you can make it Exclusive so no need to change that path.

The way you have it right now, I don't know which disk your plex appdata is on, both of those shares have files on cache and multiple array disks.

Nothing can move open files.

Disable Docker in Settings.

Set appdata and system shares to

Primary:cache; Secondary:array; Mover action:array->cache

Run Mover, wait for it to complete, post new diagnostics.

tried it a few times, but it continues to say that some files are on disk5.

chopper-diagnostics-20260304-2001.zip

Your appdata is not set the way I said

23 hours ago, trurl said:

Primary:cache; Secondary:array; Mover action:array->cache

oh, yea, when it didn't work I turned mover back off for appdata & system and restarted docker so Plex would work again. I tried again here, and same thing, still lists disk5 for some share files/folders. I will note that I ran mover with logging on and it printed '<filename> file exists' many times over.

chopper-diagnostics-20260304-2205.zip

4 hours ago, BNoyes1 said:

I ran mover with logging on and it printed '<filename> file exists' many times over.

This means there are duplicates; the mover will not overwrite any files. You need to delete one of the copies.