sreknob

Members
  • Posts

    41
  • Joined

  • Last visited

Everything posted by sreknob

  1. While in maintenance mode, I ran a file system check on all my array drives (which are xfs) and I did not find any major errors. Will check the lost+found to see if anything in there. Interestingly, on my cache pool (btrfs) did show some errors. [1/7] checking root items [2/7] checking extents data backref 333842939904 root 5 owner 18675039 offset 18446673705361137664 num_refs 0 not found in extent tree incorrect local backref count on 333842939904 root 5 owner 18675039 offset 18446673705361137664 found 1 wanted 0 back 0x189df1d0 incorrect local backref count on 333842939904 root 5 owner 18675039 offset 395763712 found 7 wanted 8 back 0x187170b0 backpointer mismatch on [333842939904 102400] ERROR: errors found in extent allocation tree or chunk allocation [3/7] checking free space cache [4/7] checking fs roots root 5 inode 18675039 errors 1040, bad file extent, some csum missing ERROR: errors found in fs roots Opening filesystem to check... Checking filesystem on /dev/sdb1 UUID: 6512c394-cc26-4544-97d3-4a484923301f found 213364232192 bytes used, error(s) found total csum bytes: 92116280 total tree bytes: 1020280832 total fs tree bytes: 773505024 total extent tree bytes: 114278400 btree space waste bytes: 224328220 file data blocks allocated: 2574916517888 referenced 20818464358 There doesn't seem to be a lot of info about these errors and I am uncertain if it's safe to run a scrub or repair on it.... Thanks in advance for any guidance!
  2. Thanks again. I figured it was a FS error and wanted to make sure this was enough to cause the fs/inode.c error and the lockup for my dockers. Kind of strange to me though the filesystem error caused this big a problem for me. Seeing that it was over a month between the FS error and the lockup, do you think this explains it? Especially as my docker appdata and docker image all run off cache, though many use the fuse file system for appdata and storage. Also, I hadn’t realized my container was running out of memory so often though as well. Suppose I’ll give Unifi a little more room. Never found an adequate reason my controller gets out of control...
  3. Thanks for having a look. It’s actually not the server that’s running out of memory. My Unifi controller mongodb gets out of control in its docker container so I have constrained the memory for that container. When it hits the limit in Unifi container, it throws the error and restarts the docker container. AFAIK it’s never been the actual unraid OS.
  4. So, it ended up being a dirty shutdown, despite lazy unmounting the docker image and killing off a boat load of processes. Also, note to self, don't trust the GUI for config edits when something is hanging. I disabled autostart from the GUI but it didn't stick, so parity check is happening now. Still nuked the docker image but won't be able to check the filesystems until parity check is done.... ¯\_(ツ)_/¯.
  5. Hi, Looking for some guidance on the following error. Noted this morning that some of my docker containers were misbehaving and then found that I was unable to stop any containers. Looking in my syslog, I found the following error overnight: Apr 27 04:37:28 unRAID kernel: ------------[ cut here ]------------ Apr 27 04:37:28 unRAID kernel: kernel BUG at fs/inode.c:518! Apr 27 04:37:28 unRAID kernel: invalid opcode: 0000 [#1] SMP PTI Apr 27 04:37:28 unRAID kernel: CPU: 5 PID: 686 Comm: kswapd0 Tainted: P O 4.19.107-Unraid #1 Apr 27 04:37:28 unRAID kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z68 Extreme3 Gen3, BIOS P2.30 06/29/2012 Apr 27 04:37:28 unRAID kernel: RIP: 0010:clear_inode+0x78/0x88 Apr 27 04:37:28 unRAID kernel: Code: 74 02 0f 0b 48 8b 83 90 00 00 00 a8 20 75 02 0f 0b a8 40 74 02 0f 0b 48 8b 83 20 01 00 00 48 8d 93 20 01 00 00 48 39 c2 74 02 <0f> 0b 48 c7 83 90 00 00 00 60 00 00 00 5b 5d c3 53 83 7f 40 00 48 Apr 27 04:37:28 unRAID kernel: RSP: 0018:ffffc90001af7be8 EFLAGS: 00010287 Apr 27 04:37:28 unRAID kernel: RAX: ffff8881433d2220 RBX: ffff888143352100 RCX: 0000000000000000 Apr 27 04:37:28 unRAID kernel: RDX: ffff888143352220 RSI: 0000000000000000 RDI: ffff888143352270 Apr 27 04:37:28 unRAID kernel: RBP: ffff888143352270 R08: 0000000000000001 R09: 0000000000000000 Apr 27 04:37:28 unRAID kernel: R10: 0000000000000001 R11: ffff88841f55fb40 R12: ffff888143352210 Apr 27 04:37:28 unRAID kernel: R13: ffff88812b2a76c0 R14: ffffc90001af7c98 R15: ffff888151041f00 Apr 27 04:37:28 unRAID kernel: FS: 0000000000000000(0000) GS:ffff88841f540000(0000) knlGS:0000000000000000 Apr 27 04:37:28 unRAID kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 27 04:37:28 unRAID kernel: CR2: 000014c9af20d020 CR3: 0000000004e0a005 CR4: 00000000000606e0 Apr 27 04:37:28 unRAID kernel: Call Trace: Apr 27 04:37:28 unRAID kernel: fuse_evict_inode+0x18/0x50 Apr 27 04:37:28 unRAID kernel: evict+0xb8/0x16e Apr 27 04:37:28 unRAID kernel: __dentry_kill+0xcb/0x135 Apr 27 04:37:28 unRAID kernel: shrink_dentry_list+0x149/0x185 Apr 27 04:37:28 unRAID kernel: prune_dcache_sb+0x56/0x74 Apr 27 04:37:28 unRAID kernel: super_cache_scan+0xee/0x16d Apr 27 04:37:28 unRAID kernel: do_shrink_slab+0x128/0x194 Apr 27 04:37:28 unRAID kernel: shrink_slab+0x11b/0x276 Apr 27 04:37:28 unRAID kernel: shrink_node+0x108/0x3cb Apr 27 04:37:28 unRAID kernel: kswapd+0x451/0x58a Apr 27 04:37:28 unRAID kernel: ? __switch_to_asm+0x41/0x70 ### [PREVIOUS LINE REPEATED 1 TIMES] ### Apr 27 04:37:28 unRAID kernel: ? mem_cgroup_shrink_node+0xa4/0xa4 Apr 27 04:37:28 unRAID kernel: kthread+0x10c/0x114 Apr 27 04:37:28 unRAID kernel: ? kthread_park+0x89/0x89 Apr 27 04:37:28 unRAID kernel: ret_from_fork+0x35/0x40 Apr 27 04:37:28 unRAID kernel: Modules linked in: macvlan nvidia_uvm(O) xt_CHECKSUM ipt_REJECT ip6table_mangle ip6table_nat nf_nat_ipv6 iptable_mangle ip6table_filter ip6_tables vhost_net tun vhost tap xt_nat veth ipt_MASQUERADE iptable_filter iptable_nat nf_nat_ipv4 nf_nat ip_tables xfs md_mod nct6775 hwmon_vid nvidia_drm(PO) nvidia_modeset(PO) nvidia(PO) crc32_pclmul intel_rapl_perf intel_uncore pcbc aesni_intel aes_x86_64 glue_helper crypto_simd ghash_clmulni_intel cryptd kvm_intel drm_kms_helper kvm drm intel_cstate coretemp mxm_wmi cp210x wmi usbserial syscopyarea sysfillrect sysimgblt fb_sys_fops agpgart i2c_i801 crct10dif_pclmul intel_powerclamp i2c_core crc32c_intel r8169 ahci mpt3sas video x86_pkg_temp_thermal backlight realtek libahci pata_jmicron button raid_class scsi_transport_sas pcc_cpufreq Apr 27 04:37:28 unRAID kernel: ---[ end trace 6347766c3e151675 ]--- Apr 27 04:37:28 unRAID kernel: RIP: 0010:clear_inode+0x78/0x88 Apr 27 04:37:28 unRAID kernel: Code: 74 02 0f 0b 48 8b 83 90 00 00 00 a8 20 75 02 0f 0b a8 40 74 02 0f 0b 48 8b 83 20 01 00 00 48 8d 93 20 01 00 00 48 39 c2 74 02 <0f> 0b 48 c7 83 90 00 00 00 60 00 00 00 5b 5d c3 53 83 7f 40 00 48 Apr 27 04:37:28 unRAID kernel: RSP: 0018:ffffc90001af7be8 EFLAGS: 00010287 Apr 27 04:37:28 unRAID kernel: RAX: ffff8881433d2220 RBX: ffff888143352100 RCX: 0000000000000000 Apr 27 04:37:28 unRAID kernel: RDX: ffff888143352220 RSI: 0000000000000000 RDI: ffff888143352270 Apr 27 04:37:28 unRAID kernel: RBP: ffff888143352270 R08: 0000000000000001 R09: 0000000000000000 Apr 27 04:37:28 unRAID kernel: R10: 0000000000000001 R11: ffff88841f55fb40 R12: ffff888143352210 Apr 27 04:37:28 unRAID kernel: R13: ffff88812b2a76c0 R14: ffffc90001af7c98 R15: ffff888151041f00 Apr 27 04:37:28 unRAID kernel: FS: 0000000000000000(0000) GS:ffff88841f540000(0000) knlGS:0000000000000000 Apr 27 04:37:28 unRAID kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 27 04:37:28 unRAID kernel: CR2: 000014c9af20d020 CR3: 0000000004e0a002 CR4: 00000000000606e0 Given that I'm unable to stop or kill my docker containers, I haven't tried a reboot as I presume my system is going to hang on shutdown due to this. My plan is to turn off auto-array start, shutdown (gracefully or not -- perhaps trying umount -f /var/lib/docker prior to this), nuke the docker image an check my file systems. Any advice appreciated. I've attached my diagnostics. Thanks! unraid-diagnostics-20200427-1448.zip
  6. @phenomeus - my brother was just having this same issue with his. "The network backup disk does not support the required capabilities" I tweaked his settings and seemed to fix it. He had the "Split level" set to manual - changed it to automatic and changed to only a single included disk and no cache. Also changed share name to "TimeMachine", set export to yes/Time Machine (hidden) and Public security and hit apply. Seemed to clear it up for him. Good luck!
  7. You can use pretty much anything with this, that's part of the beauty of it! Best to get something that can stream HTTP or RTSP, best with x264 video probably. I have a couple of EZVIZ Husky 1080p PoE Bullet Cameras I picked up on clearance for cheap and they work well as outdoor cameras. I also have some motorola wifi baby monitors, a couple of D-link DCS-2530Ls and my OctoPi camera as well.
  8. @pg93 - did you try syncing the clock using: -v /etc/localtime:/etc/localtime:ro You can either add it as a custom variable or add it to your template as a read-only path I can't guarantee it works with this container though, I'm using the official one from ccrisan/motioneye
  9. Glad it worked for you @block134 @linuxserver.io - looking through this thread, I see lots of adoption issues. I wonder if adding the set-inform address in the controller should be part of the instructions to save frustration. I think that many may be running into this problem depending on their docker network setup. For those having adoption problems, if you want to check your devices to see where they're getting stuck with adoption loops, you can SSH into the device and run "info" which will show the current set-inform IP address. This can be done though a usual SSH session or opening a debug terminal from your controller (click on the device, then the tools button, then debug terminal) depending on the state of your device.
  10. Big thanks as usual to the team! For those having adoption issues, I vaguely remember having issues before about that. In case you don't already have custom IP in controller settings, you might want to make sure that you have set the IP under settings. I had a issue where the controller was trying to set-inform with my private docker IP (172.17..1.X) instead. See screenshot below, checking "Override inform host with controller hostname/IP" and entering the IP of your server above that.
  11. I just wanted to say thanks to the team! Got this working nicely with a GTX 1060. Brilliant stuff 🙂
  12. @Bydgoszcz I do not think this is not the containers fault - it's MongoDB issue I've seen over at the UniFi forums. I have the same problem. Two options to deal with it - limit the amount of RAM that he container can use (add -m "2g" to the extra parameters field to limit to 2GB) to prevent it from making other containers and server angry OR try and have the controller directly limit the amount of RAM that it uses setting "unifi.xms=256" or similar in UniFi properties (see here for discussion). You could also try pruning the database to see if that's contributing to the issue - see here for the script I did the easy thing and just limited my docker container., hoping that one day the controller will behave better...
  13. well said! Thanks LSIO for keeping my controller going 🙂
  14. Following! Please let me know if you get this going for a specific docker image. I've been trying to do this for a DNS server that also uses port 80 and I don't want to move the unRAID webUI port. Used to have this working with a custom network but something changed with an upgrade...
  15. Just came to say a big thanks to @Fireball3 and the community! Just flashed two H310s and the scripts made it super ridiculously easy. I did have to cover pins B5-B6 to get the system to boot but everything went smoothly.