Unraid OS version 6.8.0-rc1 available

3 minutes ago, Benson said:

In this RC, I got several problem

 

1. Extreme slow read performance, I try restore all modify tunable to default but can't fix. Single disk read speed ~50MB/s, or multiple disk access i.e 3 disks total ~150MB/s. ( all were large file from individual disk, no other task )

 

 

 

Try with using different drives for all your reads -- 2 of your reads are from the same drive, disk 9.

9 minutes ago, Benson said:

2. When open Web terminal and type "exit" at prompt, the terminal will reconnect again.

I've noticed that too, it's on our list of annoyances to fix.

7 minutes ago, BRiT said:

 

Try with using different drives for all your reads -- 2 of your reads are from the same drive, disk 9.

Oh yes. Thanks

 

But I make test and boot several time, single file or muliple file all got same result. Hope I could found out the cause.

Edited October 12, 2019 by Benson

11 minutes ago, Benson said:

3. Bowser issue, seems Chrome could normal access, MS Edge - can't correct display the gui, IE even just blank page.

Edge seems to work ok.  Honestly, didn't test with IE.

2 minutes ago, Benson said:

Oh yes.

 

But I make test and boot several time, single file or muliple file all got same result. Hope I could found out a cause.

What exactly are you doing?

4 minutes ago, limetech said:

What exactly are you doing?

I set tunable parameter to default, so I think I should power off/on to make test valid.

I belive my case was a single case, but need rule out the cause. Next try safe mode.

Edited October 12, 2019 by Benson

2 hours ago, Benson said:

I set tunable parameter to default, so I think I should power off/on to make test valid.

I belive my case was a single case, but need rule out the cause. Next try safe mode.

I boot in safe mode, the read performance won't change, ~62MB/s for a large file. Then I boot in normal mode.

Below test show some I/O issue was going, a 20GB file disk read and hash need 8m34s, after it cache in memory, hash again just 36s.

 

 

Next I try different file under different controller ( but all mount by UD plugin )

- 23GB file, 1809.img, SSD in onboard SATA, normal

- 23GB file , A1001.ISO, RAID0 pool attach on another LSI (2008 chip), normal

 

 

 

Then I check syslog, I notice some message may be relate ( I have two LSI HBA, 2008 chip and 2308 chip ), so may be wait does another report same issue this moment.

 

Current

Oct 12 11:45:01 X370 kernel: mpt2sas_cm0: MSI-X vectors supported: 16, no of cores: 16, max_msix_vectors: -1

Oct 12 11:45:01 X370 kernel: mpt2sas_cm0: 0 16

Oct 12 11:45:01 X370 kernel: mpt2sas_cm0: High IOPs queues : disabled

Oct 12 11:45:01 X370 kernel: mpt2sas0-msix0: PCI-MSI-X enabled: IRQ 56

Oct 12 11:45:01 X370 kernel: mpt2sas0-msix1: PCI-MSI-X enabled: IRQ 57

Oct 12 11:45:01 X370 kernel: mpt2sas0-msix2: PCI-MSI-X enabled: IRQ 58

 

Before

Apr  3 12:35:43 X370 kernel: mpt2sas_cm0: MSI-X vectors supported: 16, no of cores: 16, max_msix_vectors: -1
Apr  3 12:35:43 X370 kernel: mpt2sas0-msix0: PCI-MSI-X enabled: IRQ 56
Apr  3 12:35:43 X370 kernel: mpt2sas0-msix1: PCI-MSI-X enabled: IRQ 57
Apr  3 12:35:43 X370 kernel: mpt2sas0-msix2: PCI-MSI-X enabled: IRQ 58

Edited October 12, 2019 by Benson

1 hour ago, Benson said:

the read performance won't change, ~62MB/s for a large file

I've tried on a couple servers and get full speed doing 'md5sum' of a file.

 

You can experiment with 2 tunables on Settings/Disk Settings page:

enable ncq

nr_requests

I suggest start with Auto on both.  To set 'auto' for nr_requests, click in the field and delete any value set there (so field is blank) and then click Apply.  You will then need to reboot for that setting to take effect.

Setting both to 'auto' tells Unraid to not change those values from what the kernel sets.

If this doesn't help next change would be to disable ncq.

If that doesn't help, maybe something different with that driver and more research needed.

Will we see in Unraid 6.8:

Linux firmware: kernel-firmware-20191008_aa95e90

Samba moved to 4.11

Nginx moved over to mainline 1.17

PHP moved to 7.3 since active support for 7.2 ends in 1 month?

 

Thanks again.

seriuosly fingers crossed that ixgbe support is fixed and included in final release as 10g intel card(s) are my main cards in my unraid boxes.

would be a nogo without.

wait and pray ........

1 minute ago, JoeUnraidUser said:

All of the files on the flash drive are now set to 600 permission and it won't let you change the files to 700.  So now I can't run any of my scripts at startup.  All permissions on the flash drive used to be set to 777 so scripts could be run no problem

Instead of 

/boot/your_script

use

bash /boot/your_script

 

5 minutes ago, JoeUnraidUser said:

All of the files on the flash drive are now set to 600 permission and it won't let you change the files to 700.  So now I can't run any of my scripts at startup.  All permissions on the flash drive used to be set to 777 so scripts could be run no problem.

You can run bash scripts like this

bash /path/to/script

 

Changed permissions of the USB device is part of the new security scheme introduced with Unraid 6.8.

 

28 minutes ago, bonienl said:

Changed permissions of the USB device is part of the new security scheme introduced with Unraid 6.8.

 

Could you please elaborate a little bit on the new security scheme? Or provide a link if it has already been discussed (sorry, I couldn't find it). Thanks!

Yeah, it is not explicitely mentioned in the release notes.

 

Replacing 'umask=0' with 'dmask=77,fmask=177' serves to set permissions on the USB flash mounted at /boot so that only the root user can access.  This has two implications:

• When/if we introduce a non-root webGUI user (like 'admin' or 'guest'), code executed by that user will not be able to reference stuff on the USB flash device.
• There can be no "executable" files in /boot tree.

9 minutes ago, JoeUnraidUser said:

Then how are we supposed to run scripts at boot?

Use CA User Scripts

Not sure why you need a perl/python script to run at boot time, but you can do something like this in your go file

cp /boot/perl_script /tmp
chmod +x /tmp/perl_script
/tmp/perl_script

 

I use Duplicati-docker to backup /boot twice a day. Now broken, permission denied. Any way to get around the new permissions? 

22 minutes ago, Niklas said:

...   Any way to get around the new permissions? 

+1  At least give us a choice of being able to setup our servers so that we can use it as we wish.  I have zero intent to setup of setting up a non-root user on my server!!!  (I could say that this is as bad as MS changing the SMB permissions/settings about once every three months but I am willing to give you the benefit of the doubt as this time!) 

Edited October 12, 2019 by Frank1940
Typing too fast in rage...

20 minutes ago, Frank1940 said:

+1  At least give us a choice of being able to setup our servers so that we can use it as we wish.  I have zero intent to setup of setting up a non-root user on my server!!!  (I could say that this is as bad as MS changing the SMB permissions/settings about once every three months but I am willing to give you the benefit of the doubt as this time!) 

Limetech is concerned about security and I appreciate their efforts towards better security.  Just because it is an inconvenience is no reason to blow past good security.  In the beta testing there were issues that surfaced about trying to run scripts from the flash drive.  Several of my plugins had to be modified to run scripts from /tmp.  Running a script from the flash under 6.8 is as simple as copying the script to /tmp and execute it from there.  I'm not sure why you would want to do this anyway.  'User Scripts' can be used to run custom scripts.

 

Limetech is working on a more automated way to have the flash device backed up to the cloud as changes on the device occur.  Until that is ready for prime time, find an alternative to backing up the flash.  You could use 'User Scripts' to do a timed backup.

I want to use the functions that duplicati provides like backup rotation, monitoring, encrypting, send to cloud and so on. Guess we have to copy the flash to another location using user scripts with rights modified to get duplicati to read it. Feels less secure but backups are very important. 

Edited October 12, 2019 by Niklas

21 minutes ago, dlandon said:

Limetech is concerned about security and I appreciate their efforts towards better security.  Just because it is an inconvenience is no reason to blow past good security.  In the beta testing there were issues that surfaced about trying to run scripts from the flash drive.  Several of my plugins had to be modified to run scripts from /tmp.  Running a script from the flash under 6.8 is as simple as copying the script to /tmp and execute it from there.  I'm not sure why you would want to do this anyway.  'User Scripts' can be used to run custom scripts.

 

Limetech is working on a more automated way to have the flash device backed up to the cloud as changes on the device occur.  Until that is ready for prime time, find an alternative to backing up the flash.  You could use 'User Scripts' to do a timed backup.

OK.  I am not concerned about backing up the Flash Drive.  In the interest of security, I have already set the SMB export to my flash drive to 'Secure' (If I was even more concerned about securing the Flash Drive, I would have stopped exporting it!) and have decided to not even assign a user to that share.  So no one can't do it from SMB!  (In fact, all of my shares are set to Secure except for the cache drive Disk Share which is set to Public.  I add files to the cache drive and allow the mover to move them to the array.  This prevents the a script/malware from modifying/deleting files on the array or any user from being able to do so via SMB.)  What I did to allow editing the contents of the flash drive (and the User Shares) was to setup the Krusader Docker and configured it to allow me to edit it. 

 

What I would like to see is a setting that would allow the user to set the permissions on the Flash Drive from the new setting back to the old Settings.  This is what MS did when they tried to remove SMBv1 from Win10 and they did the same they when they disallowed Insecure Guest Access to servers which had Guest Privileges in SMB2.  (Luckily, this latter one did not affect users who had turned SMBv1 back on.   Fixing this one was a bit more difficult!  See Here:   https://support.microsoft.com/en-ca/help/4046019/guest-access-in-smb2-disabled-by-default-in-windows-10-and-windows-ser  ) 

 

Please allow us to determine what level of security is required for our servers.  Make the default what you think is needed but give us a way around it. 

3 minutes ago, Frank1940 said:

Please allow us to determine what level of security is required for our servers.  Make the default what you think is needed but give us a way around it. 

Based on your post, what is the reason you want this?

7 minutes ago, dlandon said:

Based on your post, what is the reason you want this?

 

12 minutes ago, Frank1940 said:

What I did to allow editing the contents of the flash drive (and the User Shares) was to setup the Krusader Docker and configured it to allow me to edit it. 

In 6.8.0-rc-1, When using the Krusader Docker, I get this error message:

 

Going back to the Root of Krusader, you find this:

 

On 6.72, this is the same view (different server):

 

From what I can see, the permissions that Krusader is using are for 'Group'.   

4 hours ago, bonienl said:

Yeah, it is not explicitely mentioned in the release notes.

 

Replacing 'umask=0' with 'dmask=77,fmask=177' serves to set permissions on the USB flash mounted at /boot so that only the root user can access.  This has two implications:

• When/if we introduce a non-root webGUI user (like 'admin' or 'guest'), code executed by that user will not be able to reference stuff on the USB flash device.
• There can be no "executable" files in /boot tree.

I suspect this is likely to break some stuff users have been doing for years. I know it does for me. So if I may suggest, ...

1. Include this change in the release notes, as something that matters.
2. Add an "advanced, don't push button unless you know whatcha doin" type of option, to set dmask and fmask to non-default values.

 

Regardless, I'm not sure I follow the logic (i.e. security value) of making that change. If someone who's up to no good has write access to the flash drive content it's clearly game over. So while fmask=77 might help considering future non-root users, I fail to see how fmask=177 helps. An elaboration on the threat model would help here.

 

Thanks for all the good stuff pouring in!

Edited October 12, 2019 by doron