DeathStar Darth

Members
  • Posts

    13
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

DeathStar Darth's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. TL/DR: user choice rather than anything over/above MC. We use Ranger in the office so it's a natural extension for me to use it in my homelab. I think the original requestor (@Ziggurat) just had a personal preference for it.
  2. I tried manually bumping ranger to version ranger-1.9.3-x86_64-4cf.txz and it works fine.
  3. I was looking for this and saw it WAS in NerdPack However, when I try and run it from the cli, it errors ERROR:root:code for hash md5 was not found. Traceback (most recent call last): File "/usr/lib64/python2.7/hashlib.py", line 147, in <module> globals()[__func_name] = __get_hash(__func_name) File "/usr/lib64/python2.7/hashlib.py", line 97, in __get_builtin_constructor raise ValueError('unsupported hash type ' + name) ValueError: unsupported hash type md5 ERROR:root:code for hash sha1 was not found. Traceback (most recent call last): File "/usr/lib64/python2.7/hashlib.py", line 147, in <module> globals()[__func_name] = __get_hash(__func_name) File "/usr/lib64/python2.7/hashlib.py", line 97, in __get_builtin_constructor raise ValueError('unsupported hash type ' + name) ValueError: unsupported hash type sha1 ERROR:root:code for hash sha224 was not found. Traceback (most recent call last): File "/usr/lib64/python2.7/hashlib.py", line 147, in <module> globals()[__func_name] = __get_hash(__func_name) File "/usr/lib64/python2.7/hashlib.py", line 97, in __get_builtin_constructor raise ValueError('unsupported hash type ' + name) ValueError: unsupported hash type sha224 ERROR:root:code for hash sha256 was not found. Traceback (most recent call last): File "/usr/lib64/python2.7/hashlib.py", line 147, in <module> globals()[__func_name] = __get_hash(__func_name) File "/usr/lib64/python2.7/hashlib.py", line 97, in __get_builtin_constructor raise ValueError('unsupported hash type ' + name) ValueError: unsupported hash type sha256 ERROR:root:code for hash sha384 was not found. Traceback (most recent call last): File "/usr/lib64/python2.7/hashlib.py", line 147, in <module> globals()[__func_name] = __get_hash(__func_name) File "/usr/lib64/python2.7/hashlib.py", line 97, in __get_builtin_constructor raise ValueError('unsupported hash type ' + name) ValueError: unsupported hash type sha384 ERROR:root:code for hash sha512 was not found. Traceback (most recent call last): File "/usr/lib64/python2.7/hashlib.py", line 147, in <module> globals()[__func_name] = __get_hash(__func_name) File "/usr/lib64/python2.7/hashlib.py", line 97, in __get_builtin_constructor raise ValueError('unsupported hash type ' + name) ValueError: unsupported hash type sha512 Traceback (most recent call last): File "/usr/bin/ranger", line 36, in <module> sys.exit(ranger.main()) # pylint: disable=no-member File "/usr/lib64/python2.7/site-packages/ranger/core/main.py", line 32, in main from ranger.container.settings import Settings File "/usr/lib64/python2.7/site-packages/ranger/container/settings.py", line 13, in <module> from ranger.gui.colorscheme import _colorscheme_name_to_class File "/usr/lib64/python2.7/site-packages/ranger/gui/colorscheme.py", line 33, in <module> from ranger.gui.color import get_color File "/usr/lib64/python2.7/site-packages/ranger/gui/color.py", line 74, in <module> curses.setupterm() _curses.error: setupterm: could not find terminal I suspect this may be to do with the ncurses version which I have see giving issues with iotop as well Traceback (most recent call last): File "/usr/sbin/iotop", line 17, in <module> main() File "/usr/lib64/python2.7/site-packages/iotop/ui.py", line 620, in main main_loop() File "/usr/lib64/python2.7/site-packages/iotop/ui.py", line 610, in <lambda> main_loop = lambda: run_iotop(options) File "/usr/lib64/python2.7/site-packages/iotop/ui.py", line 508, in run_iotop return curses.wrapper(run_iotop_window, options) File "/usr/lib64/python2.7/curses/wrapper.py", line 22, in wrapper stdscr = curses.initscr() File "/usr/lib64/python2.7/curses/__init__.py", line 33, in initscr fd=_sys.__stdout__.fileno()) _curses.error: setupterm: could not find terminal Whilst downgrading ncurses to say ncurses-5.9-x86_64-4.txz fixes iotop (v0.6 in nerpack vs 1.2 in the wider world - which will compile ok on slackware), it does not fix ranger.
  4. Thanks @Squid that works perfectly now, and much appreciated.
  5. Normally I run the UnRaid server through a KVM switch and have no problem with it recognising my Logitech G815 keyboard. I've had reason to move my kit around and plugged the keyboard directly into the server (motherboard usb, not a usb hub hanging off it). At boot time it (the keyboard) springs to life in all its multi-coloured splendour, and I can use it to select bootmode (gui, safe etc) and all proceeds as normal. Midway through the boot process, all the lights go off and the keyboard is no longer of any use. I've had to pull out my old Mac keyboard to get around this for now This is from the log during boot: Aug 8 11:15:00 TheDeathStar kernel: hid-generic 0003:1B1C:1C07.0001: hiddev96,hidraw0: USB HID v1.11 Device [ ] on usb-0000:07:00.1-5/input0 Aug 8 11:15:00 TheDeathStar kernel: input: Logitech G815 RGB MECHANICAL GAMING KEYBOARD as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb4/4-1/4-1:1.0/0003:046D:C33F.0002/i nput/input1 Aug 8 11:15:00 TheDeathStar kernel: hid-generic 0003:046D:C33F.0002: input,hidraw1: USB HID v1.11 Keyboard [Logitech G815 RGB MECHANICAL GAMING KEYBOARD] on usb-0000:07:00.3-1/input0 Aug 8 11:15:00 TheDeathStar kernel: input: Logitech G815 RGB MECHANICAL GAMING KEYBOARD Keyboard as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb4/4-1/4-1:1.1/0003:046D:C3 3F.0003/input/input2 Aug 8 11:15:00 TheDeathStar kernel: input: Logitech G815 RGB MECHANICAL GAMING KEYBOARD Mouse as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb4/4-1/4-1:1.1/0003:046D:C33F. 0003/input/input3 Aug 8 11:15:00 TheDeathStar kernel: input: Logitech G815 RGB MECHANICAL GAMING KEYBOARD Consumer Control as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:07:00.3/usb4/4-1/4-1:1.1/0003 :046D:C33F.0003/input/input4 Aug 8 11:15:00 TheDeathStar kernel: hid-generic 0003:046D:C33F.0003: input,hiddev97,hidraw2: USB HID v1.11 Keyboard [Logitech G815 RGB MECHANICAL GAMING KEYBOARD] on usb-0000:07:00.3-1/input1 Definitely not a show-stopper, but I was wondering if anyone might be able to suggest a way to get it working so I can keep just one keyboard around until I can revert to my former kvm setup.
  6. Just by way of a 'how frequently does this happen'... I had this happen again overnight After the trace, the log is then filled with a looping set of errors Aug 8 08:18:13 TheDeathStar kernel: r8169 0000:06:00.1 eth0: rtl_chipcmd_cond == 1 (loop: 100, delay: 100). Aug 8 08:18:13 TheDeathStar kernel: r8169 0000:06:00.1 eth0: rtl_ephyar_cond == 1 (loop: 100, delay: 10). Aug 8 08:18:13 TheDeathStar kernel: r8169 0000:06:00.1 eth0: rtl_ephyar_cond == 1 (loop: 100, delay: 10). Aug 8 08:18:13 TheDeathStar kernel: r8169 0000:06:00.1 eth0: rtl_eriar_cond == 1 (loop: 100, delay: 100). Aug 8 08:18:13 TheDeathStar kernel: r8169 0000:06:00.1 eth0: rtl_eriar_cond == 1 (loop: 100, delay: 100). Aug 8 08:18:13 TheDeathStar kernel: r8169 0000:06:00.1 eth0: rtl_eriar_cond == 1 (loop: 100, delay: 100). Aug 8 08:18:13 TheDeathStar kernel: r8169 0000:06:00.1 eth0: rtl_eriar_cond == 1 (loop: 100, delay: 100). Aug 8 08:18:13 TheDeathStar kernel: r8169 0000:06:00.1 eth0: rtl_eriar_cond == 1 (loop: 100, delay: 100). Aug 8 08:18:13 TheDeathStar kernel: r8169 0000:06:00.1 eth0: rtl_eriar_cond == 1 (loop: 100, delay: 100). Aug 8 08:18:13 TheDeathStar kernel: r8169 0000:06:00.1 eth0: rtl_eriar_cond == 1 (loop: 100, delay: 100). Aug 8 08:18:14 TheDeathStar kernel: Generic FE-GE Realtek PHY r8169-601:00: r8169_apply_firmware failed: -110 Aug 8 08:18:23 TheDeathStar kernel: net_ratelimit: 5 callbacks suppressed https://bugzilla.kernel.org/show_bug.cgi?id=207205 seems to be related issue.
  7. I was reading this old article when you replied to it @Squid! I tried your above script with both the script and my xml in /tmp, but got an error root@TheDeathStar:/tmp# ./runxml.sh my-gluetun.xml Warning: parse_ini_file($docroot/state/var.ini): failed to open stream: No such file or directory in /tmp/runxml.sh on line 7 docker: invalid reference format. See 'docker run --help'. The path/file set in $var exists. root@TheDeathStar:/tmp# ls -lartih /usr/local/emhttp/state/var.ini 3243287 -rw-rw-rw- 1 root root 3.3K Aug 7 03:21 /usr/local/emhttp/state/var.ini as does that for $cfg root@TheDeathStar:/tmp# ls -lartih /boot/config/docker.cfg 11063 -rw------- 1 root root 350 Jul 30 16:14 /boot/config/docker.cfg Can you offer any pointers as to what I should follow up on to resolve?
  8. I have been having similar disconnects recently. Below is the last entries from my last syslog where it happened over this last wknd whilst I was away. I see ASUS m/board in both cases, but very different board at that, and both running Nvidia. A quick google throws up varied references to "RIP: 0010:dev_watchdog" type error - e.g. https://bugzilla.kernel.org/show_bug.cgi?id=199783 but as of yet I've not read about anything conclusive as to cause/resolution. Aug 2 00:22:33 TheDeathStar kernel: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out Aug 2 00:22:33 TheDeathStar kernel: WARNING: CPU: 11 PID: 10862 at net/sched/sch_generic.c:442 dev_watchdog+0xcf/0x12b Aug 2 00:22:33 TheDeathStar kernel: Modules linked in: vhci_hcd usbip_host usbip_core tun wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 poly1305_x86_64 ip6_udp_tunnel udp_tunnel libblake2s blake2s_ x86_64 libblake2s_generic libchacha ip_set iptable_raw iptable_mangle xt_owner nvidia_uvm(PO) veth xt_nat xt_tcpudp macvlan xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ ipv6 nf_defrag_ipv4 br_netfilter xfs nfsd lockd grace sunrpc md_mod nvidia_drm(PO) nvidia_modeset(PO) drm_kms_helper drm backlight agpgart syscopyarea sysfillrect sysimgblt fb_sys_fops nvidia(PO) ipmi_devintf nct6775 hwmon_vid corefreqk (O) ip6table_filter ip6_tables iptable_filter ip_tables x_tables bonding igb i2c_algo_bit r8169 realtek sr_mod cdrom edac_mce_amd kvm_amd kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd wmi_bmo f cryptd mxm_wmi nvme glue_helper nvme_core i2c_piix4 ahci i2c_core rapl libahci wmi Aug 2 00:22:33 TheDeathStar kernel: ccp k10temp button acpi_cpufreq [last unloaded: i2c_algo_bit] Aug 2 00:22:33 TheDeathStar kernel: CPU: 11 PID: 10862 Comm: FahCore_a7 Tainted: P O 5.10.28-Unraid #1 Aug 2 00:22:33 TheDeathStar kernel: Hardware name: ASUS System Product Name/Pro WS X570-ACE, BIOS 3402 03/22/2021 Aug 2 00:22:33 TheDeathStar kernel: RIP: 0010:dev_watchdog+0xcf/0x12b Aug 2 00:22:33 TheDeathStar kernel: Code: 79 b7 00 00 75 38 48 89 ef c6 05 63 79 b7 00 01 e8 79 dd fc ff 44 89 e1 48 89 ee 48 c7 c7 ef 7f de 81 48 89 c2 e8 50 16 10 00 <0f> 0b eb 10 41 ff c4 48 05 40 01 00 00 41 39 f4 75 9d eb 16 48 8b Aug 2 00:22:33 TheDeathStar kernel: RSP: 0018:ffffc90000420ed8 EFLAGS: 00010286 Aug 2 00:22:33 TheDeathStar kernel: RAX: 0000000000000000 RBX: ffff8881026f8438 RCX: 0000000000000027 Aug 2 00:22:33 TheDeathStar kernel: RDX: 00000000ffffdfff RSI: 0000000000000001 RDI: ffff888feead8920 Aug 2 00:22:33 TheDeathStar kernel: RBP: ffff8881026f8000 R08: 0000000000000000 R09: 00000000ffffdfff Aug 2 00:22:33 TheDeathStar kernel: R10: ffffc90000420d08 R11: ffffc90000420d00 R12: 0000000000000000 Aug 2 00:22:33 TheDeathStar kernel: R13: ffffc90000420f10 R14: ffffc90000420f10 R15: ffffffff820060c8 Aug 2 00:22:33 TheDeathStar kernel: FS: 000014d872fc6700(0000) GS:ffff888feeac0000(0000) knlGS:0000000000000000 Aug 2 00:22:33 TheDeathStar kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Aug 2 00:22:33 TheDeathStar kernel: CR2: 000014ebae82e8c0 CR3: 000000010f974000 CR4: 0000000000350ee0 Aug 2 00:22:33 TheDeathStar kernel: Call Trace: Aug 2 00:22:33 TheDeathStar kernel: <IRQ> Aug 2 00:22:33 TheDeathStar kernel: call_timer_fn.isra.0+0x12/0x6f Aug 2 00:22:33 TheDeathStar kernel: ? netif_tx_lock+0x7a/0x7a Aug 2 00:22:33 TheDeathStar kernel: __run_timers.part.0+0x144/0x185 Aug 2 00:22:33 TheDeathStar kernel: ? update_process_times+0x68/0x6e Aug 2 00:22:33 TheDeathStar kernel: ? hrtimer_forward+0x73/0x7b Aug 2 00:22:33 TheDeathStar kernel: ? tick_sched_timer+0x5a/0x64 Aug 2 00:22:33 TheDeathStar kernel: ? timerqueue_add+0x62/0x68 Aug 2 00:22:33 TheDeathStar kernel: run_timer_softirq+0x21/0x43 Aug 2 00:22:33 TheDeathStar kernel: __do_softirq+0xc4/0x1c2 Aug 2 00:22:33 TheDeathStar kernel: asm_call_irq_on_stack+0x12/0x20 Aug 2 00:22:33 TheDeathStar kernel: </IRQ> Aug 2 00:22:33 TheDeathStar kernel: do_softirq_own_stack+0x2c/0x39 Aug 2 00:22:33 TheDeathStar kernel: __irq_exit_rcu+0x45/0x80 Aug 2 00:22:33 TheDeathStar kernel: sysvec_apic_timer_interrupt+0x87/0x95 Aug 2 00:22:33 TheDeathStar kernel: asm_sysvec_apic_timer_interrupt+0x12/0x20 Aug 2 00:22:33 TheDeathStar kernel: RIP: 0010:___bpf_prog_run+0x838/0x12eb Aug 2 00:22:33 TheDeathStar kernel: Code: 48 8d 58 38 e9 f6 f7 ff ff 48 83 c3 08 e9 ed f7 ff ff 48 0f bf 43 02 48 8d 5c c3 08 e9 de f7 ff ff 48 8b 45 00 5b 5d 41 5c c3 <8a> 43 01 48 89 c2 c0 e8 04 83 e2 0f 0f b6 c0 48 8b 44 c5 00 48 39 Aug 2 00:22:33 TheDeathStar kernel: RSP: 0018:ffffc90007783db0 EFLAGS: 00000202 Aug 2 00:22:33 TheDeathStar kernel: RAX: ffffffff810cf263 RBX: ffffc90000811068 RCX: 0000000000000004 Aug 2 00:22:33 TheDeathStar kernel: RDX: 0000000040000003 RSI: 000000000000001d RDI: 0000000000000000 Aug 2 00:22:33 TheDeathStar kernel: RBP: ffffc90007783df0 R08: ffffc90007783eb0 R09: 0000000000000000 Aug 2 00:22:33 TheDeathStar kernel: R10: 00007fff4e260ae0 R11: 0000000000000000 R12: 0000000000000000 Aug 2 00:22:33 TheDeathStar kernel: R13: 000000007fff0000 R14: ffffc90007783eb0 R15: 0000000000000000 Aug 2 00:22:33 TheDeathStar kernel: ? ___bpf_prog_run+0x838/0x12eb Aug 2 00:22:33 TheDeathStar kernel: __bpf_prog_run32+0x35/0x51 Aug 2 00:22:33 TheDeathStar kernel: ? sysvec_apic_timer_interrupt+0x87/0x95 Aug 2 00:22:33 TheDeathStar kernel: __seccomp_filter+0x185/0x368 Aug 2 00:22:33 TheDeathStar kernel: ? pick_next_entity+0xcf/0xd7 Aug 2 00:22:33 TheDeathStar kernel: ? pick_next_task_fair+0x19c/0x201 Aug 2 00:22:33 TheDeathStar kernel: syscall_trace_enter.isra.0+0x38/0x4e Aug 2 00:22:33 TheDeathStar kernel: do_syscall_64+0xf/0x6a Aug 2 00:22:33 TheDeathStar kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Aug 2 00:22:33 TheDeathStar kernel: RIP: 0033:0x14d878353ef7 Aug 2 00:22:33 TheDeathStar kernel: Code: 73 01 c3 48 8b 0d 91 6f 2e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 18 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 61 6f 2e 00 f7 d8 64 89 01 48 Aug 2 00:22:33 TheDeathStar kernel: RSP: 002b:000014d872fc40b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000018 Aug 2 00:22:33 TheDeathStar kernel: RAX: ffffffffffffffda RBX: 0000000001774538 RCX: 000014d878353ef7 Aug 2 00:22:33 TheDeathStar kernel: RDX: 00007fff4e260ae0 RSI: 000014d872fc4060 RDI: 00007fff4e260ae0 Aug 2 00:22:33 TheDeathStar kernel: RBP: 000014d8500ec850 R08: 00007fff4e260ae0 R09: 0000000001498670 Aug 2 00:22:33 TheDeathStar kernel: R10: 0000000000000000 R11: 0000000000000202 R12: 0000000001774270 Aug 2 00:22:33 TheDeathStar kernel: R13: 000014d872fc4190 R14: 000014d872fc41e0 R15: 0000000001774418 Aug 2 00:22:33 TheDeathStar kernel: ---[ end trace 5bb24dc1dd212e0e ]---
  9. Yes, when I eventually got Unraid to fire-up after the series of unfortunate events, the 2nd nvme was not showing, nor was it showing in the bios after closer attention. I'd already come across that post whist trying to resolve the issue, and it was immediately added to my userscripts 👍 I've already rebooted any it stays in RO mode. I've tied to copy the whole FS of the content to another drive ahead of reformatting, and whilst many thousands of files copy cleanly, I am seeing a lot of others with errors cp: error reading 'foobar.file': Input/output error I'm wondering if it's worth me trying to stop the array remove the nvme that went missing (nvme1n1) restart the array - and see if in RW mode scrub (if in rw mode) or btrfs restore -v /dev/nvme1n1 /mnt/disk3/restore (the nvme that has always been present, and the newly added disk in the array) ?
  10. TL/DR : nvme cache pool gone in to read-only mode. How to recover (put in read/write mode and scrub?) A few hours after a long-running (several days) pre-clear of a new disk completed my server unexpectedly reset itself. That was pretty unusual in itself. Upon reboot, I kept on being directed to BIOS setup rather than POST. After multiple attempts using the old tricks - reseating hardware, cmos factory defaults etc - failed I took the USB boot and placed it in my Mac to have a look at the content. All the files present were readable, and I took a backup so as to ensure details of disks, shares, networks etc were available to me later. I noticed that the syslinux folder was missing off the usb, and ldlinux.c32 etc was not present anywhere (https://forums.unraid.net/topic/37416-boot-failed-failed-to-load-ldlinuxc32-help/?do=findComment&comment=360045). I downloaded fresh copy of install files from LT and copied them on to my usb, ensuring I didn't overwrite config files that appear intact. After some more 'fun' with the bios (and a bios upgrade as it was a year and 6 or so releases out of date) I eventually got it to get me to the Unraid boot options. Unraid booted fine...but I noticed one of my 2 nvme drives in cahe pool were not appearing. Reboot and look at BIOS and see only one is being reported. More BIOS changes (using new options made available in earlier bios upgrade) and they are visible again in the BIOS. Reboot into Unraid. Re-add the 2nd nvme back into the cache pool. (and add the new pre-cleared disk(3) to the array) All appeared ok, but then I notice Fix Common Problems is flagging an issue "Unable to write to cache_app" "Drive mounted read-only or completely full. Begin Investigation Here - in this ccse it is rad-only, not completely full issue, as shown on the main dashboard (which shows the utilisation exactly as I recall it before all the issues started): Running btrfs dev stats /dev/cache returns the hoped for 0 count (this is an ssd pool), but running btrfs dev stats /dev/cache_apps shows issues (this is the pool the nvme's are in) [/dev/nvme0n1p1].write_io_errs 0 [/dev/nvme0n1p1].read_io_errs 0 [/dev/nvme0n1p1].flush_io_errs 0 [/dev/nvme0n1p1].corruption_errs 0 [/dev/nvme0n1p1].generation_errs 0 [/dev/nvme1n1p1].write_io_errs 42491 [/dev/nvme1n1p1].read_io_errs 3211 [/dev/nvme1n1p1].flush_io_errs 1416 [/dev/nvme1n1p1].corruption_errs 2777 [/dev/nvme1n1p1].generation_errs 0 Trying to scrub it with btrfs scrub start -dB /dev/nvme1n1p1 highlights the fact it's in read-only mode ERROR: scrubbing /dev/nvme1n1p1 failed for device id 2: ret=-1, errno=30 (Read-only file system) Scrub device /dev/nvme1n1p1 (id 2) canceled Scrub started: Thu Jun 17 20:28:50 2021 Status: aborted Duration: 0:00:00 Total to scrub: 522.03GiB Rate: 0.00B/s Error summary: no errors found Checking the syslog shows the pain: So my question is, where do I go from here?
  11. Rather than the UserScript, give the docker flavour a whirl - search for vm_custom_icons app. (Note, code repository is held in GitHub - https://github.com/SpaceinvaderOne/unraid_vm_icons ) Although at 92gig's for a few icons, you might not want to
  12. I tried the other day and saw issues. Just tried again and see the same issues Will not apply HSTS. The HSTS database must be a regular and non-world-writable file. ERROR: could not open HSTS store at '//.wget-hsts'. HSTS will be disabled. --2021-04-23 17:28:44-- http://spaceinvader.one/unraidvmicons/ Resolving spaceinvader.one (spaceinvader.one)... 104.21.33.43, 172.67.141.41 Connecting to spaceinvader.one (spaceinvader.one)|104.21.33.43|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 530 Date: Fri, 23 Apr 2021 16:28:44 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive X-Frame-Options: SAMEORIGIN Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Expires: Thu, 01 Jan 1970 00:00:01 GMT CF-RAY: 6448777c4f6740b9-LHR Server: cloudflare 2021-04-23 17:28:44 ERROR 530: (no description). Will not apply HSTS. The HSTS database must be a regular and non-world-writable file. ERROR: could not open HSTS store at '//.wget-hsts'. HSTS will be disabled. --2021-04-23 17:28:44-- http://spaceinvader.one/unraidbanners/ Resolving spaceinvader.one (spaceinvader.one)... 104.21.33.43, 172.67.141.41 Connecting to spaceinvader.one (spaceinvader.one)|104.21.33.43|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 530 Date: Fri, 23 Apr 2021 16:28:44 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive X-Frame-Options: SAMEORIGIN Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Expires: Thu, 01 Jan 1970 00:00:01 GMT CF-RAY: 6448777cc98b2ccb-LHR Server: cloudflare 2021-04-23 17:28:44 ERROR 530: (no description). when trying to connect to the scripts specified path, you get : so looks like something for @SpaceInvaderOne to resolve?