cholzer

Maybe someone else can use this too. I have the Tailscale Docker running on Unraid (192.168.1.5). On Unraid I also run Plex as Docker with its IP set to 192.168.1.6. To access that Plex Docker through the Tailscale node simply add the following to the "UP-FLAGS" field in the Tailscale Docker. --advertise-routes=192.168.1.6/32 Now u can access Plex by its IP 192.168.1.6 remotely through the Unraid Tailscale node. I also recommend to enable the advanced view on the Tailscale docker and then add to the Extra Parameters. --restart=unless-stopped

*BUMP* how can we disable that warning?

My log looks like this: Sep 26 07:05:57 NAS kernel: vethbf83a3e: renamed from eth0 Sep 26 07:05:58 NAS kernel: eth0: renamed from veth9c122b6 Sep 26 07:06:01 NAS kernel: veth9c122b6: renamed from eth0 Sep 26 07:06:02 NAS kernel: eth0: renamed from vethc115e45 Sep 26 07:06:05 NAS kernel: vethc115e45: renamed from eth0 Sep 26 07:06:07 NAS kernel: eth0: renamed from veth8833121 Sep 26 07:06:10 NAS kernel: veth8833121: renamed from eth0 Sep 26 07:06:13 NAS kernel: eth0: renamed from vethfcb7b12 Sep 26 07:06:16 NAS kernel: vethfcb7b12: renamed from eth0 Sep 26 07:06:23 NAS kernel: eth0: renamed from veth1941e91 Sep 26 07:06:26 NAS kernel: veth1941e91: renamed from eth0 Sep 26 07:06:39 NAS kernel: eth0: renamed from veth3a3e044 Sep 26 07:06:43 NAS kernel: veth3a3e044: renamed from eth0 Sep 26 07:07:09 NAS kernel: eth0: renamed from veth13b5a96 Sep 26 07:07:11 NAS kernel: veth13b5a96: renamed from eth0 Sep 26 07:08:03 NAS kernel: eth0: renamed from veth2a876ee Sep 26 07:08:06 NAS kernel: veth2a876ee: renamed from eth0 Sep 26 07:09:06 NAS kernel: eth0: renamed from veth56008ba Sep 26 07:09:09 NAS kernel: veth56008ba: renamed from eth0 Sep 26 07:10:10 NAS kernel: eth0: renamed from veth5587952 Sep 26 07:10:13 NAS kernel: veth5587952: renamed from eth0 Sep 26 07:11:13 NAS kernel: eth0: renamed from veth21b20a6 Sep 26 07:11:16 NAS kernel: veth21b20a6: renamed from eth0 Sep 26 07:12:16 NAS kernel: eth0: renamed from veth4e69dbb Sep 26 07:12:19 NAS kernel: veth4e69dbb: renamed from eth0 I dont remember having seen this in the past. Only thing i changed resently was switching docker from macvlan to ipvlan - reason for this switch was that I still encountered crashes with macvlan in 6.12.4 //edit - this was caused by a docker container being stuck in an endless restart loop

The AppleTV is the only device which accesses my Plex Server and the transcoding is audio only as Video is direct streamed (Apple still refuses to support TrueHD / DTS-HD). So I thought that 8GB should be enough for this. But I have increased it to 16GB now. I wonder why Plex Server does not clean up after itself. However previously I have noticed that the transcode folder rarely reset in size while I was transcoding to an SSD. I always manually deleted the folder once a week.

Funny problem, Plex on my AppleTV complains that there is not enough disk space to transcode. And indeed, the ram disk it is full. Filesystem Size Used Avail Use% Mounted on tmpfs 8.6G 8.5G 107M 99% /tmp/PlexRamScratch Shouldnt Plex clean up old transcode files?

I upgraded to 6.12.4 last week, today I found this in the log. It looks like my Code Server docker container is dead now, while the other containers are still working. //edit okay, recreating the docker.img & restoring the containers was surprisingly easy. Why did this happen tho?

yeah just tried it on a 2nd system here, same GPU, doesnt occur. odd that it worked prior to upgrading to 6.12.4, but, well. not that much of an problem 😄

If this was a baremetal system, any idea where I could start to look why it switches the GUI output to the Nvidia GPU after Unraid finished booting up even though disable_xconfig=true ?

previously an intel 9700k iPGU, last weekend I moved the whole Unraid system to run under proxmox. after that move the GUI still worked nicely inside the proxmox console. today I made the upgrade and now I only get a blackscreen then the GPU is passed through. hardware transcoding in plex also works nicely, only the GUI doesnt work anymore. when I remove the GPU then the GUI works again.

NVIDIA Driver I have an GTX1050 for Plex transcoding. I just upgraded from 6.11.5 to 6.12.4 - and now I dont get a GUI anymore - after the boot I just see a blackscreen weblogin works fine. I checked config\plugins\nvidia-driver\settings.cfg first_installation=false driver_version=latest disable_xconfig=true update_check=true No change there. So it should work. Is there a problem with 6.12.4 ?

LOL, okay - I wondered if commands had changed in the new version. I misunderstood the description. 😅 I did then use the old commands from my cheat sheet with which i could set it up as usual. I only started it, then I noticed the error in the log. After another restart it seems to have updated. 😃 ---BattleNetPrefill v1.6.1 up-to-date---

Just did a clean install of LanCache Prefill on a new machine. After the setup I ran: su $USER cd ${DATA_DIR}/(BattleNet|Epic|Steam)Prefill which resulted in: bash: syntax error near unexpected token `(' I then looked in the logfile where I noticed this: ---Version missmatch, installed v1.5.0, downloading and installing latest v1.6.1...--- ---Something went wrong, can't download BattleNetPrefill v1.6.1, putting container in sleep mode---

Thank you! Now I can shutdown Unraid from inside the proxmox webinterface!

@jonp can you tell us the current state of SMB Multichannel? Did anything change since this blog post? https://unraid.net/blog/how-to-beta-test-smb-multi-channel-support

Thx! I will wait for this release to reach stable status and then maybe a week or two before I upgrade.

I have containers that need to have a static IP on my main LAN. If I get this right, switching to ipvlan would no allow this, right? The ipvlan type is best when connection to the physical network is not needed Also what is broken with macvlan that I have to switch? Or what causes this issue in the first place?

For about 4 weeks now I get this about every 2 to 3 days in the log. The system itself continues to work though, nothing obvious "breaks, stops or freezes". Aug 24 23:19:07 NAS kernel: ------------[ cut here ]------------ Aug 24 23:19:07 NAS kernel: WARNING: CPU: 2 PID: 19856 at net/netfilter/nf_conntrack_core.c:1208 __nf_conntrack_confirm+0xa5/0x2cb [nf_conntrack] Aug 24 23:19:07 NAS kernel: Modules linked in: xt_CHECKSUM ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat xt_nat xt_tcpudp iptable_mangle vhost_net tun vhost vhost_iotlb tap veth macvlan xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter xfs nfsd auth_rpcgss oid_registry lockd grace sunrpc md_mod tcp_diag inet_diag ip6table_filter ip6_tables iptable_filter ip_tables x_tables bridge stp llc ixgbe xfrm_algo mdio e1000e i915 iosf_mbi drm_buddy i2c_algo_bit x86_pkg_temp_thermal ttm intel_powerclamp coretemp drm_display_helper kvm_intel drm_kms_helper drm kvm i2c_i801 crct10dif_pclmul input_leds crc32_pclmul wmi_bmof mxm_wmi crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd cryptd rapl intel_cstate intel_uncore i2c_smbus joydev led_class intel_gtt nvme agpgart i2c_core nvme_core ahci syscopyarea libahci sysfillrect sysimgblt fb_sys_fops tpm_crb tpm_tis tpm_tis_core video thermal fan wmi Aug 24 23:19:07 NAS kernel: backlight tpm acpi_pad button unix [last unloaded: xfrm_algo] Aug 24 23:19:07 NAS kernel: CPU: 2 PID: 19856 Comm: kworker/2:2 Not tainted 5.19.17-Unraid #2 Aug 24 23:19:07 NAS kernel: Hardware name: System manufacturer System Product Name/ROG STRIX Z370-E GAMING, BIOS 3005 09/30/2021 Aug 24 23:19:07 NAS kernel: Workqueue: events macvlan_process_broadcast [macvlan] Aug 24 23:19:07 NAS kernel: RIP: 0010:__nf_conntrack_confirm+0xa5/0x2cb [nf_conntrack] Aug 24 23:19:07 NAS kernel: Code: c6 48 89 44 24 10 e8 dd e2 ff ff 8b 7c 24 04 89 da 89 c6 89 04 24 e8 56 e6 ff ff 84 c0 75 a2 48 8b 85 80 00 00 00 a8 08 74 18 <0f> 0b 8b 34 24 8b 7c 24 04 e8 16 de ff ff e8 2c e3 ff ff e9 7e 01 Aug 24 23:19:07 NAS kernel: RSP: 0018:ffffc90000170cf0 EFLAGS: 00010202 Aug 24 23:19:07 NAS kernel: RAX: 0000000000000188 RBX: 0000000000000000 RCX: abd8a9687e187a16 Aug 24 23:19:07 NAS kernel: RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa0273140 Aug 24 23:19:07 NAS kernel: RBP: ffff8881092ebf00 R08: 3a435c8f350d0ebe R09: 4ca5bad75056aacb Aug 24 23:19:07 NAS kernel: R10: 5565a652dd6ba82b R11: 629a3762be45c08e R12: ffffffff82909480 Aug 24 23:19:07 NAS kernel: R13: 0000000000014290 R14: ffff8882803b2400 R15: 0000000000000000 Aug 24 23:19:07 NAS kernel: FS: 0000000000000000(0000) GS:ffff888426c80000(0000) knlGS:0000000000000000 Aug 24 23:19:07 NAS kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Aug 24 23:19:07 NAS kernel: CR2: 0000150ccfa6e740 CR3: 000000000220a005 CR4: 00000000003706e0 Aug 24 23:19:07 NAS kernel: Call Trace: Aug 24 23:19:07 NAS kernel: <IRQ> Aug 24 23:19:07 NAS kernel: nf_conntrack_confirm+0x25/0x54 [nf_conntrack] Aug 24 23:19:07 NAS kernel: nf_hook_slow+0x3a/0x96 Aug 24 23:19:07 NAS kernel: ? ip_protocol_deliver_rcu+0x164/0x164 Aug 24 23:19:07 NAS kernel: NF_HOOK.constprop.0+0x79/0xd9 Aug 24 23:19:07 NAS kernel: ? ip_protocol_deliver_rcu+0x164/0x164 Aug 24 23:19:07 NAS kernel: ip_sabotage_in+0x47/0x58 [br_netfilter] Aug 24 23:19:07 NAS kernel: nf_hook_slow+0x3a/0x96 Aug 24 23:19:07 NAS kernel: ? ip_rcv_finish_core.constprop.0+0x3b7/0x3b7 Aug 24 23:19:07 NAS kernel: NF_HOOK.constprop.0+0x79/0xd9 Aug 24 23:19:07 NAS kernel: ? ip_rcv_finish_core.constprop.0+0x3b7/0x3b7 Aug 24 23:19:07 NAS kernel: __netif_receive_skb_one_core+0x77/0x9c Aug 24 23:19:07 NAS kernel: process_backlog+0x8c/0x116 Aug 24 23:19:07 NAS kernel: __napi_poll.constprop.0+0x28/0x124 Aug 24 23:19:07 NAS kernel: net_rx_action+0x159/0x24f Aug 24 23:19:07 NAS kernel: __do_softirq+0x126/0x288 Aug 24 23:19:07 NAS kernel: do_softirq+0x7f/0xab Aug 24 23:19:07 NAS kernel: </IRQ> Aug 24 23:19:07 NAS kernel: <TASK> Aug 24 23:19:07 NAS kernel: __local_bh_enable_ip+0x4c/0x6b Aug 24 23:19:07 NAS kernel: netif_rx+0x52/0x5a Aug 24 23:19:07 NAS kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Aug 24 23:19:07 NAS kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan] Aug 24 23:19:07 NAS kernel: process_one_work+0x1a8/0x295 Aug 24 23:19:07 NAS kernel: worker_thread+0x18b/0x244 Aug 24 23:19:07 NAS kernel: ? rescuer_thread+0x281/0x281 Aug 24 23:19:07 NAS kernel: kthread+0xe4/0xef Aug 24 23:19:07 NAS kernel: ? kthread_complete_and_exit+0x1b/0x1b Aug 24 23:19:07 NAS kernel: ret_from_fork+0x1f/0x30 Aug 24 23:19:07 NAS kernel: </TASK> Aug 24 23:19:07 NAS kernel: ---[ end trace 0000000000000000 ]--- 2 days ago I transplanted all harddisks into a new system (different mainboard, CPU and RAM). But as you can see above I got the same problem yesterday night. Anyone an idea what could cause this or what this error actually means? It looks kinda severe? System is still on Version: 6.11.5 - I usually always wait for a few months before upgrading to a new major release for stability.

Bei mir war ein "m.2 zu 4x SATA" Adapter verantwortlich für die Fehlermeldung im Unraid Log. "pcie_aspm=off" hat das nun gelöst.

I just ran into this with an m.2 to 4x SATA adapter card. pci=nommconf did not work, but adding pcie_aspm=off to the conf did work. Thank you!

I have run into this recently as well, anyone an idea what is going on?

hmm... so what is the meaning of this line in unraids syslog? May 21 07:10:01 NAS root: /usr/local/sbin/powerdown has been deprecated

yeah I thought about adding another script that is activated on "at stoping of array", but I would like to avoid the issue alltogether - lets see how my new approach does.

I might have figured it out. DISKS WHICH STAY BUSY: according to the syslog its cache2nvme and cache3nvme that appear to stay busy on shutdown, which could lead to the forced shutdown. THAT RANG A BELL: I run a seperate log-server pc to collect all kinds of logs (docker, syslog, smartmeter, ....). On that log-server promtail is used as remote syslog server to collect syslogs and write it to Grafana / Loki. In the extra parameters of all my Unraid dockers I use: --log-driver=syslog --log-opt tag="Docker_{{.Name}}" --log-opt syslog-format=rfc5424 --log-opt syslog-address=udp://192.168.1.2:40515 UDP is used because if you use TCP and the remote syslog server is down, then the docker container will FAIL TO START. This is an issue in the docker logging driver itself (not unraid's fault!)- there are many threads and issues on github about this in various projects, also affects other remote logging targets/drivers. But I digress:) So with that parameter I ensure that all docker logs get send to my log-server.... well... almost.... There are a couple of problems: the syslog server in promtail only supports RFC5424 - UNRAID DOES NOT USE THAT FORMAT FOR ITS REMOTE SYSLOG SERVER!!!! And so no data is collected. I could not find a way to get unraid to send its syslog using that format. some dockers (plex, LanCache, LanCache_prefill,...) write additional logfiles onto the unraid filesystem, which cant be sent through the docker syslog driver - I need these logs for error alerts / troubleshooting. To fix these issues I installed promtail locally on the unraid machine, and launched it with a userscript when the array starts. Promtail then tailed the unraid syslog as well as the logs from Plex, LanCache, LanCache_prefill, .. and sent them directly into the Loki database on the log-server. This worked great!!! 😃 Well, apparently that caused a new issue as it seems - because when you shut down or restart unraid, promtail does not get killed - which in return then leads to the cache2nvme and cache3nvme to stay busy and cause an unclean shutdown. SO...... WHAT NOW? I removed the local installation of promtail from unraid as that kept the cache2nvme and cache3nvme busy I installed the grafana_promtail docker on unraid and have that tail the local logs of Plex, LanCache, LanCache_prefill, .. sending these directly to my log-server I do not have it tail unraid's syslog - that would be useless as I dont get any logs when docker isnt running So since for some unknown reason Unraid cant be configured to use the RFC5424 format for sending its syslog to a remote-syslog server, I had to configure a syslog-relay on my log-server and have that do the format conversion to RFC5424....... 🙄 Fingers crossed that this fixes the issue. Thank you for your help guys!

if that really causes the issue then i wonder why it would trigger a parity check as that isnt needed when the array was stopped okay. i will look into this closer.

what if cache disks stay busy? could that trigger a unclean shutdown and parity sync even tho the array itself was stopped correctly? i have seen a message that one of the cache drives was busy a couple of times in the logs.