I noticed recently that my cache drive was at 100% capacity. Mover would not move any files. I uninstalled Mover Tuning and mover still failed.

The mover log indicated that the problem seemed to be related to VM images that were residing on both the cache drive and the array. I disabled VMs and was unsuccessful in my attempts to delete the images from the cache drive because they were read-only -- even after chmod-ing them to 755.

In maintenance mode I check the file system of the cache drive and the output is below.

[1/8] checking log skipped (none written)

[2/8] checking root items

[3/8] checking extents

data extent[328848568320, 20480] referencer count mismatch (root 257 owner 260 offset 1215193088) wanted 0 have 1

data extent[328848568320, 20480] bytenr mimsmatch, extent item bytenr 328848568320 file item bytenr 0

data extent[328848568320, 20480] referencer count mismatch (root 321 owner 260 offset 1215193088) wanted 1 have 0

backpointer mismatch on [328848568320 20480]

ERROR: errors found in extent allocation tree or chunk allocation

[4/8] checking free space tree

[5/8] checking fs roots

[6/8] checking only csums items (without verifying data)

[7/8] checking root refs

[8/8] checking quota groups skipped (not enabled on this FS)

Opening filesystem to check...

Checking filesystem on /dev/sdg1

UUID: f296ff39-0784-48e7-a757-99d0ffd864d2

found 949109067776 bytes used, error(s) found

total csum bytes: 837853060

total tree bytes: 1728331776

total fs tree bytes: 709705728

total extent tree bytes: 107560960

btree space waste bytes: 212508862

file data blocks allocated: 1332012232704

referenced 930064150528

After all of this, my Plex docker has stopped working. It's logs show the following:

PMS: failure detected. Read/write access is required for path: /config/Library/Application Support/Plex Media Server

Unraid version: 7.2.4

Thanks in advance!

phil-diagnostics-20260607-1608.zip

If you have a backup of the pool you can try the repair, but with btrfs, this is risky; if there are no backups, see if you can mount it read-only to create some first.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-543490

Thank you, JorgeB. I have successfully repaired the cache drive, and scrub is no longer reporting errors. However, the mover still refuses to move. It is still unhappy about these VM images on the cache.

MOVER LOG

Jun 8 08:22:50 phil move: mover: started

Jun 8 08:22:50 phil move: move: /mnt/cache/domains/Windows 10/2025-05-03--generate.running No such file or directory

Jun 8 08:22:50 phil move: move: /mnt/cache/domains/Windows 10/memory2025-05-03--generate.mem No such file or directory

Jun 8 08:22:50 phil move: move: /mnt/cache/domains/Windows 10/vdisk1.2025-05-03--generateqcow2 No such file or directory

Jun 8 08:22:50 phil move: move: /mnt/cache/domains/Windows 10/vdisk1.img No such file or directory

Jun 8 08:22:50 phil move: move: /mnt/cache/domains/Windows 10/2025-06-07--generate.running No such file or directory

Jun 8 08:22:50 phil move: move: /mnt/cache/domains/Windows 10/vdisk1.2025-06-07--generateqcow2 No such file or directory

Jun 8 08:22:50 phil move: move: /mnt/cache/domains/Ubuntu 24.04/2025-06-07--generate.running No such file or directory

Jun 8 08:22:50 phil move: mover: finished

NOTE: I was previously able to manually delete all of the Ubuntu VM files except the "--generate.running" one from the cache drive.

The system is configured such that the domains folder should not exist on the cache drive. So I am puzzled as to why these files are on the cache to start with.

Is it ok to simply delete these files now that the cache is not stuck in read-only mode? Alternatively, I am ok with simply removing and reinstalling these VMs if that will solve the problem.

12 minutes ago, rhodo said:

The system is configured such that the domains folder should not exist on the cache drive

Configuring it to be on the array won't move anything already on cache. But...

Better if Docker/VM related shares - appdata, domains, system - are all on cache or other pool, so Docker/VM will perform better, and so array disks can spin down since these files are always open. Nothing can move open files so you will have to disable Docker and VM Manager in Settings before these can be moved.

Marking this topic solved. I discovered that the reason the cache drive filled up is because I recently installed a docker that was dumping a bunch of video files on the cache. The mover problem had been a longstanding (but unrecognized) issue caused by misconfigured mover settings of the docker/VM folders (appdata, domains, system). In case this helps anyone with cache drive issues, below is what I did to resolve this situation.

STEP 1: CHECK --readonly

-- This confirmed the data corruption on the cache drive

-- This may have been caused by me attempting to manually delete files off the cache drive while it was in a self-imposed read-only state

-- I since learned that btrfs will put itself into a read-only state to prevent further data corruption

STEP 2: CREATE BACKUP OF CACHE DRIVE

-- mkdir /temp

-- mount -o rescue=all,ro /dev/sdX1 /temp (replace "X" with your drive letter)

STEP 3: TRY SCRUB

-- System in maintenance mode

-- btrfs scrub start -Bd /mnt/cache

-- Fails because file system is read-only

STEP 4: CHECK WITH REPAIR

-- Finds and repairs errors

-- Takes file system out of read-only mode

STEP 5: REBOOT

STEP 6: SCRUB

-- Confirms errors have been repaired and cache drive is now happy

STEP 7: CORRECTLY CONFIGURE OFFENDING DOCKER

-- The offending docker was p-streamrec. By default all its recording are placed in its appdata folder on the cache

-- Enable docker

-- Set data folder to reside on array

-- Disable docker

-- Use midnight commander to move its data off cache

STEP 8: CORRECTLY CONFIGURE MOVER SETTINGS

-- Set cache as primary and array as secondary for the appdata, domains and system folders

-- Run mover