RedXon

I'm having some problems with loading my files in the WebUI. It works fine with the Desktop Client and even works fine with the iOS app on my phone, but not in the WebUI, even when using different browsers and different PCs. I just get a spinning loading wheel indefinitely and in the browser console this is visible, does anyone know what this could be? Maybe a DB or Webserver issue? I'm on the latest container and the latest version (10.11)

Yeah, I have followed pretty much this guide. At the moment I have a IPSEC Site to Site VPN running between these Sites, but I am hoping for better performance when using Wireguard (IPSEC maxes out at about 35mbit/s in this particular hardware). Of course I have shut down the IPSEC VPN before setting up the Wireguard VPN to avoid problems with these. It was quite the ride as I was using jumphosts on either site to have access to the configurations. As I said, I am not sure if the issue lies with unraid or with the routers itself. If it helps, here are the configs (redacted a bit)... Config on unraid 1 [Interface] #Site2Site PrivateKey=redacted Address=10.253.0.1 ListenPort=51821 PostUp=logger -t wireguard 'Tunnel WireGuard-wg0 started' PostUp=iptables -t nat -A POSTROUTING -s 10.253.0.0/24 -o br0 -j MASQUERADE PostDown=logger -t wireguard 'Tunnel WireGuard-wg0 stopped' PostDown=iptables -t nat -D POSTROUTING -s 10.253.0.0/24 -o br0 -j MASQUERADE PostUp=ip -4 route flush table 200 PostUp=ip -4 route add default via 10.253.0.1 table 200 PostUp=ip -4 route add 192.168.0.0/24 via 192.168.0.1 table 200 PostDown=ip -4 route flush table 200 PostDown=ip -4 route add unreachable default table 200 PostDown=ip -4 route add 192.168.0.0/24 via 192.168.0.1 table 200 [Peer] #Unraid2 PublicKey=redacted PresharedKey=redacted Endpoint=redacted.tld:51822 AllowedIPs=10.253.0.0/24, 192.168.1.0/24 Config on unraid 2: [Interface] #Site2Site PrivateKey=redacted Address=10.253.0.2 ListenPort=51822 PostUp=logger -t wireguard 'Tunnel WireGuard-wg0 started' PostUp=iptables -t nat -A POSTROUTING -s 10.253.0.0/24 -o br0 -j MASQUERADE PostDown=logger -t wireguard 'Tunnel WireGuard-wg0 stopped' PostDown=iptables -t nat -D POSTROUTING -s 10.253.0.0/24 -o br0 -j MASQUERADE PostUp=ip -4 route flush table 200 PostUp=ip -4 route add default via 10.253.0.2 table 200 PostUp=ip -4 route add 192.168.1.0/24 via 192.168.1.1 table 200 PostDown=ip -4 route flush table 200 PostDown=ip -4 route add unreachable default table 200 PostDown=ip -4 route add 192.168.1.0/24 via 192.168.1.1 table 200 [Peer] #Unraid 1 PublicKey=redacted PresharedKey=redacted Endpoint=redacted.tld:51821 AllowedIPs=10.253.0.0/24, 192.168.0.0/24 Thanks for any input!

I am sure that I am doing something completely stupid and there is an easy fix, but after some hours of troubleshooting I'd rather ask here for a change: So, I am trying to set up site to site VPN with unRaid. And for some reason it works only from and to the servers but not beyond, could be a routing issue, could be firewall but I don't get what exactly is blocking what. To make it quick: Network1: 192.168.0.0/24, Network2: 192.168.1.0/24 Unraid1: 192.168.0.2, Unraid2: 192.168.1.2 So what works is: Connecting from one unRaid server to the other unraid Server and vice versa Connecting and pinging from unraid 2 server to any client on network 1 Connecting and pinging from unraid 1 server to any client on network 2 Connecting and pinging from any client on network 1 to unraid 2 Pinging the tunnel address of unraid 1 from any client on network 2 Pinging the tunnel address of unraid 2 from any client on network 1 What doesn't work: Pinging from any client other than unraid 2 on network 2 to anything on network 1 Pinging from any client on network 1 to any client on network 2 other than unraid 2 So I hope it is understandable. Basically I cannot get to network 1 from network 2 beyond unraid 2, as if the server is blocking it somehow. I have set up routing and the rest exactly like in the tutorial. Any Ideas?

Hi I have this weird issue where unraid reports that my log is full and also that my /var/log directory or mountpoint is getting full but when I check in there, there are no large files, there is nothing which would make it full. What can this be? I am at a loss of ideas because this sometimes freezes my system as well. Here are my findings. I also checked all the subfolders. root@Azeroth:/var/log# tree -s . ├── [ 0] btmp ├── [ 0] cron ├── [ 0] debug ├── [ 0] faillog ├── [ 0] lastlog ├── [ 120] libvirt │ ├── [ 378] libvirtd.log │ ├── [ 40] qemu │ ├── [ 0] virtlockd.log │ └── [ 0] virtlogd.log ├── [ 0] mcelog ├── [ 0] messages ├── [ 40] nfsd ├── [ 60] nginx │ └── [ 3438] error.log ├── [ 24] packages -> ../lib/pkgtools/packages ├── [ 100] pkgtools │ ├── [ 240] removed_packages │ │ ├── [ 1198] atop-2.2-x86_64-2 │ │ ├── [ 2338] community.applications-2022.03.13-x86_64-1-upgraded-2022-03-18,09:08:57 │ │ ├── [ 2414] community.applications-2022.03.17a-x86_64-1-upgraded-2022-03-23,14:52:02 │ │ ├── [ 2414] community.applications-2022.03.22a-x86_64-1-upgraded-2022-05-11,14:43:13 │ │ ├── [ 952] dynamix.file.manager-upgraded-2022-03-21,10:52:39 │ │ ├── [ 0] dynamix.file.manager-upgraded-2022-03-29,16:27:48 │ │ ├── [ 1713] dynamix.unraid.net │ │ ├── [ 2668] fix.common.problems-2022.03.13-x86_64-1-upgraded-2022-03-21,10:52:41 │ │ ├── [ 0] fix.common.problems-2022.03.18-x86_64-1-upgraded-2022-03-29,16:27:46 │ │ └── [ 2668] fix.common.problems-2022.03.29-x86_64-1-upgraded-2022-05-11,14:43:11 │ ├── [ 60] removed_scripts │ │ └── [ 829] atop-2.2-x86_64-2 │ └── [ 40] removed_uninstall_scripts ├── [ 580] plugins │ ├── [ 33] NerdPack.plg -> /boot/config/plugins/NerdPack.plg │ ├── [ 35] ca.backup2.plg -> /boot/config/plugins/ca.backup2.plg │ ├── [ 47] ca.update.applications.plg -> /boot/config/plugins/ca.update.applications.plg │ ├── [ 47] community.applications.plg -> /boot/config/plugins/community.applications.plg │ ├── [ 35] dvb-driver.plg -> /boot/config/plugins/dvb-driver.plg │ ├── [ 47] dynamix.active.streams.plg -> /boot/config/plugins/dynamix.active.streams.plg │ ├── [ 43] dynamix.cache.dirs.plg -> /boot/config/plugins/dynamix.cache.dirs.plg │ ├── [ 45] dynamix.file.manager.plg -> /boot/config/plugins/dynamix.file.manager.plg │ ├── [ 42] dynamix.schedules.plg -> /boot/config/plugins/dynamix.schedules.plg │ ├── [ 41] dynamix.ssd.trim.plg -> /boot/config/plugins/dynamix.ssd.trim.plg │ ├── [ 44] dynamix.system.info.plg -> /boot/config/plugins/dynamix.system.info.plg │ ├── [ 45] dynamix.system.stats.plg -> /boot/config/plugins/dynamix.system.stats.plg │ ├── [ 44] dynamix.system.temp.plg -> /boot/config/plugins/dynamix.system.temp.plg │ ├── [ 43] dynamix.unraid.net.plg -> /boot/config/plugins/dynamix.unraid.net.plg │ ├── [ 38] file.activity.plg -> /boot/config/plugins/file.activity.plg │ ├── [ 44] fix.common.problems.plg -> /boot/config/plugins/fix.common.problems.plg │ ├── [ 37] networkstats.plg -> /boot/config/plugins/networkstats.plg │ ├── [ 38] nvidia-driver.plg -> /boot/config/plugins/nvidia-driver.plg │ ├── [ 35] open.files.plg -> /boot/config/plugins/open.files.plg │ ├── [ 36] plexstreams.plg -> /boot/config/plugins/plexstreams.plg │ ├── [ 31] rclone.plg -> /boot/config/plugins/rclone.plg │ ├── [ 40] tips.and.tweaks.plg -> /boot/config/plugins/tips.and.tweaks.plg │ ├── [ 55] unRAIDServer.plg -> /usr/local/emhttp/plugins/unRAIDServer/unRAIDServer.plg │ ├── [ 48] unassigned.devices-plus.plg -> /boot/config/plugins/unassigned.devices-plus.plg │ ├── [ 43] unassigned.devices.plg -> /boot/config/plugins/unassigned.devices.plg │ ├── [ 34] unbalance.plg -> /boot/config/plugins/unbalance.plg │ └── [ 37] user.scripts.plg -> /boot/config/plugins/user.scripts.plg ├── [ 40] pwfail ├── [ 25] removed_packages -> pkgtools/removed_packages ├── [ 24] removed_scripts -> pkgtools/removed_scripts ├── [ 34] removed_uninstall_scripts -> pkgtools/removed_uninstall_scripts ├── [ 160] samba │ ├── [ 100] cores │ │ ├── [ 40] nmbd │ │ ├── [ 40] smbd │ │ └── [ 40] winbindd │ ├── [ 5556] log.nmbd │ ├── [ 1602] log.smbd │ ├── [ 680] log.wb-AZEROTH │ ├── [ 2822] log.winbindd │ └── [ 680] log.winbindd-idmap ├── [ 23] scripts -> ../lib/pkgtools/scripts ├── [ 0] secure ├── [ 21] setup -> ../lib/pkgtools/setup ├── [ 0] spooler ├── [ 60] swtpm │ └── [ 60] libvirt │ └── [ 40] qemu ├── [ 60] unraid-api │ └── [ 0] stderr.log ├── [ 0] vfio-pci └── [ 7296] wtmp 25 directories, 59 files Also my df -h command root@Azeroth:/var/log# df -h Filesystem Size Used Avail Use% Mounted on rootfs 16G 9.2G 6.5G 59% / tmpfs 32M 2.9M 30M 9% /run /dev/sda1 15G 1.3G 14G 9% /boot overlay 16G 9.2G 6.5G 59% /lib/firmware overlay 16G 9.2G 6.5G 59% /lib/modules devtmpfs 8.0M 0 8.0M 0% /dev tmpfs 16G 0 16G 0% /dev/shm cgroup_root 8.0M 0 8.0M 0% /sys/fs/cgroup tmpfs 384M 384M 8.0K 100% /var/log tmpfs 1.0M 0 1.0M 0% /mnt/disks tmpfs 1.0M 0 1.0M 0% /mnt/remotes tmpfs 1.0M 0 1.0M 0% /mnt/rootshare /dev/md1 7.3T 6.9T 465G 94% /mnt/disk1 /dev/md2 7.3T 6.5T 845G 89% /mnt/disk2 /dev/md3 7.3T 6.4T 924G 88% /mnt/disk3 /dev/md4 3.7T 2.8T 932G 75% /mnt/disk4 /dev/md5 3.7T 3.1T 649G 83% /mnt/disk5 /dev/md6 3.7T 2.8T 932G 75% /mnt/disk6 /dev/md7 7.3T 6.6T 788G 90% /mnt/disk7 /dev/md8 3.7T 2.8T 918G 76% /mnt/disk8 /dev/md9 3.7T 2.8T 878G 77% /mnt/disk9 /dev/md10 7.3T 6.4T 935G 88% /mnt/disk10 /dev/sdc1 1.2T 887G 223G 80% /mnt/cache shfs 55T 47T 8.1T 86% /mnt/user0 shfs 55T 47T 8.1T 86% /mnt/user /dev/loop2 80G 20G 59G 25% /var/lib/docker /dev/loop3 1.0G 4.4M 904M 1% /etc/libvirt tmpfs 3.2G 0 3.2G 0% /run/user/0 Does anyone have any idea why that could be the case? If it matters, I have a syslog server to which the syslog is getting transmitted but all it's receiving is: Azeroth rsyslogd: file '/var/log/syslog'[5] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2102.0 try https://www.rsyslog.com/e/2027 ] Local Syslog server as well as mirror to flash is disabled. Also, as you might see in the diagnostics, CPU and RAM is pinned at 100% at the moment but TOP or HTOP isn't reflecting that. Diagnostics as follows: azeroth-diagnostics-20220531-1647.zip

EDIT: Nevermind, I got it solved... turned out one of my users had a very very large folder with many very very little files in his shared owncloud folder. This was causing very high CPU as owncloud was constantly trying to scan that folder but never got very far because it always changed. I moved the folder out and told him not to do that again and CPU is back to normal again... I tried to Pin and not Pin. If I pin I get high load just on the pinned ports obviously but if I don't pin I get high load on all the ports. Let me give you some examples: This is CPU load in system. Normally when running like this it was about 10-15% load. When I stop owncloud it goes down to that, once owncloud is running CPU load is always at about 75%. Htop in unRaid gives me this: Now, of course it could be that the SHFS load in there is not from ownCloud but it stops as soon as I stop the container so something weird is going on. Also, this is what TOP looks inside of ownCloud. With this on my docker overview: But yeah, seems like a weird problem to have. Thank you so much for looking at it tough! I love this container and would love to get it working flawless again.

Hi So what I noticed recently is that PHP-FPM uses a lot of CPU on my server, so much in fact that it slows down other containers. This should not be the case. I can pin the container to only use certain cores but then the UI slows down a lot. Why is that the case? So, in TOP in the container I can see 4 PHP-FPM instanced which all use up to 30% CPU which then in turn leads to a overall system usage of about 70% on my server. I don't recall that being that way in the past so did anything change? It happens like this in PHP 7.3 and 7.4 (can't use 7.2 as I am on the newest version). Is there a way to use an alternative to FPM or is it a known bug? As I understand it OwnCloud doesn't recommend the usage of FPM for OwnCloud. Thanks

So, after I posted a few times already with strange crashes, freezes and kernel panics I can not get the issue resolved. It's getting really frustrating to the point on where I am close on giving up with unRaid, although I don't know if other OSses would behave better. So the log on it's dying grasp are down below, here are the steps I did so far: - Turned of macvlan and switched to ipvlan. Also I tried all the solutions in the thread about this issue. As far as I can tell i didn't get any call traces. - I replaced the ram, because I wasn't sure if that was the issue. Now I have 32GB of ECC ram in there and still it crashes... - Repaired the filesystem on the cache drive because I had some errors from there. No more errors from that but still... So in summary I resolved all my other issues I could have had but still it crashes after an uptime of 5-10 days. Really frustrating. What else could I do? Motherboard issue? CPU issue? The CPU and Motherboard was in my windows PC for a long time and I didn't have any issues with it. Also when I moved it to my unraid box I didn't have any issues for a while, it only really started a few months ago. Logs: "Azeroth kernel: RAX: 0000000000017bc0 RBX: 0000000000000000 RCX: ffffffff81801047" "Azeroth kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffe00000d6758" "Azeroth kernel: RIP: 0010:exc_page_fault+0x17/0x101" "Azeroth kernel: RAX: 0000000000017bc0 RBX: 0000000000000000 RCX: ffffffff81801047" "Azeroth kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffe00000d6688" "Azeroth kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000" "Azeroth kernel: asm_exc_page_fault+0x1e/0x30" "Azeroth kernel: Code: 83 e9 85 7e 00 44 89 e6 48 89 ef 5d 41 5c e9 80 04 00 00 41 56 41 55 41 54 49 89 f4 55 48 89 fd 0f 20 d0 0f 1f 40 00 49 89 c5 <65> 48 8b 04 25 c0 7b 01 00 48 8b 80 a8 03 00 00 0f 0d 48 78 66 90" "Azeroth kernel: R13: 0000000000017bc0 R14: 0000000000000000 R15: 0000000000000000" "Azeroth kernel: ? native_iret+0x7/0x7" "Azeroth kernel: RBP: fffffe00000d6688 R08: 0000000000000000 R09: 0000000000000000" "Azeroth kernel: RBP: fffffe00000d6758 R08: 0000000000000000 R09: 0000000000000000" "Azeroth kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000" "Azeroth kernel: RSP: 0000:fffffe00000d6730 EFLAGS: 00010083" "Azeroth kernel: asm_exc_page_fault+0x1e/0x30" "Azeroth kernel: RAX: 0000000000017bc0 RBX: 0000000000000000 RCX: ffffffff81801047" "Azeroth kernel: RIP: 0010:exc_page_fault+0x17/0x101" "Azeroth kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffe00000d65b8" "Azeroth kernel: RAX: 0000000000017bc0 RBX: 0000000000000000 RCX: ffffffff81801047" "Azeroth kernel: Code: 83 e9 85 7e 00 44 89 e6 48 89 ef 5d 41 5c e9 80 04 00 00 41 56 41 55 41 54 49 89 f4 55 48 89 fd 0f 20 d0 0f 1f 40 00 49 89 c5 <65> 48 8b 04 25 c0 7b 01 00 48 8b 80 a8 03 00 00 0f 0d 48 78 66 90" "Azeroth kernel: ? native_iret+0x7/0x7" "Azeroth kernel: RBP: fffffe00000d64e8 R08: 0000000000000000 R09: 0000000000000000" "Azeroth kernel: R13: 0000000000017bc0 R14: 0000000000000000 R15: 0000000000000000" "Azeroth kernel: RBP: fffffe00000d65b8 R08: 0000000000000000 R09: 0000000000000000" "Azeroth kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000" "Azeroth kernel: RSP: 0000:fffffe00000d6660 EFLAGS: 00010083" "Azeroth kernel: Code: 83 e9 85 7e 00 44 89 e6 48 89 ef 5d 41 5c e9 80 04 00 00 41 56 41 55 41 54 49 89 f4 55 48 89 fd 0f 20 d0 0f 1f 40 00 49 89 c5 <65> 48 8b 04 25 c0 7b 01 00 48 8b 80 a8 03 00 00 0f 0d 48 78 66 90" "Azeroth kernel: R13: 0000000000017bc0 R14: 0000000000000000 R15: 0000000000000000" "Azeroth kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffe00000d64e8" "Azeroth kernel: ? native_iret+0x7/0x7" "Azeroth kernel: asm_exc_page_fault+0x1e/0x30" "Azeroth kernel: RSP: 0000:fffffe00000d6590 EFLAGS: 00010083" "Azeroth kernel: RSP: 0000:fffffe00000d64c0 EFLAGS: 00010083" "Azeroth kernel: RIP: 0010:exc_page_fault+0x17/0x101" "Azeroth kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000" "Azeroth kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffe00000d6418" "Azeroth kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffe00000d6348" "Azeroth kernel: Code: 83 e9 85 7e 00 44 89 e6 48 89 ef 5d 41 5c e9 80 04 00 00 41 56 41 55 41 54 49 89 f4 55 48 89 fd 0f 20 d0 0f 1f 40 00 49 89 c5 <65> 48 8b 04 25 c0 7b 01 00 48 8b 80 a8 03 00 00 0f 0d 48 78 66 90" "Azeroth kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000" "Azeroth kernel: Code: 83 e9 85 7e 00 44 89 e6 48 89 ef 5d 41 5c e9 80 04 00 00 41 56 41 55 41 54 49 89 f4 55 48 89 fd 0f 20 d0 0f 1f 40 00 49 89 c5 <65> 48 8b 04 25 c0 7b 01 00 48 8b 80 a8 03 00 00 0f 0d 48 78 66 90" "Azeroth kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000" "Azeroth kernel: RAX: 0000000000017bc0 RBX: 0000000000000000 RCX: ffffffff81801047" "Azeroth kernel: RSP: 0000:fffffe00000d63f0 EFLAGS: 00010083" "Azeroth kernel: Code: 83 e9 85 7e 00 44 89 e6 48 89 ef 5d 41 5c e9 80 04 00 00 41 56 41 55 41 54 49 89 f4 55 48 89 fd 0f 20 d0 0f 1f 40 00 49 89 c5 <65> 48 8b 04 25 c0 7b 01 00 48 8b 80 a8 03 00 00 0f 0d 48 78 66 90" "Azeroth kernel: R13: 0000000000017bc0 R14: 0000000000000000 R15: 0000000000000000" "Azeroth kernel: RIP: 0010:exc_page_fault+0x17/0x101" "Azeroth kernel: asm_exc_page_fault+0x1e/0x30" "Azeroth kernel: ? native_iret+0x7/0x7" "Azeroth kernel: RAX: 0000000000017bc0 RBX: 0000000000000000 RCX: ffffffff81801047" "Azeroth kernel: RBP: fffffe00000d6418 R08: 0000000000000000 R09: 0000000000000000" "Azeroth kernel: RSP: 0000:fffffe00000d6320 EFLAGS: 00010083" "Azeroth kernel: RIP: 0010:exc_page_fault+0x17/0x101" "Azeroth kernel: ? native_iret+0x7/0x7" "Azeroth kernel: R13: 0000000000017bc0 R14: 0000000000000000 R15: 0000000000000000" "Azeroth kernel: asm_exc_page_fault+0x1e/0x30" "Azeroth kernel: RIP: 0010:exc_page_fault+0x17/0x101" "Azeroth kernel: RBP: fffffe00000d6348 R08: 0000000000000000 R09: 0000000000000000" "Azeroth kernel: RIP: 0010:exc_page_fault+0x17/0x101" "Azeroth kernel: asm_exc_page_fault+0x1e/0x30" "Azeroth kernel: R13: 0000000000017bc0 R14: 0000000000000000 R15: 0000000000000000" "Azeroth kernel: RBP: fffffe00000d61a8 R08: 0000000000000000 R09: 0000000000000000" "Azeroth kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffe00000d6278" "Azeroth kernel: RIP: 0010:exc_page_fault+0x17/0x101" "Azeroth kernel: asm_exc_page_fault+0x1e/0x30" "Azeroth kernel: asm_exc_page_fault+0x1e/0x30" "Azeroth kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffe00000d61a8" "Azeroth kernel: RBP: fffffe00000d6278 R08: 0000000000000000 R09: 0000000000000000" "Azeroth kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000" "Azeroth kernel: RSP: 0000:fffffe00000d6180 EFLAGS: 00010083" "Azeroth kernel: RAX: 0000000000017bc0 RBX: 0000000000000000 RCX: ffffffff81801047" "Azeroth kernel: ? native_iret+0x7/0x7" "Azeroth kernel: ? native_iret+0x7/0x7" "Azeroth kernel: Code: 83 e9 85 7e 00 44 89 e6 48 89 ef 5d 41 5c e9 80 04 00 00 41 56 41 55 41 54 49 89 f4 55 48 89 fd 0f 20 d0 0f 1f 40 00 49 89 c5 <65> 48 8b 04 25 c0 7b 01 00 48 8b 80 a8 03 00 00 0f 0d 48 78 66 90" "Azeroth kernel: RAX: 0000000000017bc0 RBX: 0000000000000000 RCX: ffffffff81801047" "Azeroth kernel: R13: 0000000000017bc0 R14: 0000000000000000 R15: 0000000000000000" "Azeroth kernel: Code: 83 e9 85 7e 00 44 89 e6 48 89 ef 5d 41 5c e9 80 04 00 00 41 56 41 55 41 54 49 89 f4 55 48 89 fd 0f 20 d0 0f 1f 40 00 49 89 c5 <65> 48 8b 04 25 c0 7b 01 00 48 8b 80 a8 03 00 00 0f 0d 48 78 66 90" "Azeroth kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000" "Azeroth kernel: RSP: 0000:fffffe00000d6250 EFLAGS: 00010083" "Azeroth kernel: RIP: 0010:exc_page_fault+0x17/0x101" "Azeroth kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000" "Azeroth kernel: Call Trace:" "Azeroth kernel: asm_exc_page_fault+0x1e/0x30" "Azeroth kernel: <ENTRY_TRAMPOLINE>" "Azeroth kernel: RSP: 0000:fffffe00000d60b0 EFLAGS: 00010083" "Azeroth kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033" "Azeroth kernel: R13: 0000000000017bc0 R14: 0000000000000000 R15: 0000000000000000" "Azeroth kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffe00000d60d8" "Azeroth kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000" "Azeroth kernel: Code: 83 e9 85 7e 00 44 89 e6 48 89 ef 5d 41 5c e9 80 04 00 00 41 56 41 55 41 54 49 89 f4 55 48 89 fd 0f 20 d0 0f 1f 40 00 49 89 c5 <65> 48 8b 04 25 c0 7b 01 00 48 8b 80 a8 03 00 00 0f 0d 48 78 66 90" "Azeroth kernel: CR2: fffffe00000d5ff8 CR3: 00000001d6090000 CR4: 00000000003506e0" "Azeroth kernel: FS: 000014566f33f600(0000) GS:ffff8887fe900000(0000) knlGS:ffff8887fe900000" "Azeroth kernel: RAX: 0000000000017bc0 RBX: 0000000000000000 RCX: ffffffff81801047" "Azeroth kernel: ? native_iret+0x7/0x7" "Azeroth kernel: R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000" "Azeroth kernel: RBP: fffffe00000d60d8 R08: 0000000000000000 R09: 0000000000000000" "Azeroth kernel: Code: dc e8 92 d3 8a ff 48 89 ef e8 97 65 89 ff e8 c9 d3 8a ff 5c 65 c6 05 83 e9 85 7e 00 44 89 e6 48 89 ef 5d 41 5c e9 80 04 00 00 <41> 56 41 55 41 54 49 89 f4 55 48 89 fd 0f 20 d0 0f 1f 40 00 49 89" "Azeroth kernel: RSP: 0000:fffffe00000d6000 EFLAGS: 00010083" "Azeroth kernel: RAX: 0000000081801047 RBX: 0000000000000000 RCX: ffffffff81801047" "Azeroth kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000" "Azeroth kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: fffffe00000d6008" "Azeroth kernel: double fault: 0000 [#1] SMP NOPTI" "Azeroth kernel: Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 7601 10/16/2019" "Azeroth kernel: traps: PANIC: double fault, error_code: 0x0" "Azeroth kernel: RIP: 0010:exc_page_fault+0x0/0x101" "Azeroth kernel: CPU: 4 PID: 11633 Comm: fuser Tainted: P W O 5.14.15-Unraid #1" Thank you

I am on 6.10 RC for a while now which has not changed this behaviour. Unfortunately this prticular server is in a network which does not support VLANs. I will probably upgrade this network to something that supports VLANs but not at the moment unfortunately. I do however use a custom docker net so the containers have an internal IP in the 172.18.0.0/16 range and the external IP (not external on the WAN but external on the LAN) of the server.

Now I had some crashes and freezes with this server for some time now but wasn't able to find out what was wrong. In the last thread ( ) I was advised to completely redo my cache array, which I did, and hoped for the best. But unfortunately the server has crashed again. However I did set up a syslog server in order to be able to see what was going on before the crash and I captured this as the last dying gasp: Azeroth kernel: RIP: 0010:nf_nat_setup_info+0x12f/0x6d9 [nf_nat] I have the whole syslog leading up to this in the attachements. I have found a thread with people saying it has to do with their mikrotik network gear but I don't use any mikrotik gear. Has anyone any idea what this is and what I could do? Thanks All-Messages-search-result.csv

Copying did take a while and I had some freezes while doing that, I believe the Filesystem was truly corrupted or something. I managed though to move everything from the cache to the array finally and did double check everything copied well. Then I checked the SSDs thoroughly with Smart and nothing was unusual... so far so good. I now formatted the cache array (it was old, sure, the array was created in 2016) and am hoping that everything goes well from here. Now the mover is slowly moving files back... could take a while. Hopefully you wont hear from me again with this issue.

Yeah, as I said everything was stopped. No docker, no VMs, nothing visible in the top bar aswell.

Something seems really broken... Server went offline again while moving the files with MC. Tried to disable all VMs and Docker, disabled VM and Docker services and set all shares to cache: yes. Mover didn't really want to work so I cancelled it and just moved things with MC. All went fine until it reached the appdata folder then it first went really slow until it eventually just broke and I cant get in with WebUI, then SSH broke and now I can't even ping it anymore. Bad thing: this is my offsite server so I will postpone this until I can be at the site for at least a day. It does seem to be only the FS though as extended smart checks on all my 4 SSDs have been fine.

Thanks for the advice. The file system check (at least the scrub) has been successful. I'll try to do the other steps. Do you think the system lockup has anything to do with that then? Any advice on how to best do this? Just start in maintenance, copy everything over, format and copy back or is there a tool to help achieve that?

Hi Yesterday I had some issues with one of my unraid servers. I noticed when I got the message from pulseway that CPU was over 90% for over 5 minutes. I logged in to the WebUI which was unresponsive. My containers didn't seem to work anymore as I could not connect to them and couldn't open the docker tab on the UI. Strangely enough my htop in SSH didn't show much cpu activity, albeit the system load being shown as over 190. In SSH I tried some things and decided to reboot the system, which did nothing. It did the output that "system is going down" but it never did. I was able to "rescue" the diagnostics log so I'll attach it here. I just today found some time to skim through the logs and it is a little frighting honestly to see so many errors. Some were critical btrfs errors (from the cache array) and other errors I think are related. I don't know but assume the cpu load was from btrfs, but the system was completely locked. I could only restart it (thankfully soft reset) by short pressing the power button. After that it went down gracefully. After a restart everything seems to be in order and fine again. Two files are attached. One is the snippet from the syslog where the errors began (note, there is a gap in the syslog of almost 8 hours before the errors began) and the other is the full diagnostics I rescued. Thanks everyone for any attempt to bring light to this mess. log snippet.txt azeroth-diagnostics-20211003-1310.zip

Hi there I know this is a generic Owncloud question but as I'm using this container I thought why not ask here as well, maybe I'm lucky and you know the answer. Alright, I'm using "external storage" 'plugin to assign a local folder to one of my users. So his share is accessible with OwnCloud. If he uses Owncloud exclusively it's fine but if SMB is in the mix it doesn't work, as owncloud uses the "nobody:users" with the permissions set to 644 (so only user can write, all others can only read). Because I have disabled unauthorized SMB access (why was that even a thing?) every user has to log in with his own user account in the form of "username:users". This leads to all the files and folders created in Owncloud or the Desktop Sync being read only for the user, unless he exclusively uses Owncloud. So my question: can Owncloud be configured in a way that it sets the permissions to 664 or even 660 or something custom, so that the files are at least writable to by the user? I mean, the users are in the same group so 660 should be enough and safer. Thank you.