unRAID OS version 6.3.0 Stable Release Available


limetech

Recommended Posts

ntlm auth = yes seems to have fixed my problem.  :)

 

I upgraded and had the same issue with a PopCorn Hour player, would not connect to SMB share anymore. 

added ntlm auth = yes to smb config and it's now working again.  Thanks!

 

So, is this going to be fixed in the next release, where this settings works correctly without this manual step?  I don't want to have to do this every time there is an new release of unraid.

 

Once you have in the Samba Extra Configuration, it will always be there if you upgrade through the Plugin page or just copy over the bz* files.  Even if it it is added into the standard unRAID release, you don't have to remove it because the entry will just turn it 'on' a second time.  (It is like saving a file twice.)

 

That's correct.  We are turning that option on for 6.3.1.

 

I am one of those that has not had any issues at all with the new samba share security.  I'm wondering if it might be best for those of us wanting better security to have an option in the Settings->SMB that defaults to the older security method, but allow us that want it to turn on the newer method of security.

 

LT has been very focused on security lately, and to turn on an older security method purely for backwards compatibility with no means of turning on the enhanced security method seems contrary to the LT goal of improving security.

Link to comment
  • Replies 323
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

That's correct.  We are turning that option on for 6.3.1.

 

I am one of those that has not had any issues at all with the new samba share security.  I'm wondering if it might be best for those of us wanting better security to have an option in the Settings->SMB that defaults to the older security method, but allow us that want it to turn on the newer method of security.

 

LT has been very focused on security lately, and to turn on an older security method purely for backwards compatibility with no means of turning on the enhanced security method seems contrary to the LT goal of improving security.

 

Seconded.

Link to comment

ntlm auth = yes seems to have fixed my problem.  :)

 

I upgraded and had the same issue with a PopCorn Hour player, would not connect to SMB share anymore. 

added ntlm auth = yes to smb config and it's now working again.  Thanks!

 

So, is this going to be fixed in the next release, where this settings works correctly without this manual step?  I don't want to have to do this every time there is an new release of unraid.

 

Once you have in the Samba Extra Configuration, it will always be there if you upgrade through the Plugin page or just copy over the bz* files.  Even if it it is added into the standard unRAID release, you don't have to remove it because the entry will just turn it 'on' a second time.  (It is like saving a file twice.)

 

That's correct.  We are turning that option on for 6.3.1.

 

I am one of those that has not had any issues at all with the new samba share security.  I'm wondering if it might be best for those of us wanting better security to have an option in the Settings->SMB that defaults to the older security method, but allow us that want it to turn on the newer method of security.

 

LT has been very focused on security lately, and to turn on an older security method purely for backwards compatibility with no means of turning on the enhanced security method seems contrary to the LT goal of improving security.

 

Care has to be taken in doing this.  The text on the "Samba extra configuration:"  box in the GUI is actually stored in a file called  smb-extra.conf  in the config  folder.  This file (smb-extra,conf) is actually loaded/called near the end of the general Samba configuration file whenever Samba is started.  As a result of its positioning, it can modify any of the settings that are in the default Samba configuration file.  That are folks who actually do this!  This feature was actually included in unRAID long before the GUI box was added. 

 

It would be my suggestion if Limetech decides to add support for the old protocol that they preserve the current contents of smb-extra.conf and place their modifications at the beginning of that file and have the modifications 'commented-out' and enough additional commenting/description so that the end user can easily figure out how to enable the older protocol.  (You simply have to remove the '#' beginning of the line to enable the setting.)

 

Conversely, LimeTech could turn on the old protocol as the default and the user could turn it off by putting 

 

ntlm auth = no

 

into the GUI box.  Either way would work.  Folks just have to made aware of which way the solution was implemented.

Link to comment

Can do Jon... any idea how I can get Dockers back on 6.2.4?

 

EDIT: Fixed it. If anyone else runs into this issue I had to 'stop' docker, delete the image, reboot, re-start docker and it's showing running again.

 

Same steps I've used with bouncing between RC and 6.2.4 took some trial and error and I even included an extra reboot at the end.

 

My guess is the docker version in 6.3.x upgrades the IMG file in some way and it becomes incompatible with earlier versions of docker, so when we revert back to 6.2.4 it doesn't work.

 

Still confused as to why a reboot is required to get it going, even if the docker.img is deleted... above my head though.

Link to comment

Ok, Docker was frozen this morning (not a big deal, it froze when I tried to force an update a container. This has happened before but the we gui becomes unresponsive). Server was still running and functioning. I went to reboot via "powerdown" and got the attached error message. I am guessing MD15 is drive 15? I never saw this message in 6.2.4. If I have to replace drive 15, it's not a huge deal I am just concerned that I never saw this in 6.2.4.

 

http://imgur.com/a/KezW2

Link to comment

ntlm auth = yes seems to have fixed my problem.  :)

 

I upgraded and had the same issue with a PopCorn Hour player, would not connect to SMB share anymore. 

added ntlm auth = yes to smb config and it's now working again.  Thanks!

 

So, is this going to be fixed in the next release, where this settings works correctly without this manual step?  I don't want to have to do this every time there is an new release of unraid.

 

Once you have in the Samba Extra Configuration, it will always be there if you upgrade through the Plugin page or just copy over the bz* files.  Even if it it is added into the standard unRAID release, you don't have to remove it because the entry will just turn it 'on' a second time.  (It is like saving a file twice.)

 

That's correct.  We are turning that option on for 6.3.1.

 

I am one of those that has not had any issues at all with the new samba share security.  I'm wondering if it might be best for those of us wanting better security to have an option in the Settings->SMB that defaults to the older security method, but allow us that want it to turn on the newer method of security.

 

LT has been very focused on security lately, and to turn on an older security method purely for backwards compatibility with no means of turning on the enhanced security method seems contrary to the LT goal of improving security.

 

I was affected but I agree with the above.  I'm now intent on finding why my Windows 10 PC seems to have downgraded security rather than hoping LT waste effort catering for it now that we know the manual fix is so easy.

Link to comment

ntlm auth = yes seems to have fixed my problem.  :)

 

I upgraded and had the same issue with a PopCorn Hour player, would not connect to SMB share anymore. 

added ntlm auth = yes to smb config and it's now working again.  Thanks!

 

So, is this going to be fixed in the next release, where this settings works correctly without this manual step?  I don't want to have to do this every time there is an new release of unraid.

 

Once you have in the Samba Extra Configuration, it will always be there if you upgrade through the Plugin page or just copy over the bz* files.  Even if it it is added into the standard unRAID release, you don't have to remove it because the entry will just turn it 'on' a second time.  (It is like saving a file twice.)

 

That's correct.  We are turning that option on for 6.3.1.

 

I am one of those that has not had any issues at all with the new samba share security.  I'm wondering if it might be best for those of us wanting better security to have an option in the Settings->SMB that defaults to the older security method, but allow us that want it to turn on the newer method of security.

 

LT has been very focused on security lately, and to turn on an older security method purely for backwards compatibility with no means of turning on the enhanced security method seems contrary to the LT goal of improving security.

 

I was affected but I agree with the above.  I'm now intent on finding why my Windows 10 PC seems to have downgraded security rather than hoping LT waste effort catering for it now that we know the manual fix is so easy.

 

What my gut feeling is that the implementation of NTLMv2 in SAMBA is incompatible with the version that is in Win10.  After that fails, Win10 'falls' back to NTLMv1 and since that is not turn on the latest version of SAMBA (by  default), it fails to connect to the server-- period.  As soon as NTLMv1 is turned back on in SAMBA, Win10 computers can connect via that protocol. 

Link to comment

I went to reboot via "powerdown" and got the attached error message. I am guessing MD15 is drive 15? I never saw this message in 6.2.4. If I have to replace drive 15, it's not a huge deal I am just concerned that I never saw this in 6.2.4.

 

The error means there is something wrong with the Reiser file system on Disk 15.  It does NOT mean there is anything wrong with the drive associated with Disk 15.  It also does not mean there's anything wrong with 6.3.0, although it's possible (but not likely) there's an improvement in the ReiserFS modules in 6.3.0 that is better at checking for corruption.  Please see Check Disk File systems.

Link to comment

I searched all through this thread, so hopefully no duplicating...

 

After upgrading from 6.2.4 to 6.3.0, my 'unRAID Main' web interface is blank (see screenshot). This happens in Chrome and Firefox and I cleared browser cache and tested in private mode on both browsers. I also tried killing unmenu and restarting it with no luck, but not sure if that is at all related...

 

The array is up and running (started automatically after upgrade) and my dockers are running.

Screen_Shot_2017-02-08_at_8_16.28_AM.png.0ae7742bbc5221f63f290d9c95b0bd0e.png

Link to comment

I have a problem that popped up earlier in the 6.3 BETA cycle, hoped it would get fixed when the FINAL came out, but no luck.  Maybe it's specific to my configuration.  This issue is when I STOP the array, then select the checkbox to reboot, then proceed to click the REBOOT button, nothing happens.  Almost like there is nothing associated with this action.  I end up having to SSH in, then reboot from the shell.

 

I'm experiencing no other issues.  Diagnostics attached.  Feedback appreciated.

 

Thanks.

 

Anyone have any insight on this?  At one point I ran the powerdown addon, it was removed awhile back as I was told it was no longer needed.  When the reboot button is clicked, I assume it runs a command or script?, can I check to verify those commands and or scripts are present?  If so, some guidance on where to look would be appreciated.

Link to comment
Quote from: joeschmoe on Today at 08:16:58 AM

After upgrading from 6.2.4 to 6.3.0, my 'unRAID Main' web interface is blank (see screenshot).

The latest security updates in 6.3.x are probably the death knell for unmenu, since it's no longer being actively developed.

 

I'd advise no longer using unmenu.

 

oh wow, ok.

 

What is the best way to manage the server now? CLI only?

Link to comment

Quote from: joeschmoe on Today at 08:16:58 AM

After upgrading from 6.2.4 to 6.3.0, my 'unRAID Main' web interface is blank (see screenshot).

The latest security updates in 6.3.x are probably the death knell for unmenu, since it's no longer being actively developed.

 

I'd advise no longer using unmenu.

 

oh wow, ok.

 

What is the best way to manage the server now? CLI only?

unMenu was never needed, and the unRAID Main web interface that you say is missing was always just a frame for the builtin web interface unRAID has always had. If you haven't hacked your go file to put it on another port you should be able to just go to http://tower or whatever you have named your server.

 

From your screenshot I think maybe you have named it unRAIDServer, so just go to http://unRAIDServer.

Link to comment

Conversely, LimeTech could turn on the old protocol as the default and the user could turn it off by putting 

 

ntlm auth = no

 

into the GUI box.  Either way would work.  Folks just have to made aware of which way the solution was implemented.

 

That is what we have done for 6.3.1 (we are turning on the option by default).  This is because there are still many servers out there that have not been updated to 6.3 yet and we don't want the first thing that happens is their clients can't connect.  We'll probably eventually make this a SMB Network setting in the future.

Link to comment

That is what we have done for 6.3.1 (we are turning on the option by default).  This is because there are still many servers out there that have not been updated to 6.3 yet and we don't want the first thing that happens is their clients can't connect.  We'll probably eventually make this a SMB Network setting in the future.

When you make it a setting, you could put a warning saying something about "Enabling more secure setting could cause failed connections from some clients" so people know the possible consequences. New installs could default to higher security with release notes* outlining possible issues, upgraded installs would inherit existing settings, and Squid's FCP could warn about possible insecure settings.

 

*(like anyone actually reads the release notes)

Link to comment

Quote from: joeschmoe on Today at 08:16:58 AM

After upgrading from 6.2.4 to 6.3.0, my 'unRAID Main' web interface is blank (see screenshot).

The latest security updates in 6.3.x are probably the death knell for unmenu, since it's no longer being actively developed.

 

I'd advise no longer using unmenu.

 

oh wow, ok.

 

What is the best way to manage the server now? CLI only?

unMenu was never needed, and the unRAID Main web interface that you say is missing was always just a frame for the builtin web interface unRAID has always had. If you haven't hacked your go file to put it on another port you should be able to just go to http://tower or whatever you have named your server.

 

From your screenshot I think maybe you have named it unRAIDServer, so just go to http://unRAIDServer.

 

Thank you! had no clue! obviously :-) (crawling back into my hole)

Link to comment

After upgrading from 6.2.4 to 6.3.0, I get the following in my VM/qemu log.

 

2017-02-05T20:29:39.741418Z qemu-system-x86_64: -device vfio-pci,host=08:00.0,id=hostdev3,bus=pci.0,addr=0x9: Failed to mmap 0000:08:00.0 BAR 2. Performance may be slow
2017-02-05T20:29:39.746332Z qemu-system-x86_64: warning: Unknown firmware file in legacy mode: etc/msr_feature_control

 

I looked back at some old diagnostics from a couple of weeks ago and I did not get this message.  This is for an add-on USB 3.0 controller that I have passed through to the VM.  I have not fully tested the USB but can tell you that it is working on some level as I am typing and using a mouse that is plugged into this device....not sure that the performance may be slow means.

 

I am post here vs KVM forum since I did not get this message previously.

 

Any suggestions?

 

Hi snoopin,

 

Quick question:  is there any felt impact from the upgrade in terms of your VM, performance, or anything with your USB devices attached to that controller?  If not, the message is likely harmless, but curious if you can trace this back to any symptoms you notice when using the VM.

 

@jonp I detailed this and requested the inclusion of a patch back in RC4 related to the USB card causing this issue, details are here http://lime-technology.com/forum/index.php?topic=53689.msg515705#msg515705 with the link to the fix, I have not noticed any degradation of performance in my VM with this issue.

Link to comment

Quote from: joeschmoe on Today at 08:16:58 AM

After upgrading from 6.2.4 to 6.3.0, my 'unRAID Main' web interface is blank (see screenshot).

The latest security updates in 6.3.x are probably the death knell for unmenu, since it's no longer being actively developed.

 

I'd advise no longer using unmenu.

 

oh wow, ok.

 

What is the best way to manage the server now? CLI only?

unMenu was never needed, and the unRAID Main web interface that you say is missing was always just a frame for the builtin web interface unRAID has always had. If you haven't hacked your go file to put it on another port you should be able to just go to http://tower or whatever you have named your server.

 

From your screenshot I think maybe you have named it unRAIDServer, so just go to http://unRAIDServer.

Despite all of the above, unMenu is still working for me under 6.3.0 without any special measures needed.  I agree that is is now relatively redundant, given the massive improvements that have been made to the web UI, but I still find myself using the myMain option occasionally.

Link to comment

After upgrading from 6.2.4 to 6.3.0, I get the following in my VM/qemu log.

 

2017-02-05T20:29:39.741418Z qemu-system-x86_64: -device vfio-pci,host=08:00.0,id=hostdev3,bus=pci.0,addr=0x9: Failed to mmap 0000:08:00.0 BAR 2. Performance may be slow
2017-02-05T20:29:39.746332Z qemu-system-x86_64: warning: Unknown firmware file in legacy mode: etc/msr_feature_control

 

I looked back at some old diagnostics from a couple of weeks ago and I did not get this message.  This is for an add-on USB 3.0 controller that I have passed through to the VM.  I have not fully tested the USB but can tell you that it is working on some level as I am typing and using a mouse that is plugged into this device....not sure that the performance may be slow means.

 

I am post here vs KVM forum since I did not get this message previously.

 

Any suggestions?

 

Hi snoopin,

 

Quick question:  is there any felt impact from the upgrade in terms of your VM, performance, or anything with your USB devices attached to that controller?  If not, the message is likely harmless, but curious if you can trace this back to any symptoms you notice when using the VM.

 

@jonp I detailed this and requested the inclusion of a patch back in RC4 related to the USB card causing this issue, details are here http://lime-technology.com/forum/index.php?topic=53689.msg515705#msg515705 with the link to the fix, I have not noticed any degradation of performance in my VM with this issue.

 

That's a patch in qemu and we are not comfortable adding that, even if it is from Alex W.  This is because once it's added, we have to maintain it.  Probably if this patch is needed it will find it's way to upstream anyway, but it appears to just be cosmentic:

 

    "NB, this doesn't actually change the behavior of the device, it only

    removes the scary "Failed to mmap ... Performance may be slow" error

    message.  We cannot currently create an mmap over the MSI-X table"

Link to comment

...

The point is you should use /sbin/poweroff instead of 'powerdown' or '/usr/local/sbin/powerdown' in your 'at' job.

 

Does /sbin/poweroff stop the array before shutting down ?

Tries to.  On Settings/Disk Settings page the 'Shutdown time-out' defines how long it will wait before dropping the hammer.

Link to comment

...

The point is you should use /sbin/poweroff instead of 'powerdown' or '/usr/local/sbin/powerdown' in your 'at' job.

 

Does /sbin/poweroff stop the array before shutting down ?

Tries to.  On Settings/Disk Settings page the 'Shutdown time-out' defines how long it will wait before dropping the hammer.

 

Sorry this a little off topic but I had to considerably increase that to shutdown my newly converted btrfs servers, unmounting all disks takes about 2 minutes (one has 10, the other 12 data disks), do you know if this is normal for btrfs?

Link to comment

After upgrading from 6.2.4 to 6.3.0, I get the following in my VM/qemu log.

 

2017-02-05T20:29:39.741418Z qemu-system-x86_64: -device vfio-pci,host=08:00.0,id=hostdev3,bus=pci.0,addr=0x9: Failed to mmap 0000:08:00.0 BAR 2. Performance may be slow
2017-02-05T20:29:39.746332Z qemu-system-x86_64: warning: Unknown firmware file in legacy mode: etc/msr_feature_control

 

I looked back at some old diagnostics from a couple of weeks ago and I did not get this message.  This is for an add-on USB 3.0 controller that I have passed through to the VM.  I have not fully tested the USB but can tell you that it is working on some level as I am typing and using a mouse that is plugged into this device....not sure that the performance may be slow means.

 

I am post here vs KVM forum since I did not get this message previously.

 

Any suggestions?

 

Hi snoopin,

 

Quick question:  is there any felt impact from the upgrade in terms of your VM, performance, or anything with your USB devices attached to that controller?  If not, the message is likely harmless, but curious if you can trace this back to any symptoms you notice when using the VM.

 

@jonp I detailed this and requested the inclusion of a patch back in RC4 related to the USB card causing this issue, details are here http://lime-technology.com/forum/index.php?topic=53689.msg515705#msg515705 with the link to the fix, I have not noticed any degradation of performance in my VM with this issue.

 

That's a patch in qemu and we are not comfortable adding that, even if it is from Alex W.  This is because once it's added, we have to maintain it.  Probably if this patch is needed it will find it's way to upstream anyway, but it appears to just be cosmentic:

 

    "NB, this doesn't actually change the behavior of the device, it only

    removes the scary "Failed to mmap ... Performance may be slow" error

    message.  We cannot currently create an mmap over the MSI-X table"

 

Okie dokie, thanks for chiming in.

Link to comment

Hi,

 

I'm unable to install the update as per a previous post in this thread.  It was recommended that I download the zip from from the website and then overwrite all of the bz* files on the flash drive with the ones in the zip.

 

Can I simply overwrite the files while the server is running and then restart? Or do I have to power down and overwrite the files on the flash drive from another computer?

 

Sorry in advance for the rookie question.

 

Ryan.

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.