Reyhn

Following that procedure was the solution for me. I ran the parity-check, which completed without any errors. Then I ran the SMART extended tests without any errors. I did not find any errors anywhere, which gave me the confidence to proceed with a rebuild: I stopped the array, unassigned the red-X:ed drive, started the array, checked the emulated contents, stopped the array, assigned the drive back and finally started the array once more. It's now rebuilding. Done in seven hours.

OK, so no lost+found is a good thing, then 🙂 I already tried that, but I stopped the array then restarted it in normal mode several times, but nothing changed. It did not mount successfully by itself.

Thanks a lot for that! Great thinking of the developers to easily download everything like that! A great plus for UNRAID! 🙂

Hi! I'm quite new to unRAID - I built my server last spring but haven't used it much. After a couple of power shortages, I noticed that one of my four disks has a red X and says "Device is disabled, content emulated". I have tried the following guides: https://wiki.unraid.net/Manual/Storage_Management#Checking_a_File_System https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui Doing the xfs_repair didn't yield very much. Here are the logs: xfs_repair -nv from the web GUI: Phase 1 - find and verify superblock... - block cache size set to 1507224 entries Phase 2 - using internal log - zero log... zero_log: head block 106467 tail block 106467 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 0 - agno = 3 - agno = 2 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Sat Feb 19 11:49:51 2022 Phase Start End Duration Phase 1: 02/19 11:49:45 02/19 11:49:45 Phase 2: 02/19 11:49:45 02/19 11:49:45 Phase 3: 02/19 11:49:45 02/19 11:49:48 3 seconds Phase 4: 02/19 11:49:48 02/19 11:49:48 Phase 5: Skipped Phase 6: 02/19 11:49:48 02/19 11:49:51 3 seconds Phase 7: 02/19 11:49:51 02/19 11:49:51 Total run time: 6 seconds xfs_repair -v from the web GUI: Phase 1 - find and verify superblock... - block cache size set to 1507224 entries Phase 2 - using internal log - zero log... zero_log: head block 106467 tail block 106467 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 2 - agno = 3 - agno = 0 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... XFS_REPAIR Summary Sat Feb 19 11:53:49 2022 Phase Start End Duration Phase 1: 02/19 11:53:42 02/19 11:53:43 1 second Phase 2: 02/19 11:53:43 02/19 11:53:43 Phase 3: 02/19 11:53:43 02/19 11:53:46 3 seconds Phase 4: 02/19 11:53:46 02/19 11:53:46 Phase 5: 02/19 11:53:46 02/19 11:53:46 Phase 6: 02/19 11:53:46 02/19 11:53:49 3 seconds Phase 7: 02/19 11:53:49 02/19 11:53:49 Total run time: 7 seconds done I don't see anything helpful here, except the mention of lost+found. But I cannot find any lost+found folder on the disk. Where is it supposed to be located? How can I find out what is wrong, so that I can fix it? Is the next step really redoing a drive formatted with XFS? Isn't there any other log or diagnostics to run? The disks were new when I pruchased them last year, and haven't been used much. I'd appreciate any help!

Hello! I'm not well versed in the world of Linux, so this might be a newbie question, but I can't figure out these access permissions... I am running Unraid v6.9.2 on a PC. On a Raspberry Pi 4, I am running Ubuntu 20.04.3. My desktop PC is running Windows 11. I want to copy files from the RPi to Unraid without passing Win11, but the user password is not accepted. I have tried the following from the originating RPi: scp test-file.txt test-user@Tower:/mnt/user/test-public SCP (I assume) is asking for the password of "test-user", but I get a "Permission denied". I just created the share "test-public" with both NFS and SMB set to export and public. I also just created the user "test-user" on Unraid with read/write access to that share. From my Win11 PC I have connected to Unraid via SSH using Tabby Terminal. I have also connected to the RPi the same way. So this is not the common "Windows share access"-issue, as I am not trying to access Unraid from Windows. But I don't see what I am doing wrong... 😞 On Unraid, the "/mnt/user/test-public" share looks like this: drwxrwxrwx 1 nobody users 6 Dec 14 07:43 test-public/ How can I find out what is wrong? ------ Edit: I forgot to mention that once I figure out what I'm doing wrong, I will not be using public shares. The share is intended to be "Secure" with only a specific user having write access to it. In the example above, I'm just using publich shares to demonstrate that not even the simples scenario that I expected to work works.