unRAID OS version 6.3.0 Stable Release Available


limetech

Recommended Posts

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.

Link to comment
  • Replies 323
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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(8) 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".

 

Link to comment

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!)

Link to comment

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 <=======

 

Link to comment

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".

 

Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment

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

Link to comment

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"

Link to comment

<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

Link to comment

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...

Link to comment

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?

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.