cantharides999

I've ran the check -n option (from management interface) resulting in the following: 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 ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... Metadata CRC error detected at 0x46b78d, xfs_inobt block 0xaea86678/0x1000 btree block 3/3 is suspect, error -74 bad magic # 0 in inobt block 3/3 sb_ifree 143, counted 140 sb_fdblocks 2394544389, counted 2411574121 - 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 data fork in ino 2149391519 claims free block 287002959 data fork in ino 2149391519 claims free block 295665266 data fork in ino 2149391519 claims free block 297755762 imap claims a free inode 2149391520 is in use, would correct imap and clear inode - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - 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 entry "Clockwise.srt" in shortform directory 2149391518 references free inode 2149391520 would have junked entry "Clockwise.srt" in directory inode 2149391518 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 8 - agno = 7 - agno = 11 - agno = 0 - agno = 10 - agno = 9 - agno = 13 - agno = 14 - agno = 15 - agno = 12 - agno = 17 - agno = 16 - agno = 19 - agno = 18 No modify flag set, skipping phase 5 Inode allocation btrees are too corrupted, skipping phases 6 and 7 No modify flag set, skipping filesystem flush and exiting. I thought aftrewards I should run check without (-n) option but this results in: 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. Don't know exactly how to proceed to get the filesystem fixed. Alternatively I'm thinking of moving the data of the disk and reformatting the disk in XFS.

Recently added "replaced" a disk in my array and a strange phenomenon occurs; After writing data to the disk, the disk seems to "disappear". Accessing it directly through MC or through" samba, the disk appears unavailable. As such no data can be written anymore. Reboot of the system resolves the issue, until the disk is written to again. Read checks, smart checks do not reveal any errors, it appears as if the disk "unmounts", although in array config it still accessible. Accessing it through unraid management console results in screen below (stiil mounted in array). Anyone any thoughts ? Log registers following error: Sep 28 11:41:49 Tower kernel: XFS (md3): metadata I/O error in "xfs_btree_read_buf_block.constprop.0+0x75/0xc1 [xfs]" at daddr 0xaea86678 len 8 error 74 Sep 28 11:41:49 Tower kernel: XFS (md3): xfs_do_force_shutdown(0x1) called from line 296 of file fs/xfs/xfs_trans_buf.c. Return address = 00000000c3fe9b6d Sep 28 11:41:49 Tower kernel: XFS (md3): I/O Error Detected. Shutting down filesystem Sep 28 11:41:49 Tower kernel: XFS (md3): Please unmount the filesystem and rectify the problem(s) Anyone now how to resolve ?

Today I ran into a similar issue --> connection refused to webui, while two weeks ago worked flawlessly. Tried force updating etc, without succes. Then I remenbered there were some updates on the NORDVPN software side this week. I checked the servers allowing for openVPN connection, and the server I was using before wasn't in the list anymore. Installed a new openvpn config file (to another server) and docker container runs fine. again. Issue was on the side of NORDVPN in my case.

I'm kinda noob inregard to docker and mariadb, but could anyone explain to me briefly what these values mean/represent when setting up the mariadb docker: container value PUID 99 container value PUIG 100

Thats what I did now, but now the system doesn't recognize my license key. Forget what I said. Copied the wrong file to the wrong place. Everything seems to be working real fine now. Thx for your help.

I've followed the procedure today on my unraid 5.05 config,but it doesn't seem to work. I get a problem with the vallidation of the certificate. In short this is the error message I get after using the wget cmd.: 'WARNING cannot verify raw.githubusercontent.com certificate and afterwards I get a HTTP 400 bad request.'" The manual download of the unRAISserver.plg didn't help either. Rebooting the server doesn't result in downloading unraid v6. ??