djuniah

Apologies for the very late reply! I didn't get a notification email (I need to check the settings on this forum). The media folder did exist and the correct perms were there. It was working fine for a while and then just stopped one day. I did get it working again, however that was over a month ago and I don't exactly remember what I did to get it going again (I hate that I've now authored one of "those" posts). I want to say that maybe it was related to a change in the docker network settings (this was around the time that there were issues with macvlan with an unraid update). I currently have ipvlan in the docker settings.

Seeing this exact same issue. Did you ever get it resolved? I even tried completely deleting the container/appdata and i'm still getting the issue.

Sorry, just realized that I never followed up to this. In my original post i mentioned that "The display on the monitor doesn't show any errors and I can't seem to enter anything there with the keyboard." So doing it directly at the machine was no help. I ended up just crossing my fingers and hard rebooting the machine as I couldn't see any other way to get at it.

Right but i can't get to the webUI, SSH, or the terminal at the moment. Is there some other way that I could do that?

My server seems to have gotten itself into an odd state. All of my network shares are working and running at full speed, all of my services running in docker containers are also completely functional. The webUI and SSH however are not working correctly. The WebUI just doesn't load and when I SSH I get a login prompt that does function, but once i enter my password, it shows the "last login was X" messages and then never shows a prompt. The display on the monitor doesn't show any errors and I can't seem to enter anything there with the keyboard. I tried just tapping the power button and it did say that it was sending processes the kill command, but that was over an hour ago and all of my services are still accessible/running. At this point i'm not sure what other options I have besides a hard kill and I really don't want to do that. Does anyone have any other suggestions that I can try? EDIT: Just wanted to note that this isn't related to some config issue with another docker container trying to take port 80. Nothing has changed in the past 48+ hours and this just happened out of nowhere. Doesn't seem performance related as my other containers seem to be running fine (although i don't know for sure since i can't get to the webUI or terminal to run htop/top) EDIT2: If i leave the webUI loading, after a very long time, nginx eventually returns a 500 error.

Sorry for the double post but it also looks like the registration domain is having DNS issues as well. Just went to update my USB drive and now i can't register the new one

Awesome thank you! Was just able to grab it.

Thank you! Would it be possible to have the tool posted to the forum in the meantime?

Just tried to grab the latest version of the USB download tool and it's giving a DNS error on the craftassets.unraid.net domain.

Thanks for the advice. I do have a ups but it's runtime is around 45 minutes and they're replacing a transformer so it'll be much longer than that. They've done a few others in the area this week and they took from 8am to 6pm. I ended up just cancelling and shutting down.

So, i'm several hours into a drive rebuild (old drive was showing errors, and i put in a replacement), and i just got a call from my power company that they need to cut power to my house in about 12 hours to replace a transformer. The rebuild has about 14 hours left. Any suggestions on what I should do here? I have the old drive still in the box, so i assume the safe answer is to swap back to that one and then shut down until power is restored, then start the rebuild all over again. I also see that there is a "pause" button in the parity sync/rebuild section, is there a way to pause it, shut down, and then resume it later? Any other general thoughts/suggestions?

Ok thanks for the help/quick replies! Truly appreciated.

Ah thanks! Didn't realize that. In the Lost+Found dir i'm seeing about 32 files who's names are just "20454, 20455, 20457,....etc" (basically the disconnected inode names from my previous post) and they are of varying sizes from 1kb to 750kb outside of looking at the file contents directly and hoping to find header info, do you have any suggestions on how to figure out what they might be?

Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... sb_ifree 760, counted 672 sb_fdblocks 832117916, counted 833084897 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 Metadata CRC error detected at 0x417105, xfs_dir3_block block 0x4fd8/0x1000 bad directory block magic # 0x74760a33 in block 0 for directory inode 20449 corrupt block 0 in directory inode 20449 will junk block no . entry for directory 20449 no .. entry for directory 20449 problem with directory contents in inode 20449 cleared inode 20449 - 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 = 0 - agno = 1 - agno = 2 - agno = 3 entry "__ADMIN__" at block 0 offset 96 in directory inode 6442552432 references free inode 20449 clearing inode number in entry at offset 96... Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... bad hash table for directory inode 6442552432 (no data entry): rebuilding rebuilding directory inode 6442552432 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 20454, moving to lost+found disconnected inode 20455, moving to lost+found disconnected inode 20457, moving to lost+found disconnected inode 20459, moving to lost+found disconnected inode 20460, moving to lost+found disconnected inode 20461, moving to lost+found disconnected inode 20465, moving to lost+found disconnected inode 20466, moving to lost+found disconnected inode 20467, moving to lost+found After that I stopped the array, then restarted it in maintenance mode and i'm still seeing a "No Filesystem" error. Any thoughts on why that may still be?

It appears as though i have some filesystem corruption. I've checked my SMART values and everything seems normal there so i'm thinking it's not a hardware related issue. This all started with an "Unmountable: No file system" message after a bad shutdown (power loss i believe). After starting the array in maintenance mode and running "xfs_repair -v /dev/md3" I get a "filesystem has valuable metadata changes in a log which needs to be replayed." message. Which it then suggests either mounting the filesystem to replay the log, or re-running with -L to clear the log and repair. I have a few questions: - Does starting the array in maintenance mode count as trying to mount it? I assume with unraid that i shouldn't be manually trying to mount any /dev/md# devices right? - Would it be safer to just shut down, pull the drive, wipe it, and then have unraid use parity to rebuild it? Or should I attempt the repair? If i do attempt the repair, would that affect parity at all?