mr-hexen Posted February 5, 2017 Share Posted February 5, 2017 Anyone else see a significant performance degradation in VM's? I have a ubuntu 16.04 vm that I use a test platform for learning linux. I always have used it via VNC and its been OK (usable), but since 3.0 its dog slow. I have 2 cores assigned, 2GB ram, Q35-2.7 (tried 2.5 and 2.6), none of these settings changed since 6.2.4. Quote Link to comment
RobJ Posted February 5, 2017 Share Posted February 5, 2017 Seems to be a bug in the nice new feature to specify the SMART device type (ATA, SATA, Areca, etc). You can now select the correct type globally and for each drive. However it starts on Automatic, which I assume should attempt to identify the correct type, but doesn't appear to be working correctly. When Settings->Disk Settings->SMART controller type is set to Automatic, all of the Smart reports are only 318 bytes, and look like this: smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.9.7-unRAID] (local build) Copyright © 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org ERROR: smartctl takes ONE device name as the final command-line argument. You have provided 2 device names: /dev/sdc Use smartctl -h to get a usage summary I can't explain the error, as I only see one device listed in each. But if I change the global setting to ATA, then all of the SMART reports are correct in the diagnostics zip. Users should probably change the global setting to ATA, then override it on each disk that requires a different setting. Quote Link to comment
nokdim Posted February 5, 2017 Share Posted February 5, 2017 What's not normal is log shows /dev/sdh1 is assigned to cache and gets mounted but then a strange entry: Feb 5 15:30:44 Nokdim-NAS preclear.disk: Resuming preclear of disk 'sdh' Something not right about that. Try booting in 'unRAID OS safe mode' and see if user shares appear. That's a Preclear bug spotted and reported to gfjardim earlier. In the earlier case, it was harmless, in that the resumed preclear was of sdp, a symbol that did not and had never existed on that user's system. In this case, you need to reboot as quickly as possible, then check whether your Cache drive has been partially cleared. I would uninstall the Preclear plugin. I removed the preclear plugin and rebooted and still dont see user shares. Also I dont care about data loss on cache drive worse comes to worse a show I had on DVR will get lost. I just want my user shares back... Try stopping the array, and selecting No Device for the cache drive and then restarting the array I stopped the array and took the cache drive out. I started the array but still no user shares. I stopped the array again and rebooted. After the reboot it is in the same state. Quote Link to comment
trurl Posted February 5, 2017 Share Posted February 5, 2017 Unless there is a way I can reboot into safe mode via a console session or the webgui. Main - Boot Device - Flash - Syslinux Configuration. Move menu default to Safe Mode and reboot. Quote Link to comment
dlandon Posted February 5, 2017 Share Posted February 5, 2017 What's not normal is log shows /dev/sdh1 is assigned to cache and gets mounted but then a strange entry: Feb 5 15:30:44 Nokdim-NAS preclear.disk: Resuming preclear of disk 'sdh' Something not right about that. Try booting in 'unRAID OS safe mode' and see if user shares appear. That's a Preclear bug spotted and reported to gfjardim earlier. In the earlier case, it was harmless, in that the resumed preclear was of sdp, a symbol that did not and had never existed on that user's system. In this case, you need to reboot as quickly as possible, then check whether your Cache drive has been partially cleared. I would uninstall the Preclear plugin. I removed the preclear plugin and rebooted and still dont see user shares. Also I dont care about data loss on cache drive worse comes to worse a show I had on DVR will get lost. I just want my user shares back... Try stopping the array, and selecting No Device for the cache drive and then restarting the array I stopped the array and took the cache drive out. I started the array but still no user shares. I stopped the array again and rebooted. After the reboot it is in the same state. Remove all plugins, reboot and add them back one at a time to find out which one is causing the problem. Quote Link to comment
nokdim Posted February 5, 2017 Share Posted February 5, 2017 I'm back to working thanks again... Quote Link to comment
RobJ Posted February 5, 2017 Share Posted February 5, 2017 What's not normal is log shows /dev/sdh1 is assigned to cache and gets mounted but then a strange entry: Feb 5 15:30:44 Nokdim-NAS preclear.disk: Resuming preclear of disk 'sdh' Something not right about that. Try booting in 'unRAID OS safe mode' and see if user shares appear. That's a Preclear bug spotted and reported to gfjardim earlier. In the earlier case, it was harmless, in that the resumed preclear was of sdp, a symbol that did not and had never existed on that user's system. In this case, you need to reboot as quickly as possible, then check whether your Cache drive has been partially cleared. I would uninstall the Preclear plugin. I removed the preclear plugin and rebooted and still dont see user shares. Also I dont care about data loss on cache drive worse comes to worse a show I had on DVR will get lost. I just want my user shares back... Try stopping the array, and selecting No Device for the cache drive and then restarting the array I stopped the array and took the cache drive out. I started the array but still no user shares. I stopped the array again and rebooted. After the reboot it is in the same state. Here's what I see, but I'm not expert enough to fully explain it. Before your server had even finished booting, vsftpd was accepting connections from multiple stations on your local network, and mkdir'ing /mnt/user and a number of shares, then apparently beginning downloads and uploads of files, with transfer speeds logged. That's not supposed to happen, because there is NO true /mnt/user file system yet, because the array hasn't started and the drives haven't mounted. So vsftpd created a bad /mnt/user in RAM, with share folders, and my guess is that those spurious folders blocked the ability of FUSE to create the true FUSE User Share system, once the array had been started and all of the drives mounted. FUSE may especially have been blocked if the bad /mnt/user/* had files in use, being transferred by vsftpd to and from 3 different stations. You'll need to find a way to disallow vsftpd from accepting connections until the array is fully started. Quote Link to comment
dlandon Posted February 6, 2017 Share Posted February 6, 2017 I'm back to working thanks again... What did you do to solve the problem so others can learn? Quote Link to comment
RobJ Posted February 6, 2017 Share Posted February 6, 2017 Here's a response from SnickySnacks that may help some users with share access issues, particularly for devices using older Samba authentication methods. I was initially going to post that my DuneHD was working, but I realized I had my shares set to "secure" not "private". To get it working in "Private" mode, add ntlm auth = yes to your samba.conf in settings -> SMB and restart samba. Howdy SnickySnacks, do you feel this may be a general answer to the problems a number of users are having accessing shares from other devices? If so, I'd like to post it more visibly. And can you add to your post how new users would restart Samba? I'm not sure it's a general answer (I was able to connect on Windows 10 in private mode regardless). It likely only affects devices that use the older NTLM1 authentication. My debugging steps went like this: Added to samba.conf: log level=2 syslog=3 reloaded config from telnet: smbcontrol smbd reload-config Saw in the syslog: "NTLMv1 passwords NOT PERMITTED for user" This indicated that my device was using the older protocol which was likely disabled for security reasons. Adding ntlm auth = yes then: smbcontrol smbd reload-config allowed the older authentication. This shouldn't make a difference for like windows 10 (which people seem to be having a problem with), but some devices that don't support NTLMv2 may require it. From the smb.conf manpage https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html ntlm auth (G) This parameter determines whether or not smbd( will attempt to authenticate users using the NTLM encrypted password response. If disabled, either the lanman password hash or an NTLMv2 response will need to be sent by the client. If this option, and lanman auth are both disabled, then only NTLMv2 logins will be permited. Not all clients support NTLMv2, and most will require special configuration to use it. Default: ntlm auth = yes Looks like unraid or a more recent samba version is defaulting this to "no". Quote Link to comment
SnickySnacks Posted February 6, 2017 Share Posted February 6, 2017 Note that you only need the ntlm auth=yes line. the log level and syslog lines are only useful for debugging Quote Link to comment
RobJ Posted February 6, 2017 Share Posted February 6, 2017 Note that you only need the ntlm auth=yes line. the log level and syslog lines are only useful for debugging Yes I should have made that clearer, was thinking of someone who had asked for ways to see debug info, thought this would help them. I may be wrong, but wasn't there advice in the 6.2 days to change a setting in Windows 10 to downgrade something involving logins, in order to make connections to unRAID servers possible in some situations? That may have backfired here, and those Win 10 stations may be trying to connect using the older ntlmv1 authentication, which may have recently been disabled in 6.3.0. (but I may be wrong!) Quote Link to comment
John_M Posted February 6, 2017 Share Posted February 6, 2017 Seems to be a bug in the nice new feature to specify the SMART device type (ATA, SATA, Areca, etc). You can now select the correct type globally and for each drive. However it starts on Auto, which I assume should attempt to identify the correct type, but doesn't appear to be working correctly. When set to Auto, all of the Smart reports are only 318 bytes, and look like this: smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.9.7-unRAID] (local build) Copyright © 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org ERROR: smartctl takes ONE device name as the final command-line argument. You have provided 2 device names: /dev/sdc Use smartctl -h to get a usage summary I can't explain the error, as I only see one device listed in each. But if I change the global setting to ATA, then all of the SMART reports are correct in the diagnostics zip. Users should probably change the global setting to ATA, then override it on each disk that requires a different setting. I agree there's a bug but for me changing the global setting to ATA results in this in the SMART reports: /dev/sdc: Unknown device type ' ata' =======> VALID ARGUMENTS ARE: ata, scsi, nvme[,NSID], sat[,auto][,N][+TYPE], usbcypress[,X], usbjmicron[,p][,x][,N], usbprolific, usbsunplus, marvell, areca,N/E, 3ware,N, hpt,L/M/N, megaraid,N, aacraid,H,L,ID, cciss,N, auto, test <======= Quote Link to comment
limetech Posted February 6, 2017 Author Share Posted February 6, 2017 Note that you only need the ntlm auth=yes line. the log level and syslog lines are only useful for debugging Yes, probably on to something. unRaid 6.2 uses samba 4.4, unRaid 6.3 is using samba 4.5.3. In the samba change log for 4.5.0 there's this: NTLMv1 authentication disabled by default ----------------------------------------- In order to improve security we have changed the default value for the "ntlm auth" option from "yes" to "no". This may have impact on very old clients which doesn't support NTLMv2 yet. The primary user of NTLMv1 is MSCHAPv2 for VPNs and 802.1x. By default, Samba will only allow NTLMv2 via NTLMSSP now, as we have the following default "lanman auth = no", "ntlm auth = no" and "raw NTLMv2 auth = no". Quote Link to comment
RobJ Posted February 6, 2017 Share Posted February 6, 2017 Seems to be a bug in the nice new feature to specify the SMART device type (ATA, SATA, Areca, etc). You can now select the correct type globally and for each drive. However it starts on Auto, which I assume should attempt to identify the correct type, but doesn't appear to be working correctly. When set to Auto, all of the Smart reports are only 318 bytes, and look like this: smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.9.7-unRAID] (local build) Copyright © 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org ERROR: smartctl takes ONE device name as the final command-line argument. You have provided 2 device names: /dev/sdc Use smartctl -h to get a usage summary I can't explain the error, as I only see one device listed in each. But if I change the global setting to ATA, then all of the SMART reports are correct in the diagnostics zip. Users should probably change the global setting to ATA, then override it on each disk that requires a different setting. I agree there's a bug but for me changing the global setting to ATA results in this in the SMART reports: /dev/sdc: Unknown device type ' ata' =======> VALID ARGUMENTS ARE: ata, scsi, nvme[,NSID], sat[,auto][,N][+TYPE], usbcypress[,X], usbjmicron[,p][,x][,N], usbprolific, usbsunplus, marvell, areca,N/E, 3ware,N, hpt,L/M/N, megaraid,N, aacraid,H,L,ID, cciss,N, auto, test <======= Yes, you're right. I was positive I tested and it worked, but I can't find the positive result. When I test now, I get the same thing you do. Quote Link to comment
bakes82 Posted February 6, 2017 Share Posted February 6, 2017 I updated to 6.3 and now have a Kernel Panic. I had to roll back to 6.2.4 which might I say should be on the download links ..... What do I need to send to see whats causing the panic? Quote Link to comment
ezhik Posted February 6, 2017 Share Posted February 6, 2017 Note that you only need the ntlm auth=yes line. the log level and syslog lines are only useful for debugging Yes, probably on to something. unRaid 6.2 uses samba 4.4, unRaid 6.3 is using samba 4.5.3. In the samba change log for 4.5.0 there's this: NTLMv1 authentication disabled by default ----------------------------------------- In order to improve security we have changed the default value for the "ntlm auth" option from "yes" to "no". This may have impact on very old clients which doesn't support NTLMv2 yet. The primary user of NTLMv1 is MSCHAPv2 for VPNs and 802.1x. By default, Samba will only allow NTLMv2 via NTLMSSP now, as we have the following default "lanman auth = no", "ntlm auth = no" and "raw NTLMv2 auth = no". Yep, I had to change my systems to mount using ntlmssp rather than ntlm after upgarding to 6.3 Cheers. Quote Link to comment
GHunter Posted February 6, 2017 Share Posted February 6, 2017 My upgrade from v6.2.4 seems to be working fine. I do have tons of this line in my syslog occurring every 1 or 2 seconds and I don't know what it is or if I should be worried about it, other then filling up the syslog. Feb 5 09:01:08 FileSvr kernel: xhci_hcd 0000:00:14.0: URB transfer length is wrong, xHC issue? req. len = 0, act. len = 4294967288 Diagnostics attached. Gary Is this a new issue vs. 6.2.4? This issue might be caused by an attached USB device auto-suspending or auto-poweroff. A plugin or container or vm might be trying to do this Please post output of these commands and we might be able to figure out which device it is: lsusb for i in /sys/bus/usb/devices/*/power/autosuspend; do echo -n "$i "; cat $i; done for i in /sys/bus/usb/devices/*/power/level; do echo -n "$i "; cat $i; done (Click [select] above, then Ctrl-C to copy to clipboard. Then in telnet/ssh window open to server, "paste" those commands - with putty you can use right-mouse click or hit Shift-Insert.) I've had this issue prior to v6.3.0 so it isn't specific to this version of unRaid. Here is my output to the commands you requested: root@FileSvr:~# lsusb Bus 002 Device 002: ID 8087:8001 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:8009 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 002: ID 13fe:5200 Kingston Technology Company Inc. Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 004: ID 0471:0815 Philips (or NXP) eHome Infrared Receiver Bus 003 Device 007: ID 147a:e042 Formosa Industrial Computing, Inc. Bus 003 Device 002: ID 04d9:a015 Holtek Semiconductor, Inc. Bus 003 Device 006: ID 046d:c31c Logitech, Inc. Keyboard K120 Bus 003 Device 005: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@FileSvr:~# for i in /sys/bus/usb/devices/*/power/autosuspend; do echo -n "$i "; cat $i; done /sys/bus/usb/devices/1-1/power/autosuspend 0 /sys/bus/usb/devices/2-1/power/autosuspend 0 /sys/bus/usb/devices/3-10/power/autosuspend 2 /sys/bus/usb/devices/3-13/power/autosuspend 2 /sys/bus/usb/devices/3-3/power/autosuspend 2 /sys/bus/usb/devices/3-6/power/autosuspend 2 /sys/bus/usb/devices/3-9/power/autosuspend 2 /sys/bus/usb/devices/4-3/power/autosuspend 2 /sys/bus/usb/devices/5-1/power/autosuspend 2 /sys/bus/usb/devices/usb1/power/autosuspend 0 /sys/bus/usb/devices/usb2/power/autosuspend 0 /sys/bus/usb/devices/usb3/power/autosuspend 0 /sys/bus/usb/devices/usb4/power/autosuspend 0 /sys/bus/usb/devices/usb5/power/autosuspend 0 /sys/bus/usb/devices/usb6/power/autosuspend 0 root@FileSvr:~# for i in /sys/bus/usb/devices/*/power/level; do echo -n "$i "; cat $i; done /sys/bus/usb/devices/1-1/power/level auto /sys/bus/usb/devices/2-1/power/level auto /sys/bus/usb/devices/3-10/power/level on /sys/bus/usb/devices/3-13/power/level on /sys/bus/usb/devices/3-3/power/level on /sys/bus/usb/devices/3-6/power/level on /sys/bus/usb/devices/3-9/power/level on /sys/bus/usb/devices/4-3/power/level on /sys/bus/usb/devices/5-1/power/level on /sys/bus/usb/devices/usb1/power/level auto /sys/bus/usb/devices/usb2/power/level auto /sys/bus/usb/devices/usb3/power/level auto /sys/bus/usb/devices/usb4/power/level auto /sys/bus/usb/devices/usb5/power/level auto /sys/bus/usb/devices/usb6/power/level auto root@FileSvr:~# One other thought that might help if you think this is a USB problem. I have 2 USB devices being passed through to 2 Win 10 VM's. Bus 003 Device 004: ID 0471:0815 Philips (or NXP) eHome Infrared Receiver is passed through to a VM via an Ethernet to USB adapter. And the other one is Bus 003 Device 007: ID 147a:e042 Formosa Industrial Computing, Inc. is passed through to a different VM via an Ethernet to USB adapter. I've tried passing these devices through in both USB 2.0 EHCI mode and USB 3.0 XHCI mode and both modes still cause problems. I've disabled all power saving features inside the VM's and ran through the BIOS to check for any possible problems there. I've also tried switch Ethernet cables too. None of which helped. Of course I could go through and troubleshoot again now that I'm on unRaid v6.3.0. If you could point me in the right direction, that would be great. I just don't know if this is an unRaid problem or something on my end. Thanks again, Gary Quote Link to comment
GHunter Posted February 6, 2017 Share Posted February 6, 2017 My upgrade from v6.2.4 seems to be working fine. I do have tons of this line in my syslog occurring every 1 or 2 seconds and I don't know what it is or if I should be worried about it, other then filling up the syslog. Feb 5 09:01:08 FileSvr kernel: xhci_hcd 0000:00:14.0: URB transfer length is wrong, xHC issue? req. len = 0, act. len = 4294967288 At the rate it's filling the syslog, it's clearly going to be trouble, probably causing you to have to reboot every other day. That number corresponds to -8, but I have no idea what table to check for an error return of 8. I do notice that you are very tight on memory, about as tight as I've ever seen, so it's possible that's an indirect indication of something not being able to allocate the memory it requested. It first occurred at 10:05pm, with no other clues associated. It's associated with the onboard Intel USB controller. Perhaps consider decreasing by 1GB the RAM assigned to one VM? One other thing I noticed, you may want to raise the tunable md_sync_thresh to at least 320, but 600 or 610 may be even better, for better parity check performance. Thanks for the help and advice Rob. I'll definitely make some changes as you suggested. Gary Quote Link to comment
phbigred Posted February 6, 2017 Share Posted February 6, 2017 So far so good with 6.3 had an issue with rc6 but upgrade went normal and yet to have a lockup like I did on that rc. Quote Link to comment
smashingtool Posted February 6, 2017 Share Posted February 6, 2017 I am on Windows 10 Pro. My shares are set to public. I am not having trouble accessing them, but I am getting long pauses in the middle of transfers, that is ultimately prolonging the transfer time considerably. Any idea what I can do to troubleshoot this? Netbios over TCP/IP is enabled. It's all wired connections. My network.cfg shows: # Generated settings: USE_DHCP="yes" IPADDR="192.168.1.130" NETMASK="255.255.255.0" GATEWAY="192.168.1.1" DHCP_KEEPRESOLV="no" DNS_SERVER1="192.168.1.1" DNS_SERVER2="" DNS_SERVER3="" BONDING="no" BONDING_MODE="1" Quote Link to comment
landS Posted February 6, 2017 Share Posted February 6, 2017 <type arch='x86_64' machine='pc-q35-2.3'>hvm</type> to: <type arch='x86_64' machine='pc-q35-2.7'>hvm</type> Thanks Gary. I was at pc-q35-2.5, however the key-presses did not work as expected. Manually changed the XML to 2.7 and my ElementaryOS VM is back to humming as hoped for. edit: spoke to soon. the keypresses are now working, however it takes 7 seconds for each press to register ;( Too tired to dig ATM. edit 1: Ok... 1 dig solved this. The VM defaulted to using QXL after the 6.3 uprgrade rather than CIRRUS for the VNC driver. The QXL VNC driver is a DOG on performance Outside of this, the update has been smooth on 2 machines nice work LT Quote Link to comment
nokdim Posted February 6, 2017 Share Posted February 6, 2017 I'm back to working thanks again... What did you do to solve the problem so others can learn? Not 100% sure what the fix was but - Deleted the preclear plugin - Deleted the rclone plugin not sure but was also just upgraded I have 3 network devices that write via FTP to /mnt/user/Nokdim as RobJ eluded to (I stopped FTP on those devices since I saw that directory being created even though the user share wasn't available?!?!?! seemed bad... I am using the built in FTPd so yeah it accepted connection but not sure how to stop that besides maybe write to a none user share) - Removed the cache drive from the array After a reboot the cache drive was back in as a cache drive on the array on its own and all user shares came back. All my docker/VM depended on user shares so they spun right up once the user shares came online. I do believe the user shares had an issue possibly due to preclear or rclone most likely preclear The FTPd issue probably added fuel to the fire. Lesson learned is probably upgrade each plugin and verify with reboot prior to unRAID plugin update itself. Dockerize as much as possible, I feel that saved me hours since it seemed plugin related and all my dockers spun right up after. Update one thing at a time or else it is a guessing game on the culprit. And most importantly be thankful for a community like this one for a second set of eyes and support!!! Thanks Again... Quote Link to comment
LateNight Posted February 6, 2017 Share Posted February 6, 2017 ntlm auth = yes seems to have fixed my problem. Quote Link to comment
RobJ Posted February 6, 2017 Share Posted February 6, 2017 A reminder to users that have a problem and want help - attach your diagnostics! We can't guess what happened without some clues. If at all possible, grab the diagnostics immediately after the problem occurs. Need help? Read me first! Quote Link to comment
karateo Posted February 6, 2017 Share Posted February 6, 2017 Note that you only need the ntlm auth=yes line. the log level and syslog lines are only useful for debugging Yes, probably on to something. unRaid 6.2 uses samba 4.4, unRaid 6.3 is using samba 4.5.3. In the samba change log for 4.5.0 there's this: NTLMv1 authentication disabled by default ----------------------------------------- In order to improve security we have changed the default value for the "ntlm auth" option from "yes" to "no". This may have impact on very old clients which doesn't support NTLMv2 yet. The primary user of NTLMv1 is MSCHAPv2 for VPNs and 802.1x. By default, Samba will only allow NTLMv2 via NTLMSSP now, as we have the following default "lanman auth = no", "ntlm auth = no" and "raw NTLMv2 auth = no". That's it!!!! I updated again and from windows 10 I did this https://kb.iu.edu/d/atcb LmCompatibilityLevel 3 or NTLMv2 response only I lost a VM in the process but at least the shares are working again! Quick tip on how to restore the lost VM from the web interface? Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.