fireplex

Members
  • Posts

    194
  • Joined

  • Last visited

Everything posted by fireplex

  1. OK, I see 6.12.8 has just been released so will check that. I do not have the Parity Check Tuning plugin installed, so will have a look at that also. Thanks for the assistance.
  2. Ah that would explain it, thanks. I presume just need to wait for a new release for the bug fix?
  3. Hi, I have had prior warnings of parity errors for a couple of weeks now. Yesterday I replaced the parity drive with a larger drive, the parity rebuild finished this morning but I received a notification notice saying parity errors, this is from /boot/config/plugins/dynamix/notifications/archive (I cleared it from onscreen) :- -rw------- 1 root root 206 Feb 16 07:35 Unraid_Parity_Sync_1708068901.notify <---------------- this morning root@Tower:/boot/config/plugins/dynamix/notifications/archive# cat YD191511891GB cat: YD191511891GB: No such file or directory root@Tower:/boot/config/plugins/dynamix/notifications/archive# cat Unraid_Parity_Sync_1708068901.notify timestamp=1708068901 event=Unraid Parity-Sync subject=Notice [TOWER] - Parity-Sync finished (2591 errors) description=Duration: 18 hours, 33 minutes, 36 seconds. Average speed: 119.8 MB/s importance=normal So the above reports 2591 errors. However, my GUI shows: 0 errors reported. So, why the discrepancy between the notification I received and the GUI? Thanks!
  4. Hmm, that's a bit worrying. OK thanks for letting me know.
  5. Yes I saw that thread and the comment about is this something you installed. Hence my query on this thread, as I have not knowingly installed elogind...
  6. Hi, my server powered itself off in the middle of the night, no one near it. Is elogind-daemon part of the standard unRAID build please ? Jul 25 02:32:54 Tower emhttpd spinning down /dev/sdd Jul 25 03:01:11 Tower root /mnt/cache: 83.7 GiB (89874059264 bytes) trimmed Jul 25 03:04:06 Tower elogind-daemon Power key pressed. Jul 25 03:04:06 Tower elogind-daemon Powering Off... Jul 25 03:04:06 Tower elogind-daemon System is powering down.. Jul 25 03:04:06 Tower shutdown shutting down for system halt Jul 25 03:04:06 Tower init Switching to runlevel: 0 Jul 25 03:04:06 Tower flash_backup stop watching for file changes
  7. So I have a share that I used some time ago and I deleted all files within it, and on the GUI deleted the share. All is good until I reboot, then the empty share reappears again. I have checked my individual disks /mnt/diskX and it's not there, I am guessing there is some config file somewhere that has not been updated, any ideas how I can resolve this please? unRAID 6.12.3
  8. I'm not using docker exclusive IPs as far as I know? root@Tower:~# docker network list NETWORK ID NAME DRIVER SCOPE 76bd4672c776 br0 ipvlan local f16d1d53f08a bridge bridge local 9631fda6a856 host host local dbc961e617d5 none null local 51e76c81f980 proxynet bridge local 08dbbc14524f wg0 bridge local
  9. Hi, yes my unRAID server has a static IP address already. Would be nice to know what "features" the home router specifically needs to support ipvlan, I've had a dig around and can't find any specific feature/support that it needs? I am running OpenWRT on my router so it's pretty flexible.
  10. I found the fix to the 40 minute losing external connection issue on 6.12.0: I set "Host access to custom networks" to disabled and since then the network has been fine. I will install 6.12.1 anyway
  11. Could you elaborate on this at all, what specifics of ipvlan does the router need to support ? Thanks.
  12. Just done another reboot on unRAID, everything worked fine for a period of time then after approx. 40 minutes unRAID seems to lose external access.
  13. I can ping my router fine, and in fact Plex is still working. It *seems* to be just affecting unRAID:
  14. So, running with IPvlan and IPv4 networking for a bit and everything was fine. But now, unRAID seems to have lost access to external networks, eg: Here are some more logs if someone can look please? tower-diagnostics-20230619-0100.zip
  15. May be a slightly different issue from mine then, worthwhile starting your own thread with diagnostics
  16. OK, so think I figured this out. My unRAID networking was set to IPv4+IPv6 due to SMB related networking issues I had in the past. Changing the network type to IPv4 seems to fix this issue. I tried this due to a comment I saw about IPvlan use "Finally, auto-configured EUI-64 IPv6 type addresses are based on MAC type addresses. Therefore, all the Virtual Machines or containers that share the same parent interface, will auto generate the same IPv6 address. We advise the user to make sure that all the Virtual Machines or containers use static IPv6 addresses or IPv6 privacy addresses with SLAAC disabled." Whether the above is root cause I have no idea but IPv4 is working so far with IPvlan. Whether my SMB related network issues now return I will have to see....
  17. Hi, Just upgraded to 6.12 from 6.11.5 and noticed I was getting repeating kernel macvlan errors reported in syslog so changed docker network type to ipvlan as recommended. Note that apart from these kernel errors everything seemed OK and networking was OK at 6.12 prior to docker change. Changing docker to ipvlan results in unRAID being unable to check dockers or plugins for updates, under status it reports "not available". I also seem to lose remote access to my swag docker and Plex docker seems unable to resolve its IP. Diagnostics attached, any ideas please? Thanks! tower-diagnostics-20230618-2206.zip
  18. Just to follow up on the issue I had, in case it helps anyone, I realised that unRAID was being assigned IPv6 addresses by my router (even though I tried to disable it on my router). Changing the unRAID Network Settings from IPv4 to IPv4 + IPv6 fixed the intermittent connectivity issues I was having and I can access \\tower consistently every time now from all my PCs 😀
  19. Hi, I removed data disks 4 & 5 from my array and now the disks are numbered 1,2,3,6 and 7 as per below. Any issues if I stop the array and assign 6 and 7 to 4 & 5 respectively ? (I know, just hate seeing things like that 😆) ?
  20. Holy crap, didn't realise they could be this bad! Seriously, it's mad. Guess I got off luckily with my disk7 then. So you all believe it's definitely an SMR issue, and my diagnostics look OK?
  21. Well I've done several reboots and power cycles in trying to troubleshoot this, and whever I restart the transfer it just crawls along immediately. I just cannot see how I can possibly get my TBs of data back onto this disk at this rate 😢
  22. I don't believe that is the problem. Disk 7 is also an SMR drive and I had no issues writing data back to that. And I can't believe even SMR should be this slow (as reported by rsync): Films_My_Rips/HDTV/Interstellar/Interstellar (2014).mkv 2,473,164,800 6% 117.22kB/s 85:13:41
  23. Hoping someone can help here, tearing my hair out!! I have been converting my existing disks from resier to xfs, and all has been well. But I am having problems with just one disk (note this is NOT a new disk, it was just resierfs previously). Problem: During rsync writing data back to the disk I noticed it was crawling at kb/s write rate. What I have tried: 1. Removed parity disk to ensure not related to that 2. Tested copying same files using rsync to another drive, to rule out source drive <- get good data rate 3. Ran SMART extended diagnostics overnight <- no errors 4. Changed SATA cable and port being used on motherboard 5. Ran xfs_repair -n <- nothing reported Note, this disk, /dev/disk3, was fine previously, I have never noticed any issues. Also, the rsync had copied over 1TB data to this disk at a reasonable speed of around 30MB/s prior to it slowing down. During a reboot, while mounting disks, it will hang on this disk for a period of time (unlike my other disks which mount instantly): Jan 6 09:59:31 Tower emhttpd: shcmd (10190): mkdir -p /mnt/disk3 Jan 6 09:59:31 Tower emhttpd: shcmd (10191): mount -t xfs -o noatime,nouuid /dev/md3 /mnt/disk3 Jan 6 09:59:31 Tower kernel: XFS (md3): Mounting V5 Filesystem Jan 6 10:01:50 Tower kernel: XFS (md3): Ending clean mount Jan 6 10:01:50 Tower emhttpd: shcmd (10192): xfs_growfs /mnt/disk3 Jan 6 10:01:50 Tower root: meta-data=/dev/md3 isize=512 agcount=6, agsize=268435455 blks Jan 6 10:01:50 Tower root: = sectsz=512 attr=2, projid32bit=1 Jan 6 10:01:50 Tower root: = crc=1 finobt=1, sparse=1, rmapbt=0 Jan 6 10:01:50 Tower root: = reflink=1 bigtime=1 inobtcount=1 Jan 6 10:01:50 Tower root: data = bsize=4096 blocks=1465130633, imaxpct=5 Jan 6 10:01:50 Tower root: = sunit=0 swidth=0 blks Jan 6 10:01:50 Tower root: naming =version 2 bsize=4096 ascii-ci=0, ftype=1 Jan 6 10:01:50 Tower root: log =internal log bsize=4096 blocks=521728, version=2 Jan 6 10:01:50 Tower root: = sectsz=512 sunit=0 blks, lazy-count=1 Jan 6 10:01:50 Tower root: realtime =none extsz=4096 blocks=0, rtextents=0 At this stage, I can only think this is an xfs filesystem related issue.... Any ideas guys ? tower-diagnostics-20230106-1035.zip tower-smart-20230106-0957.zip
  24. Yes, I have unRAID running 24x7 and its the Local Master (according to Dynix plugin). I'll have a look but I'm a little hesitant to start chaning things on all my PCs when they used to work fine.