JorgeB

Post output of: btrfs fi usage -T /x Create a new share called e.g. backup and then copy from /x to /mnt/user/backup

That looks like a permissions issue, run newperms on those shares.

Do you have some?

Settings -> Docker and Settings -> VM manager (some options will only show with advance view enable)

You're likely moving a lot of small files, mover is not efficient for that, better off moving manually.

Yep.

Parity2 appears to be failing, run an extended SMART text to confirm. May 31 10:35:32 godzilla kernel: ata4.00: exception Emask 0x0 SAct 0x1ff80 SErr 0x0 action 0x0 May 31 10:35:32 godzilla kernel: ata4.00: irq_stat 0x40000008 May 31 10:35:32 godzilla kernel: ata4.00: failed command: READ FPDMA QUEUED May 31 10:35:32 godzilla kernel: ata4.00: cmd 60/00:38:e0:d3:67/04:00:08:00:00/40 tag 7 ncq dma 524288 in May 31 10:35:32 godzilla kernel: res 41/40:00:90:d6:67/00:00:08:00:00/00 Emask 0x409 (media error) <F> May 31 10:35:32 godzilla kernel: ata4.00: status: { DRDY ERR } May 31 10:35:32 godzilla kernel: ata4.00: error: { UNC } May 31 10:35:32 godzilla kernel: ata4.00: configured for UDMA/133 May 31 10:35:32 godzilla kernel: sd 5:0:0:0: [sdm] tag#7 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 May 31 10:35:32 godzilla kernel: sd 5:0:0:0: [sdm] tag#7 Sense Key : 0x3 [current] May 31 10:35:32 godzilla kernel: sd 5:0:0:0: [sdm] tag#7 ASC=0x11 ASCQ=0x4 May 31 10:35:32 godzilla kernel: sd 5:0:0:0: [sdm] tag#7 CDB: opcode=0x88 88 00 00 00 00 00 08 67 d3 e0 00 00 04 00 00 00 May 31 10:35:32 godzilla kernel: print_req_error: I/O error, dev sdm, sector 141022864 May 31 10:35:32 godzilla kernel: md: disk29 read error, sector=141022800 May 31 10:35:32 godzilla kernel: md: disk29 read error, sector=141022808 May 31 10:35:32 godzilla kernel: md: disk29 read error, sector=141022816 May 31 10:35:32 godzilla kernel: md: disk29 read error, sector=141022824 May 31 10:35:32 godzilla kernel: md: disk29 read error, sector=141022832 May 31 10:35:32 godzilla kernel: md: disk29 read error, sector=141022840 May 31 10:35:32 godzilla kernel: md: disk29 read error, sector=141022848 May 31 10:35:32 godzilla kernel: md: disk29 read error, sector=141022856

Based on the transaction id both the docker and libvirt images are fairly new, Unraid recreates them at array start if it previous ones are missing, this can happen if they were deleted or most frequently if the device where they were is missing or unmountable, to avoid the latter you should use the disk path in the settings, not the user path, so this doesn't happen, so e.g. for the docker set it to /mnt/cache/system/docker.img instead of /mnt/user/system/docker.img Also note that old images might still exist on the array, the system share has files both on the array and cache.

USB drives are not recommended both for performance and reliability. I'm sorry but I don't even want to try troubleshooting bad performance with USB drives, it would be mostly a waste of time.

Noting jumping out on the logs regarding shares, try redoing the flash drive, backup current one, re-do it, restore only super.dat and the key, both on the config folder, then check is shares are available and if not post new diags.

Please post the diagnostics: Tools -> Diagnostics

Changed Status to Closed Changed Priority to Other

This is a general support issue, also logs are lost after a reboot so enable the syslog server/mirror feature and if/when it happens again please start a thread in the general support forum and attach the diags plus the saved syslog. Good idea to also try safe mode to rule out any plugins.

This is an Unraid support forum, not general Linux.

Those look like an actual disk problem, though an intermittent one, you should keep an eye on that disk. Also not recommended to run a correcting check unless sync errors (not disk errors) are expected, and you should never run one when disk errors are expected.

Currently btrfs can correctly report the free space when using different size devices, it's just the GUI that isn't doing it, but it should be fixed soon on an upcoming release.

Start here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

Logs are spammed with these: May 30 13:13:21 Tower vsftpd[26984]: connect from 192.168.16.137 (192.168.16.137) May 30 13:13:32 Tower vsftpd[27206]: connect from 192.168.16.137 (192.168.16.137) May 30 13:13:42 Tower vsftpd[27680]: connect from 192.168.16.137 (192.168.16.137) Makes it very difficult to find anything else, see if you can fix it for a future issue, to re-enable the drives see here (you can do both at the same time): https://wiki.unraid.net/Troubleshooting#Re-enable_the_drive

Nothing jumps out in the log, try rebooting.

Since it's a single device pool it can't fix data corruption but you can find out which files are corrupt by running a scrub, they will be identified in the syslog, then delete or replace them.

Lots of call traces, including in the Unraid driver, this could point to some hardware issue, run memtest, also look for a BIOS update. There is also constant log spam like this: May 30 12:46:30 EDINBURGH kernel: pcieport 0000:00:01.3: AER: Corrected error received: 0000:00:01.3 May 30 12:46:30 EDINBURGH kernel: pcieport 0000:00:01.3: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID) May 30 12:46:30 EDINBURGH kernel: pcieport 0000:00:01.3: device [1022:1483] error status/mask=00000040/00006000 May 30 12:46:30 EDINBURGH kernel: pcieport 0000:00:01.3: [ 6] BadTLP May 30 12:46:48 EDINBURGH kernel: pcieport 0000:00:01.3: AER: Corrected error received: 0000:00:01.3 May 30 12:46:48 EDINBURGH kernel: pcieport 0000:00:01.3: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID) May 30 12:46:48 EDINBURGH kernel: pcieport 0000:00:01.3: device [1022:1483] error status/mask=00000040/00006000 May 30 12:46:48 EDINBURGH kernel: pcieport 0000:00:01.3: [ 6] BadTLP See if this helps.

Both the docker and libvirt images are corrupt and need to be recreated (libvirt should be restored from a backup if available), corruption was likely the result of one of your cache devices (cache2) dropping offline in the past: May 30 14:09:04 GamingNas kernel: BTRFS info (device sdb1): bdev /dev/sdg1 errs: wr 59211818, rd 45027162, flush 401384, corrupt 0, gen 0 See here for more info.

If the filesystem check/repair is done correctly (using the GUI or CLI) parity will be updated and kept in sync.

Like mentioned you should try the command on both devices (and both should always be connected), please post a screenshot of terminal (including the commands) after typing these commands, I find it odd that none of them worked: mkdir /x mount -o degraded,usebackuproot,ro /dev/sdc1 /x Assuming device letters are the same as the screenshot if not make the appropriate correction.

Should be fine as long as support by your hardware, the adapter is transparent to the OS.