All Activity

Was it memory? i'm having the same issue.

It happen again and now I've disable SSL as you recommend.

Please remove the exclussion pattern and give it a minute to check if that works, also, try with the refresh interval enabled; please let me know if any of those options help you with problem, otherwise i'll send you a dm to start debugging the error.

Possible yes should you IMHO no. If you did, i would recommend the deny host plugin. Unraid IMHO is not true enterprise grade software. Its slow to implement security and patches. Some changes due to repositories and packages they use are not always fully up to date. For this reason, I would not trust this system to be a forward facing machine. Is it capable to do so yes.

may remove this entry and while you setup your app, when you enter the URL, may add https://files.... the error says your app trys http instead https

Ok, so first thing is… can I install unraid to a HDD? I am using a Dell R720 and would like to just boot off the HDD so I don’t have to “interrupt” the boot sequence and force it to boot from the flash drive every time I need to make an update. Now on to the burning question, I set up my flash drive on a cheap USB flash that at the time was the only drive my computer would recognize. This has been fixed and would like to use a Samsung drive if I can’t boot to HDD like I previously asked. I have TB’s of data on my unraid server that I can’t loose so if I flash a new USB flash and start using that will I loose access to all my data bc it was put on there from the old flash drive?

May be, but I haven't call-trace at different build, no matter macvtap or ipvlan. I haven't enable bonding in my setup, your vhost IP assign was on vhost0@bond0 not on vhostx.x, so would you try disable bonding ? BTW, I also try enable bonding, but haven't found it will got IP from DHCP. Due to I don't know what bonding mode you use and other different setting, so below i/f list not identical to you. 5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:1b:21:7e:5a:c4 brd ff:ff:ff:ff:ff:ff inet 192.168.9.6/21 brd 192.168.15.255 scope global dynamic noprefixroute eth0 valid_lft 467sec preferred_lft 392sec 6: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000 link/ether a8:a1:59:66:10:2c brd ff:ff:ff:ff:ff:ff 10: vhost1@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 500 link/ether 02:77:ec:ab:35:c4 brd ff:ff:ff:ff:ff:ff 19: eth0.3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:1b:21:7e:5a:c4 brd ff:ff:ff:ff:ff:ff 20: vhost0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 500 link/ether 02:08:34:0a:89:1a brd ff:ff:ff:ff:ff:ff 21: [email protected]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 500 link/ether 02:08:34:0a:89:1a brd ff:ff:ff:ff:ff:ff 22: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:fe:39:a0 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 23: macvtap0@eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 500 link/ether 52:54:00:65:73:08 brd ff:ff:ff:ff:ff:ff inet6 fe80::5054:ff:fe65:7308/64 scope link valid_lft forever preferred_lft forever You will found only real mac and the VM vmac have got IP, vhost1@eth1 & virbr0 haven;t.

This would require similar instalion that nextcloud/own cloud does, which is server side encryption. You would require some form of email/telecom voip server (irc for text). If all unraid server were connected to brokerage servers to unraid.net and management was via the unriad connect, I could see this. Otherwise one could implement this as this is a web page edit and an email code oath change.

Thank you. yes, in USA My ISP charges $15 a month extra for a static public IP. This is what my friend is on now, it it's working like before. This is something I will have to do eventually.

looks like eth0 via br0 is youur mac that you should be using in teh router for dhcpo static mac adress asigment please confirm that mac ac:15:a2:85:1d:0f uis set to static ip of 192.168.1.180

Let me clear up the confusions. First, I have and always have had the system running in MACVLAN mode. The actual problem is the primary NIC VHOST (vhost0) is being assigned the same IP as the primary NIC. The primary NIC and vhost0 each have unique MAC addresses. As such, the network has two systems with different MAC addr using the same IP addr. The cherry in top being both systems are plugged into the same physical network port! This behavior has only cropped up since implementing the workaround to allow MACVLAN without the call-trace lock ups. What's really confusing to me is if you search online for "Linux, MACVLAN, call trace" all that comes up are UnRaid reports. Even the bug report for the Linux kernel was made by limetech. There are no other reports by anyone else about this behavior. So it seems to me that this is an UNRaid specific issue. I have other Linux systems running Docker with MACVLAN networks that have never had a call trace lock up. So why are we seeing this happen on UNRaid systems?

I see. I was hoping the mover would always just move to the correct disk based on its current share regardless of its originating share. Sounds like that Caution section explains why that isn't possible (although I don't fully understand it... but that's neither here nor there) Thanks for the help. I managed to update and adjust the script to get it working all within the same share. That error *should* probably be updated and clarified if possible though so maybe I'll try to report that suggestion.

Try rebooting your server to clear out the RAM or running echo 3 > /proc/sys/vm/drop_caches and echo 1 > /proc/sys/vm/compact_memory in a terminal. Then let it sit with the 96 GB Win 11 VM for a few hours and see if your Win 10 VM will start. I had this exact behavior, the memory fragmentation made it such that when I reduced the RAM on my Win 11 VM from 32 GB to 16 GB my other VMs would start. I think after you make that change in tips and tweaks you still need to clear everything out that built up and never got released either by running those commands or rebooting.

I'm not sure if that setting did the trick or not, but either way it sounds like those defaults were not appropriate for my use case. I tried making the changes you listed and let it sit several hours. I started my Windows 10 VM and it hung at the boot screen... so no noticeable change. I have 128GB of RAM and I originally allocated 96GB to my Windows 11 VM (with memorybacking), and 8GB to a Windows 10 VM. I dropped my Win11 VM down to 64GB and now Win10 boots without any issues. So I guess even though I had plenty of memory to go around, something wasn't playing nice. Not sure if maybe I needed to reboot my Win11 VM after changing the two settings you mentioned for it to take effect. Maybe I'll try out a few other memory combinations tomorrow to see if I can reproduce the hanging behavior of my Win10 VM.

Apparently this is a confirmed bug, I didn't search back far enough in the forum before posting:

Apologies in advance for yet another plex transcoding thread. I read a bunch of them and didn't find anything that addresses my issue. I just recently added a P2000 to my system, primarily to provide additional horsepower while processing A LOT of files using TDARR. TDARR setup went fine. I added the Nvidia driver plugin, added the Nvidia variables, selected the Nvidia plugin within TDARR. It has been chugging for over a week and has already saved me over a terabyte. Up till now, the iGPU in my i5-12500 has been more than adequate for my modest plex transcoding needs. In fact, I still plan on using the iGPU with plex, but I thought I would try setting up the P2000 just so I have the option. First, I tried selecting the P2000 in Plex transcoder settings without any additional config changes to the plex docker. In this case, Plex continued playback normally but it did revert to CPU transcoding. This was somewhat expected as I hadn't added any of the nvidia specific variables to my Plex config. I then completed the Nvidia config for the Plex docker, adding the extra parameter, both variables, and checking for spaces... basically everything I read in all the other threads. After this I tried to force another transcode and playback simply stopped. Cycling the play/pause button in the playback did nothing, and after a few minutes the title disappears from the dashboard. Of course I tried with several other files all with the same result. Again, playback just stopped. In the dashboard, network and CPU dropped off immediately as if I had stopped playback. Plex was not frozen as I could still navigate the UI and even play direct play files. All I have to do is select the iGPU inside plex and it takes over the HW transcoding just fine. Clearly something changed when I added the nvidia variables to the plex docker since it didn't revert to CPU transcoding as before. Any idea why the P2000 isn't picking up the transcode as it should? Don't know if it is significant, but I am using the Plex Official docker container.

Thank you for getting back to me @SimonF. Much appreciated. I am almost certain that I have tried them all but have no issues doing that again. I will get back to you with my findings.

Hm das überlege ich mir nochmal ob ich das will. Aktuell hab ich mir meine Fotos quer in Immich eingespielt, aber damit bin ich auch noch nicht so zufrieden. Hätte eigentlich gerne das in NC genutzt... Ich werde das morgen mal testen....

ls print this: app command data dev etc init lsiopy migrations opt proc run srv tmp var bin config defaults docker-mods home lib media mnt package root sbin sys usr Now when i type ls -l: root@53abd88c5e33:/# ls -l total 32 drwxr-xr-x 1 abc abc 36 Apr 24 07:37 app drwxr-xr-x 1 root root 930 Apr 17 06:49 bin drwxr-xr-x 1 root root 5224 Apr 17 06:49 command drwxrwx--- 1 abc abc 102 Feb 16 18:20 config drwxrwx--- 1 abc abc 102 Feb 16 18:20 data drwxr-xr-x 1 abc abc 16 Apr 24 07:37 defaults drwxr-xr-x 5 root root 340 Apr 25 14:18 dev -rwxr--r-- 1 root root 23629 Dec 31 1969 docker-mods drwxr-xr-x 1 root root 1178 Apr 25 14:18 etc drwxr-xr-x 1 root root 0 Apr 17 06:49 home -rwxr-xr-x 1 root root 1012 Nov 20 09:09 init drwxr-xr-x 1 root root 1042 Apr 24 07:40 lib drwxr-xr-x 1 root root 0 Apr 17 06:49 lsiopy drwxr-xr-x 1 root root 28 Apr 17 06:49 media drwxr-xr-x 1 root root 92 Apr 24 07:37 migrations drwxr-xr-x 1 root root 0 Apr 17 06:49 mnt drwxr-xr-x 1 root root 0 Apr 17 06:49 opt drwxr-xr-x 1 root root 30 Apr 17 06:49 package dr-xr-xr-x 356 root root 0 Apr 25 14:18 proc drwx------ 1 root root 18 Apr 18 13:49 root drwxr-xr-x 1 root root 224 Apr 25 14:19 run drwxr-xr-x 1 root root 992 Apr 17 06:49 sbin drwxr-xr-x 1 root root 0 Apr 17 06:49 srv dr-xr-xr-x 13 root root 0 Apr 25 14:18 sys drwxrwxrwt 1 root root 496 Apr 25 14:15 tmp drwxr-xr-x 1 root root 68 Apr 24 07:37 usr drwxr-xr-x 1 root root 102 Apr 24 07:40 var

根据提供的诊断文件，虚拟机日志： qemu-system-x86_64: terminating on signal 15 from pid 31467 (/usr/sbin/libvirtd): QEMU进程接收到了来自pid为31467的进程的SIGTERM信号，这通常用于请求程序正常退出。来自libvirtd，这是负责管理Linux上虚拟机的守护进程。 shutting down, reason=shutdown: 虚拟机管理系统已经接收到关闭的命令。 shutting down, reason=destroyed: 虚拟机是被强制关闭的。 虚拟机在收到关闭信号时，正常响应并开始了关闭过程。但问题似乎出在虚拟机尝试进行正常关闭的过程中。 群晖虚拟机似乎没有按照预期那样自动关机。这可能是由于多种原因造成的，比如： 群晖的操作系统可能需要配置特定的脚本或设置来响应外部的关机信号。 可能有一些挂起的任务或者服务阻止了系统正常关机。 建议再尝试观察一下，或者更换群晖虚拟机启动

Edit: I dont know if this is the solution, but maybe my last paragraph here has the possible solution (I didn't find the error, just updated all my outstanding containers) Okay i had some time and tried my best, but this are the results (cannot find the cause) 1. Started the server 2. Straight the Settings and stopped the autostart of the general Docker Service 3. Waited some time, but Ram was idling at 5-10% 4. Started up the Docker Service, and immideatily disabled the autostart for most of the apps 4.1. Said apps went on and server was running at 20 %, until suddenly the RAM got up to 50,60,70,80 4.2. Started to power down some apps - still at 80 % (seemed to only slow down the process of the RAM 'growing') 4.3. Powered down all Docker Container by Stop All in the Docker View 4.4 RAM still at 97 % which does mean 30 GB of RAM (with no active apps (triple checked)) 5. Waited some time ~5min RAM was +-1% at 96-98 % 5.1. captured the following line in the process overview in the settings: root 21802 171 91.0 33754864 29626460 ? Sl 21:50 58:13 /usr/bin/dockerd -p /var/run/dockerd.pid --log-opt max-size=50m --log-opt max-file=1 --log-level=fatal --storage-driver=btrfs the 91.0 is the RAM value for this service 6. Turned of the general Docker Service 6.1. RAM dropped immediatly to 4-5 % Okay so next thing to try: I am notorius to just leave my containers on the current version and forget about updating them. Yes I know that has to change. Just updated everything and now tried to start everything one on one. Start the Docker Service and start up one container after each other with time breaks of around 5min between each! --- author's note: will send this posting when I am done doing this process - all in all it took around 3 hours---- Docker Service is started but all containers are set to do not auto start Waited 10 min and set everything one after one other to start up. Now all my Docker Containers are started up, each operating wth a reasanable amount of RAM, if something will break again I will report it back here. Possible Solution: Didn't update my containers and something there did break... Or I did something accidental that fixed the problem. Will mark the comment from JorgeB to be the solution, because impatience was not helping, and the slow but steady process was. Thank you!

To be honest, those are your assumption. We need solid founding.

Getting the same warning. Did you figure out what is causing it?

你选择的目录错误，/etc是系统配置文件的放置目录，重启后非系统文件会重置 建议选择U盘/boot/下新建目录或者共享挂载/mnt/user/X

has anyone confirm this is good?