-
After taking the array offline and adding my first parity disk, all my dockers have disappeared from the docker tab
Makes sense. But when I recreate the docker containers from the same images, I still have to go through and set up the settings and libraries and downloaders and so on. I suppose that's the fault of the app itself, right?
-
After taking the array offline and adding my first parity disk, all my dockers have disappeared from the docker tab
Thanks for the links. Most of the dockers could be recreated fine, but I had to rebuild plex's libraries _again_. Any idea what could've caused it? Or how to prevent this in the future? I don't know where these dockers are stored or what can delete them.
-
Unraid Plex libraries seem to disappear
Thanks for the help. I switched from binhex-plex-pass to plex's official docker and that seems to have helped a little. I didn't get any help from Plex's side of things.
-
-
After taking the array offline and adding my first parity disk, all my dockers have disappeared from the docker tab
Up until yesterday I was running unraid with two large hard drives, no cache and no parity. I just added another HDD and NVMe and decided to enable parity and cache. Now all of my docker containers have disappeared from the docker tab. Will they come back when the parity check is complete? Is this similar to how turning off the array also stops the docker containers? To be clear, my docker containers haven't turned off, they've completely vanished from the tab. If they have gone missing or been removed for some reason (I swear I didn't do it on purpose) what are the odds that I can restore them with the same configuration as before? Or will I have to rebuild everything from scratch? I had the official plex docker as well as linuxserver's nzbget, sonarr, and radarr installed. Thanks. Screenshots:
-
Unraid Plex libraries seem to disappear
I enabled the syslog settings in your posted link. The plex library has disappeared again. I don't see anything in the syslog about plex, but it does say that another docker, NZBGet, has crashed for some reason. Aug 5 00:25:30 Vault kernel: docker0: port 4(veth954b6bd) entered forwarding state Aug 5 00:29:33 Vault kernel: docker0: port 4(veth954b6bd) entered disabled state Aug 5 00:29:33 Vault kernel: vethce454a9: renamed from eth0 Aug 5 00:29:33 Vault kernel: docker0: port 4(veth954b6bd) entered disabled state Aug 5 00:29:33 Vault kernel: device veth954b6bd left promiscuous mode Aug 5 00:29:33 Vault kernel: docker0: port 4(veth954b6bd) entered disabled state Aug 5 00:33:21 Vault kernel: igc 0000:02:00.0 eth0: NIC Link is Down Aug 5 00:33:21 Vault kernel: bond0: (slave eth0): link status definitely down, disabling slave Aug 5 00:33:21 Vault kernel: device eth0 left promiscuous mode Aug 5 00:33:21 Vault kernel: bond0: now running without any active interface! Aug 5 00:33:21 Vault kernel: br0: port 1(bond0) entered disabled state Aug 5 00:33:23 Vault dhcpcd[1121]: br0: carrier lost Aug 5 00:33:23 Vault avahi-daemon[5897]: Withdrawing address record for 192.168.1.232 on br0. Aug 5 00:33:23 Vault avahi-daemon[5897]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.1.232. Aug 5 00:33:23 Vault avahi-daemon[5897]: Interface br0.IPv4 no longer relevant for mDNS. Aug 5 00:33:23 Vault dhcpcd[1121]: br0: deleting route to 192.168.1.0/24 Aug 5 00:33:23 Vault dhcpcd[1121]: br0: deleting default route via 192.168.1.254 Aug 5 00:33:23 Vault dnsmasq[7969]: no servers found in /etc/resolv.conf, will retry Aug 5 00:33:25 Vault ntpd[1294]: Deleting interface #1 br0, 192.168.1.232#123, interface stats: received=70, sent=70, dropped=0, active_time=25005 secs Aug 5 00:33:25 Vault ntpd[1294]: 216.239.35.8 local addr 192.168.1.232 -> <null> Aug 5 00:33:57 Vault kernel: igc 0000:02:00.0 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Aug 5 00:33:57 Vault kernel: bond0: (slave eth0): link status definitely up, 1000 Mbps full duplex Aug 5 00:33:57 Vault kernel: bond0: (slave eth0): making interface the new active one Aug 5 00:33:57 Vault kernel: device eth0 entered promiscuous mode Aug 5 00:33:57 Vault kernel: bond0: active interface up! Aug 5 00:33:57 Vault kernel: br0: port 1(bond0) entered blocking state Aug 5 00:33:57 Vault kernel: br0: port 1(bond0) entered forwarding state Aug 5 00:33:57 Vault dhcpcd[1121]: br0: carrier acquired Aug 5 00:33:58 Vault dhcpcd[1121]: br0: rebinding lease of 192.168.1.232 Aug 5 00:34:00 Vault kernel: igc 0000:02:00.0 eth0: NIC Link is Down Aug 5 00:34:00 Vault kernel: bond0: (slave eth0): link status definitely down, disabling slave Aug 5 00:34:00 Vault kernel: device eth0 left promiscuous mode Aug 5 00:34:00 Vault kernel: bond0: now running without any active interface! Aug 5 00:34:00 Vault kernel: br0: port 1(bond0) entered disabled state Aug 5 00:34:01 Vault dhcpcd[1121]: br0: carrier lost Aug 5 00:34:05 Vault kernel: igc 0000:02:00.0 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Aug 5 00:34:05 Vault kernel: bond0: (slave eth0): link status definitely up, 1000 Mbps full duplex Aug 5 00:34:05 Vault kernel: bond0: (slave eth0): making interface the new active one Aug 5 00:34:05 Vault kernel: device eth0 entered promiscuous mode Aug 5 00:34:05 Vault kernel: bond0: active interface up! Aug 5 00:34:05 Vault kernel: br0: port 1(bond0) entered blocking state Aug 5 00:34:05 Vault kernel: br0: port 1(bond0) entered forwarding state Aug 5 00:34:05 Vault dhcpcd[1121]: br0: carrier acquired Aug 5 00:34:05 Vault dhcpcd[1121]: br0: rebinding lease of 192.168.1.232 Aug 5 00:34:10 Vault dhcpcd[1121]: br0: probing for an IPv4LL address Aug 5 00:34:10 Vault dhcpcd[1121]: br0: DHCP lease expired Aug 5 00:34:10 Vault dhcpcd[1121]: br0: soliciting a DHCP lease Aug 5 00:34:10 Vault dhcpcd[1121]: br0: offered 192.168.1.232 from 192.168.1.254 Aug 5 00:34:12 Vault dhcpcd[1121]: br0: probing address 192.168.1.232/24 Aug 5 00:34:15 Vault dhcpcd[1121]: br0: using IPv4LL address 169.254.25.30 Aug 5 00:34:15 Vault avahi-daemon[5897]: Joining mDNS multicast group on interface br0.IPv4 with address 169.254.25.30. Aug 5 00:34:15 Vault avahi-daemon[5897]: New relevant interface br0.IPv4 for mDNS. Aug 5 00:34:15 Vault avahi-daemon[5897]: Registering new address record for 169.254.25.30 on br0.IPv4. Aug 5 00:34:15 Vault dhcpcd[1121]: br0: adding route to 169.254.0.0/16 Aug 5 00:34:15 Vault dhcpcd[1121]: br0: adding default route Aug 5 00:34:15 Vault network: hook services: interface=br0, reason=IPV4LL, protocol=ipv4ll Aug 5 00:34:15 Vault network: update services: 45s Aug 5 00:34:17 Vault dhcpcd[1121]: br0: leased 192.168.1.232 for 86400 seconds Aug 5 00:34:17 Vault avahi-daemon[5897]: Registering new address record for 192.168.1.232 on br0.IPv4. Aug 5 00:34:17 Vault dhcpcd[1121]: br0: adding route to 192.168.1.0/24 Aug 5 00:34:17 Vault dhcpcd[1121]: br0: changing default route via 192.168.1.254 Aug 5 00:34:17 Vault dnsmasq[7969]: reading /etc/resolv.conf Aug 5 00:34:17 Vault dnsmasq[7969]: using nameserver 192.168.1.254#53 Aug 5 00:34:17 Vault network: hook services: interface=br0, reason=BOUND, protocol=dhcp Aug 5 00:34:17 Vault network: update services: 45s Aug 5 00:34:17 Vault avahi-daemon[5897]: Withdrawing address record for 169.254.25.30 on br0. Aug 5 00:34:17 Vault avahi-daemon[5897]: Leaving mDNS multicast group on interface br0.IPv4 with address 169.254.25.30. Aug 5 00:34:17 Vault avahi-daemon[5897]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.232. Aug 5 00:34:17 Vault dhcpcd[1121]: br0: deleting route to 169.254.0.0/16 Aug 5 00:34:17 Vault network: hook services: interface=br0, reason=IPV4LL, protocol=ipv4ll Aug 5 00:34:17 Vault network: update services: 45s Aug 5 00:34:19 Vault ntpd[1294]: Listen normally on 2 br0 192.168.1.232:123 Aug 5 00:34:19 Vault ntpd[1294]: new interface(s) found: waking up resolver Aug 5 00:35:00 Vault network: reload service: nginx Aug 5 00:58:53 Vault emhttpd: read SMART /dev/sdh Aug 5 01:29:00 Vault emhttpd: spinning down /dev/sdh Aug 5 02:05:07 Vault emhttpd: read SMART /dev/sdh Aug 5 05:34:42 Vault emhttpd: spinning down /dev/sdh Aug 5 11:53:26 Vault ool www[8441]: /usr/local/emhttp/plugins/dynamix/scripts/rsyslog_config Aug 5 11:53:28 Vault rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="8492" x-info="https://www.rsyslog.com"] start Aug 5 12:55:59 Vault emhttpd: read SMART /dev/sdh Aug 5 13:26:06 Vault emhttpd: spinning down /dev/sdh Aug 5 14:27:55 Vault emhttpd: read SMART /dev/sdh Aug 5 16:12:36 Vault emhttpd: spinning down /dev/sdh Aug 5 18:10:46 Vault emhttpd: read SMART /dev/sdh Aug 5 18:29:26 Vault kernel: nzbget[20589]: segfault at a ip 00000000004673bb sp 00001481a8f46c20 error 4 in nzbget[400000+5f7000] likely on CPU 3 (core 3, socket 0) Aug 5 18:29:26 Vault kernel: Code: 30 48 8b 6f 28 48 89 74 24 28 48 39 c5 48 89 44 24 08 0f 84 66 01 00 00 0f 1f 80 00 00 00 00 48 8b 45 00 48 8b 98 38 03 00 00 <80> 7b 0a 00 0f 84 3b 01 00 00 4c 8b 2b 41 8b 85 3c 01 00 00 83 f8 Aug 5 19:04:31 Vault emhttpd: spinning down /dev/sdh Aug 5 21:05:16 Vault emhttpd: read SMART /dev/sdh Aug 5 23:31:11 Vault emhttpd: spinning down /dev/sdh
-
Unraid Plex libraries seem to disappear
Hello. I'm new to plex and unraid. I have installed the binhex-plexpass app on my unraid server and added some libraries. The whole thing seems to work at first, but this morning when I woke up, the server libraries were missing. I could still access the server via the webUI but it didn't present itself as a server in the sidebar that I could manage; and its libraries weren't available for serving. So I don't know if it crashed or what. Rebooting the docker resolved the issue temporarily but I don't know what would cause the server to disappear. Some more details: - I can visit the server at its IP and port (192.168.1.232:32400) but the libraries are missing and I cannot access the settings for the server until I reboot the docker container.
-
New user, slow transfer speeds on new drive without parity or cache
Thanks, I'll check that out. I'll also try this out with my Windows desktop just to check how it performs. Should I expect unraid to be able to saturate a gigabit connection for both reading and writing when using Windows?
-
New user, slow transfer speeds on new drive without parity or cache
Here's the diagnostics. When I copy a file with Finder on my mac, it doesn't show the file transfer speed, but the activity monitor does. Crystal Disk Mark (Or I guess the new one is AmorphousDiskMark?) shows similar stats. I attached some screenshots. Thanks for the reply. vault-diagnostics-20240707-1056.zip
-
New user, slow transfer speeds on new drive without parity or cache
I'm just getting started with unraid. I have a basic array with one drive, no cache, no parity (yet), and a single SMB user share. I installed the disk speed plugin and it reported about 430MBps. I ran the network speed test app and it gives me gigabit speeds. But for some reason when I run a crystal disk mark or simple file transfers, I get about 80MBps read and about 30MBps write via SMB shares. Is my CPU the bottleneck? Should I have a different type of share? Without parity, I would expect it to saturate a gigabit connection. CPU: Intel® Celeron® Processor J6413, 1.5M Cache, 4cores, up to 3.00 GHz RAM: 16GB DDR4 Hard Drive: WD Red Plus 6TB CMR Motherboard: CWWK J6413 nas motherboard, with 6 sata ports (sata 1 is native, the others are through a JMB585 expansion chip) Newest version of Unraid downloaded today. Any suggestions?
whiterook6
Members
-
Joined
-
Last visited