kahunamike

Appreciate the effort in putting this together. Spent an evening trying to migrate to the 2-docker linuxserver version and gave up. This was really straightforward. Used 8.0.24 (11notes/unifi:8.0.24-unraid) since that's what I was previously on and what the backup was built with. Only (known) issue I ran into was on Restore which appeared to hang. Restarted the container, logged in and everything looks great.

Thanks so much @JorgeB! Was worried I'd have to restore from backup. Have a great rest of your day!

Yay! Mounted successfully. The lost+found folder would be in the root of the drive right? In my case: /mnt/disk1? If so, I don't see any lost+found folder in there.

Not sure if this is good or bad.... Is it just try to start the array normally now? 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... clearing needsrepair flag and regenerating metadata sb_fdblocks 488961967, counted 490185727 - 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 inode 5221924220 - bad extent starting block number 4503567550832887, offset 0 correcting nextents for inode 5221924220 bad data fork in inode 5221924220 cleared inode 5221924220 - agno = 3 - agno = 4 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 3 - agno = 1 - agno = 4 - agno = 2 entry "IMG_2660.JPG" at block 1 offset 3136 in directory inode 5221034101 references free inode 5221924220 clearing inode number in entry at offset 3136... 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 5221034101 (no data entry): rebuilding rebuilding directory inode 5221034101 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (39:3996936) is ahead of log (1:2). Format log to cycle 42. done

Thanks @JorgeB. I'm getting this. Maybe because I ran the above already? Should I go ahead and run it with "-L"? Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.

I recently found one of my drives as "Unmountable: Unsupported or no file system". From directions in the forums, I ran: "xfs_repair -v /dev/sdd" from the console It gave me the error: "Sorry, could not find valid secondary superblock Exiting now." The drive still is unmountable. Any other ideas on bringing this drive back? I see instructions on looking for a lost+found folder but I don't see that anywhere. The drive never appears in Unassigned Devices with the array stopped or in maintenance mode. With the array started, I don't see the folder in /mnt/user

Came across this thread as I was also looking to up the pool size. I think what you are looking for is in the /config directory of the MariaDB docker. There is a custom.cnf file that you can edit and has the InnoDB parameters in it like: innodb_buffer_pool_size = 2048M

Thanks @thestickhughes! That worked for me too. After upgrading Unraid to 6.5, Xeoma wouldn't start up anymore. Modified the Xeoma.conf file down to 17.8.31 and back up to 17.11.24 seemed to do the trick.