phillipppp

I would like to see some improvements to the UI for this, but there IS currently a simpler way than you mentioned: 1. Edit the container 2. Enable “Advanced View” 3. Add the following to “Post Arguments” (replacing the appropriate values): ``` && docker network connect <your network name> <your container name> ``` This will persist across updates.

While still unresolved, I've got a thread going with the xfs distro. There may be more information there in case someone comes across a similar problem in the future and finds this topic. https://lkml.kernel.org/linux-xfs/CACf8WVuHtDoJS1x5XzvBV99Z6Gp7bqbwDT4QsKsJrETtyyvFTg@mail.gmail.com/

Okay thanks, was curious if rebuilding could be avoided. Fingers crossed it goes smooth.

I was able to get an image of the drive and mounted in an Ubuntu box booted on a USB. UFS was able to identify all the files on the drive in the same structure as my shares. What’s the best way to replace the disk without rebuilding the back without carrying the bad filesystem?

Is it normal to keep disk-level backups and not data/share-based backups?

I first ran from the web ui with `-n` and once it reported issues, I re-ran without the `-n`. I can provide the full output if it would help but it is quite large.

So, the only next steps are to wait for a newer version of unraid or restore the entire array from a backup? I was under the impression that, with my configuration, the array would be protected from loss of a single drive. I even keep a hot spare in the chassis for this. Are there no other options?

Alright. I am on 6.12.6. Would there be any newer version? Should I replace the drive with a new one instead of formatting?

Thanks @JorgeB . Unfortunately, I have tried multiple times all with the same result. Would formatting the drive and doing a rebuild return the array to normal operation?

Had a power outage recently and had issues with Docker starting and killing all shares. After some looking around, I ran the `xfs_repair` on Disk 1 in my array and it reported issues. I re-ran without `-n` and cannot make it past the following: ... Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... rebuilding directory inode 12955326179 Metadata corruption detected at 0x46fa05, inode 0x38983bd88 dinode fatal error -- couldn't map inode 15192014216, err = 117 Starting the array outside maintenance mode now shows the disk with: Unmountable: Unsupported or no file system I am almost to the point of formatting the drive and rebuilding in place but want to check if there are any other options to try first. Diagnostics attached. tower-diagnostics-20231214-2011.zip