Koenig
-
Posts
74 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Koenig
-
-
9 minutes ago, itimpi said:
There have been reports that the Mover Tuning plugin can cause the Mover button to not work. Not sure about the other issue but you could try booting in Safe Mode to see if any other plugin is causing an issue.
Will try.
The thing is it ran just beatifully until I had a powerout (I wrote crash earlier, but it was actually a powerout), after it rebooted it was starting to go slow, it's like 15-25 seconds after I push anything or change tab, sometimes the browser (chrome) opens a popup that says the website has become unresponsive ans ask if I wish to wait or something else.
VM's and dockers works just fine anyway, it just annoying when it is that slow you know....
-
Hi!
My servers web-UI became very slow after a crash and I can't figure out why, I have tried rebooting it several times with no luck.
It's been like this for a couple of weeks everything else works so due to lack of time it has just been running anyway, until today I also noticed that it won't respond to me manually invoking the mover (via the button) thinking it might be related.
It might also be 2 issues.
Anyway I attched my diagnostics and hope this great community can come up with what my problem is.
-
30 minutes ago, dlandon said:
Can you updatde the 6.11.5 server to 6.12?
It will eventually get updated, but probably not until there´s a 6.12.1 stable.
If that is the only course of action we have to wait, it is not like I will forget the issue anyway as there's plenty to remind me in the log
-
7 hours ago, dlandon said:
I'm seeing this in the log:
Apr 29 07:15:56 NAS rpc.mountd[6334]: v4.0 client detached: 0x602ff7716405b917 from "192.168.8.30:702" Apr 29 07:18:05 NAS kernel: CIFS: VFS: \\UNRAID\ISOs BAD_NETWORK_NAME: \\UNRAID\ISOs ### [PREVIOUS LINE REPEATED 9 TIMES] ### Apr 29 07:18:19 NAS ool www[4016]: Successful logout user root from 192.168.8.120 Apr 29 07:18:19 NAS kernel: CIFS: VFS: \\UNRAID\ISOs BAD_NETWORK_NAME: \\UNRAID\ISOs ### [PREVIOUS LINE REPEATED 14 TIMES] ### Apr 29 07:18:43 NAS webGUI: Successful login user root from 192.168.8.120 Apr 29 07:18:44 NAS kernel: CIFS: VFS: \\UNRAID\ISOs BAD_NETWORK_NAME: \\UNRAID\ISOs ### [PREVIOUS LINE REPEATED 6 TIMES] ###I'm not sure what this means, but the workgroup on your servers is not the same. Unraid is ToK, NAS is TOK. Windows doesn't care about the case because it is always upper case in Windows. Linux may deal with it differently though because of the case difference.
Unfortunately me changing this so the setting says "ToK" on both servers didn't help, lines like the ones below continue to come frequently:
May 4 02:28:55 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:1182285 May 4 02:54:55 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:1291108 May 4 02:57:00 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:1299810 May 4 02:58:02 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:1304178 May 4 03:17:17 Unraid kernel: CIFS: VFS: \\192.168.8.25\Backups Close unmatched open for MID:1384761 -
6 minutes ago, dlandon said:
I'm seeing this in the log:
Apr 29 07:15:56 NAS rpc.mountd[6334]: v4.0 client detached: 0x602ff7716405b917 from "192.168.8.30:702" Apr 29 07:18:05 NAS kernel: CIFS: VFS: \\UNRAID\ISOs BAD_NETWORK_NAME: \\UNRAID\ISOs ### [PREVIOUS LINE REPEATED 9 TIMES] ### Apr 29 07:18:19 NAS ool www[4016]: Successful logout user root from 192.168.8.120 Apr 29 07:18:19 NAS kernel: CIFS: VFS: \\UNRAID\ISOs BAD_NETWORK_NAME: \\UNRAID\ISOs ### [PREVIOUS LINE REPEATED 14 TIMES] ### Apr 29 07:18:43 NAS webGUI: Successful login user root from 192.168.8.120 Apr 29 07:18:44 NAS kernel: CIFS: VFS: \\UNRAID\ISOs BAD_NETWORK_NAME: \\UNRAID\ISOs ### [PREVIOUS LINE REPEATED 6 TIMES] ###I'm not sure what this means, but the workgroup on your servers is not the same. Unraid is ToK, NAS is TOK. Windows doesn't care about the case because it is always upper case in Windows. Linux may deal with it differently though because of the case difference.
Nice catch, changed it too see if it matters.
-
1 hour ago, dlandon said:
By your screen shot, you're on 6.11.5. This post is about 6.12.0-rc5.
Move your post to the UD forum, post diagnostics again and we'll carry on there.
Yeah, the screenshot is from a unraid-server running 6.11.5 that is the one that contains the share that I'm mounting on one with unraid 6.12.0-rc5, wich is the one that is throwing CIFS-lines in the log.
Attaching diagnostics from both servers.
"unraid" runs RC5, "nas" runs 6.11.5 (stable)
A courious thing here is that "nas" (stable) also have a mounted SMB-share from "unraid" but is not throwing those errors into the log, while "unraid" (RC5) has a mounted share and thows a lot of those lines in the log
EDIT: Fixed the quote.
nas-diagnostics-20230503-2019.zip unraid-diagnostics-20230503-2019.zip
-
Hi!
Is it possible to change the flashdrive while the server is online?
Just got a dreadded message that a key is missing and that the flash-drive probably are corrupt, but the array and everything is working as is should for now.
So is there a way to change the flash-drive while the system still is "live"?
-
1 minute ago, ljm42 said:
Woohoo! And I see that the unraid-api is running fine, you didn't have to do anything manually for that right?
No that diagnostics was the second thing I did with the server after the reboot. (the first thing was to start the VM "Daily-driver", via my mobile phone, wich is my "daily-use-computer")
-
1
-
-
28 minutes ago, ljm42 said:
Thanks.
I'm not sure if this is causing the issue with diagnostics, but your syslog is full of messages like this:
PAM unable to dlopen(/lib64/security/pam_unix.so): /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/libresolv.so.2)This is caused by the UD Preclear plugin:
https://forums.unraid.net/topic/120567-unassigned-devices-preclear-a-utility-to-preclear-disks-before-adding-them-to-the-array/page/6/#comment-1147509Yes, I was aware of this and was thinking of mentioning it, I just hadn't rebooted due to an ongoing parity-check.
The parity-check was on 96% or something like that so I "forced" it, and I have now rebooted.
Guess what....
It now works to create the diagnostics via the "Tools".
EDIT: I would like to give a big thanks to you guys, this community is amazing!!
-
1
-
-
16 minutes ago, ljm42 said:
Hmm. Can you show me a screenshot of what happens when you try to collect diagnostics using the webgui?
Also, what happens if you run this in a web terminal:
diagnosticsVia the web-terminal it creates a diagnostics-file, but if I use the the "tool" it doen't create a file.
The file ending in 35 is the one created via web-terminal, the one ending in 41 just doesn't get created.
unraid-diagnostics-20220727-1935.zip
-
Now I'm able to login.
So that looks OK, but I still cannot create a diagnostics...
Though that might be anothr matter.
-
1
-
-
root@Unraid:~# /etc/rc.d/rc.unraid-api install API has been running for 1s and is in "production" mode!-----UNRAID-API-REPORT-----> SERVER_NAME: Unraid ENVIRONMENT: production UNRAID_VERSION: 6.10.3 UNRAID_API_VERSION: 2.49.2 (running) NODE_VERSION: v14.15.3 API_KEY: invalid MY_SERVERS: signed out CLOUD: API key is missing RELAY: disconnected MINI-GRAPH: disconnected ONLINE_SERVERS: Unraid OFFLINE_SERVERS: HAS_CRASH_LOGS: no </----UNRAID-API-REPORT----->-
1
-
-
root@Unraid:~# ls -al /usr/local/sbin/unraid-api lrwxrwxrwx 1 root root 36 Jul 27 18:31 /usr/local/sbin/unraid-api -> /usr/local/bin/unraid-api/unraid-api root@Unraid:~# ls -al /usr/local/bin/unraid-api/ /bin/ls: cannot access '/usr/local/bin/unraid-api/': No such file or directory-
1
-
-
4 minutes ago, ljm42 said:
This means the install did not complete. Please uninstall the My Servers plugin (if the plugin is listed as being installed), then reinstall, making sure to let the plugin install run to completion.
Unraid 6.11 has a feature where plugin installs will continue in the background so this shouldn't be an issue going forward.
Well it says the same for me, but if you check the logs I attached you can see that the installation was completed.
-
1
-
-
7 minutes ago, ljm42 said:
Super helpful, the log shows that the plugin absolutely finished installing, so that is not the issue.
Would you please open a web terminal and run these two commands, then paste the results here?
unraid-api report -v php /usr/local/emhttp/plugins/dynamix/include/UpdateDNS.php -vroot@Unraid:~# unraid-api report -v bash: unraid-api: command not found root@Unraid:~# php /usr/local/emhttp/plugins/dynamix/include/UpdateDNS.php -v (Output is anonymized, use '-vv' to see full details) Unraid OS 6.10.3 with My Servers plugin version 2022.07.26.1609 ⚠️ Not signed in to Unraid.net Use SSL is auto ✅ Rebind protection is disabled for myunraid.net Response (HTTP 406): null Error: Nothing to doAnd I can't sign in to unraid.net, it just never gets to any login page....
-
8 minutes ago, ljm42 said:
Sorry to hear it. Please see my post right above yours
Hope this helps.
EDIT: The image is taken after uninstall/reinstall.
-
Same for me.
+ I can't create a diagnostics to attach to this post, it just says "Downloading" but nothing happens and this file - "/logs/unraid-diagnostics-20220727-1817.zip" does not exist on the flash.
-
On 12/20/2021 at 7:38 PM, JorgeB said:
Again sounds like a board/BIOS problem, try the new BIOS.
As an update to this thread:
I ran a memtest, only one pass, and it was OK.
So I went ahead and updated the BIOS again, and right now I am at 15 days uptime, which is a record, lets hope I didn't jinx it with this post
At the same time as I updated the BIOS I also changed a setting that disabled the system from booting from one of the disks attached to my HBA-card (this also cut boot-times as the HBA card does not do it's own boot-thing any more)
So I'm not sure wich of this actually was causing my issues, but hopefully this issue is solved now.
-
On 12/19/2021 at 1:53 PM, JorgeB said:
It should, make sure it's running the latest BIOS, if not it's a board problem, that setting, if implemented correctly, is enough to solve the C-states issue, avoiding the need to completely disabling them.
But it didn't, and yes when i changed the setting to what was recommended in that post you linked to, I had the latest BIOS (I updated just prior to changeing that setting), although now there's a newer BIOS.
But I realized today that disabling the C-states is not really an option, the power consumption of the server vent up like a 100W when I disabled the C-states, I think from the attached image you can determine the time pretty accurate as to when I reboot with the C-states disabled.
I took a photo of the screen at one of the crashes as well if that could of any help I'll atttach that as well.
-
1 hour ago, JorgeB said:
You don't need to disable C-states, just set the correct power supply idle control.
Sorry for not remembering the name of the setting right, but that is exactly the setting I meant when I wrote "powerline"-setting, so I have already tried that and it did not solve the problem, I changed that setting a couple of months ago and I still have had the system go unresponsive to the point where I have to make hard reset, with a maximum uptime of 14 days.
+ That was the exact post I was reffering to in my previous post.
The lockups are the root of my problem, but now that I have disabled global C-states (to try if that helps with the lockups) my Windows VM's performance i so slow it is unbearable so any help in understanding why that is and if there's anything to do about it would be much appreciated.
-
Hi!
I have a Ryzen 3970X on a Gigabyte TRX40 Aorus Xtreme with 128GB Samsung ECC.
I have problems with random "crashes" where the system becomes totally unresponsive and i cannot find anything in the logs (I have a separate sys-log server).
When I bulit the system some 18months ago I did run a 48hr memtest without no errors, the system has been unstable ever since the build. The "crashes" are very intermittent, but always happen within 14 days after a system restart (can be 1 day, can be 13).
I found some post here on the forum saying some Ryzens have som bug that can cause craches, and in these cases a powerline setting can fix the problem and sometimes one have to disable the global C-states.
So I tried the powerline setting for a while but it did not help, so today I decided to test to disable the global C-states, but that had a very negative effect on my Windows VM's, they got really bad performance wise, and each machine takes about a 100% of a thread in the system constantly and the machines themselves are very "laggy".
Does anybody know if there is a way to fix this?
-
On 5/29/2021 at 3:57 PM, ulisses1478 said:
Do you have 2 monitors connected? Can you check if your VM still works like connecting with ssh or something like this?
I have this issue as well.
I have two monitors attached to a Nvidia 2070 Super.
The VM becomes unresponsive when this happens, it is a Windows VM and i have tried to used remote desktop when it happens but it doesn't seem to connect (says configuring session or something like that the whole time until I aborts it), also a noraml shutdown doesn't work but a forced one does.
-
For a long time WINS-server has worked for me by adding "wins support = yes" in the "SMB Extras" section, but after I upgraded from 6.8.3 to 6.9.2 I keep getting this in my log:
May 26 08:31:54 NAS nmbd[15831]: process_name_registration_request: unicast name registration request received for name SAMSUNG_6260ND<20> from IP 192.168.8.65 on subnet UNICAST_SUBNET. Error - should be sent to WINS server May 26 08:33:27 NAS nmbd[15831]: [2021/05/26 08:33:27.527778, 0] ../../source3/nmbd/nmbd_incomingrequests.c:170(process_name_refresh_request) May 26 08:33:27 NAS nmbd[15831]: process_name_refresh_request: unicast name registration request received for name DAILY-DRIVER<20> from IP 192.168.8.205 on subnet UNICAST_SUBNET. May 26 08:33:27 NAS nmbd[15831]: [2021/05/26 08:33:27.527875, 0] ../../source3/nmbd/nmbd_incomingrequests.c:173(process_name_refresh_request) May 26 08:33:27 NAS nmbd[15831]: Error - should be sent to WINS server May 26 08:33:32 NAS nmbd[15831]: [2021/05/26 08:33:32.051536, 0] ../../source3/nmbd/nmbd_incomingrequests.c:170(process_name_refresh_request) May 26 08:33:32 NAS nmbd[15831]: process_name_refresh_request: unicast name registration request received for name DAILY-DRIVER<00> from IP 192.168.8.205 on subnet UNICAST_SUBNET. May 26 08:33:32 NAS nmbd[15831]: [2021/05/26 08:33:32.051696, 0] ../../source3/nmbd/nmbd_incomingrequests.c:173(process_name_refresh_request) May 26 08:33:32 NAS nmbd[15831]: Error - should be sent to WINS server May 26 08:33:36 NAS nmbd[15831]: [2021/05/26 08:33:36.571248, 0] ../../source3/nmbd/nmbd_incomingrequests.c:170(process_name_refresh_request) May 26 08:33:36 NAS nmbd[15831]: process_name_refresh_request: unicast name registration request received for name TOK<00> from IP 192.168.8.205 on subnet UNICAST_SUBNET. May 26 08:33:36 NAS nmbd[15831]: [2021/05/26 08:33:36.571325, 0] ../../source3/nmbd/nmbd_incomingrequests.c:173(process_name_refresh_request) May 26 08:33:36 NAS nmbd[15831]: Error - should be sent to WINS server May 26 08:33:51 NAS nmbd[15831]: [2021/05/26 08:33:51.694575, 0] ../../source3/nmbd/nmbd_incomingrequests.c:211(process_name_registration_request) May 26 08:33:51 NAS nmbd[15831]: process_name_registration_request: unicast name registration request received for name SAMSUNG_6260ND<00> from IP 192.168.8.65 on subnet UNICAST_SUBNET. Error - should be sent to WINS serverAnyone know if the support for WINS has been removed or if something else has changed that break this?
(I use WINS only to get name resolution when connecting to my network via VPN, so if there's another way to get that working I would be thankful for some tips on how to do that.)
-
Moved to General support.
Web-UI very slow
in General Support
Posted
I never found a solution to this, so I have lived with it up until today when I updated the "unraid-api-plugin", so I guess that was the culprit somehow.
Now everything is snappy again and I'm happy!