Unraid OS version 6.8.0-rc1 available

8 hours ago, glennv said:

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

Intel 10Gbit support is included - but we're using the kernel "in-tree" ixgbe driver instead of Intel "out-of-tree" ixgbe driver (tree refers to the Linux kernel source code tree).

 

If you really need extra functionality provided by the Intel driver you can do more than pray, you can complain here:

https://sourceforge.net/p/e1000/bugs/

8 hours ago, JoeUnraidUser said:

That's just ridiculous.  I should be able to properly run a script on a Linux system.  At boot I am running several perl, bash, and python scripts with many different parameters.

The USB boot flash is FAT32 file system which does not support *nix style permission bits.  There are also other restrictions with FAT32, for example no symlinks, no hard links.

3 hours ago, Niklas said:

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. 

Why can't you run it as 'root' user?

16 minutes ago, limetech said:

Why can't you run it as 'root' user?

It's a docker container. Don't know how to run it as root. Hmm

 

I use it to backup flash, some appdata and important array stuff, encrypted and uploaded to Onedrive with smart retention. Web gui

Edit: I can probably work around it.

Edited October 12, 2019 by Niklas

2 hours ago, doron said:

So while fmask=77 might help considering future non-root users, I fail to see how fmask=177 helps

You don't understand what fmask and dmask do when mounting FAT32 volumes.  They are octal values that turn off corresponding permission bits.  It causes all files to have only owner RW bits set and all directories to have only owner RWX bits set.

 

There are sensitive files stored on the flash such as your actual passwd file and ssh keys.  We are not going to change this back the way it was.  The USB boot flash was never meant to store anything other than files necessary to boot and config files.  You might notice that since day 1 we have copied the 'go' file to /tmp and executed it from there.

 

Sorry this is an inconvenience but there are many workarounds.

On 10/12/2019 at 1:55 PM, limetech said:

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.

Continue follow read performance issue, I try above suggestion but result same. Then I make test on another machine and same problem found.

 

 

In above setup,

- Array disks ( Harddisk and SSD ) also got slow problem, but SSD faster (~110MB/s) then Harddisk (~60MB/s)

- Cache pool in RAID0 or RAID1 speed normal.

 

 

In above setup, I assign same SSD as cache ( no format, nothing change ), speed was normal ~511MB/s

 

All harddisk connect to LSI HBA and SSD connect to onboard. So problem not on hardware, just array pool ( software ) issue.

 

In my point of view, it worse then 6.7.

 

 

Edited October 13, 2019 by Benson

Could we get a toggle added to gui to disable IPV6 for Ntpd for those of us who don't use ipv6 in our networks?

 

ntpd[2511]: bind(19) AF_INET6 fe80::434:4cff:fe46:a14b%14#123 flags 0x11 failed: Cannot assign requested address

ntpd[2511]: failed to init interface for address fe80::434:4cff:fe46:a14b%14

58 minutes ago, Dazog said:

Could we get a toggle added to gui to disable IPV6 for Ntpd for those of us who don't use ipv6 in our networks?

Settings -> Network Settings -> Network protocol -> IPv4 only

 

EDIT - OK, I see this in my IPv4 system log once also:

Oct 11 20:38:14 Tower ntpd[1876]: bind(19) AF_INET6 fe80::7462:deff:fe79:8567%12#123 flags 0x11 failed: Cannot assign requested address
Oct 11 20:38:14 Tower ntpd[1876]: unable to create socket on br0 (3) for fe80::7462:deff:fe79:8567%12#123
Oct 11 20:38:14 Tower ntpd[1876]: failed to init interface for address fe80::7462:deff:fe79:8567%12

Is it causing a problem or just don't like seeing it in the log? 

 

(Just trying to help triage  )

Edited October 12, 2019 by ljm42

2 hours ago, limetech said:

The USB boot flash was never meant to store anything other than files necessary to boot and config files.  You might notice that since day 1 we have copied the 'go' file to /tmp and executed it from there.

Yet, I can export the Flash Drive via SMB, make it public (or Secure or Private if I assign a user with Read/Write permission), and do anything I want from there.  And you tell me that you don't want to give me the same privileges from the Linux side...

4 hours ago, limetech said:

You don't understand what fmask and dmask do when mounting FAT32 volumes.  They are octal values that turn off corresponding permission bits.  It causes all files to have only owner RW bits set and all directories to have only owner RWX bits set.

Actually I do understand, quite well in fact. Which is why I commented that it makes sense to me to set fmask & dmask to 77 (which is 077). The bit that made me wonder is disabling of the X bit for root (which is what's caused by your setting fmask to 177 as opposed to 077).

Quote

There are sensitive files stored on the flash such as your actual passwd file and ssh keys. 

Understood and appreciated. However this is unrelated to turning off the X bit for root. This is the only bit I'm concerned with.

Quote

We are not going to change this back the way it was.

Nor should you. It makes good sense to make all these files inaccessible to non-root users. 

Bottom line - perhaps you want to reconsider the one bit - X bit for root. It has nothing to do with access to the sensitive files; these will be fully protected from non-root snoopers with dmask=77 and fmask=77.

 

Thanks!

 

Edited October 12, 2019 by doron

6 hours ago, Frank1940 said:

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

 

I did find a solution to this problem.  What I did was to run the Krusader Docker as 'root'.  Anyone, who wants the details to what I did, can find it in the Krusader Docker Support thread.  I have the feeling that this solution may work on a lot of other Dockers...

25 minutes ago, Frank1940 said:

I did find a solution to this problem.  What I did was to run the Krusader Docker as 'root'.  Anyone, who wants the details to what I did, can find it in the Krusader Docker Support thread.  I have the feeling that this solution may work on a lot of other Dockers...

Works fine with the Duplicati Docker too. Thanks.

Edited October 12, 2019 by Niklas

28 minutes ago, Frank1940 said:

I did find a solution to this problem.  What I did was to run the Krusader Docker as 'root'.  Anyone, who wants the details to what I did, can find it in the Krusader Docker Support thread.  I have the feeling that this solution may work on a lot of other Dockers...

Good answer.

5 hours ago, ljm42 said:

Settings -> Network Settings -> Network protocol -> IPv4 only

 

EDIT - OK, I see this in my IPv4 system log once also:

Oct 11 20:38:14 Tower ntpd[1876]: bind(19) AF_INET6 fe80::7462:deff:fe79:8567%12#123 flags 0x11 failed: Cannot assign requested address
Oct 11 20:38:14 Tower ntpd[1876]: unable to create socket on br0 (3) for fe80::7462:deff:fe79:8567%12#123
Oct 11 20:38:14 Tower ntpd[1876]: failed to init interface for address fe80::7462:deff:fe79:8567%12

Is it causing a problem or just don't like seeing it in the log? 

 

(Just trying to help triage  )

It's harmless, I googled it.

 

It appears when NTPD is set to look for IPV4/6 at boot. But since I am Ipv4 only. 

If it fails. and prints that error.

Reading up, if we can disable ipv6 and restart NTPD with a Gui option, it will be IPV4 only. 

I know my ask is VERY minor, like a 6.8.1 or 6.8.54 request

 

 

Edited October 12, 2019 by Dazog

Hi Great job.

@limetech the vega 10 reset bug patch is in this release. Is the navi patch also here please?

https://forum.level1techs.com/t/navi-reset-kernel-patch/147547

 

What should the disk tunables enable_NCQ and nr_requests be set to in this version? I made notes before I upgraded and they were previously set to Auto and 128, respectively. Now they are set to Auto and Auto. The GUI help suggests that Auto NCQ uses the disks' default (which amounts to a queue length of 32) but I always thought that Unraid preferred NCQ to be off (a queue length of 1) because Linux handles queueing better than the disks' firmware. So has the meaning of Auto changed for that tunable?

20 minutes ago, John_M said:

What should the disk tunables enable_NCQ and nr_requests be set to in this version? I made notes before I upgraded and they were previously set to Auto and 128, respectively. Now they are set to Auto and Auto. The GUI help suggests that Auto NCQ uses the disks' default (which amounts to a queue length of 32) but I always thought that Unraid preferred NCQ to be off (a queue length of 1) because Linux handles queueing better than the disks' firmware. So has the meaning of Auto changed for that tunable?

Those tunables date back to I think kernel 2.6 days, maybe even 2.4.  There have been huge changes in block I/O layer over the years and for most things the kernel "decides" the best settings.  Honestly I barely experimented with those settings and nothing I tried seemed to make much difference. YMMV

1 hour ago, SpaceInvaderOne said:

Hi Great job.

@limetech the vega 10 reset bug patch is in this release. Is the navi patch also here please?

https://forum.level1techs.com/t/navi-reset-kernel-patch/147547

 

Yes can add that.

5 hours ago, doron said:

Understood and appreciated. However this is unrelated to turning off the X bit for root. This is the only bit I'm concerned with.

Turning on the 'x' bit for files makes them all executable.  This is not correct for all the files on the flash.  The only executable script on the flash is the 'go' file and optionally a 'stop' file, both of which are copied to /tmp and executed from there.  I don't want all the files to appear executable and I don't want someone trying to execute 'make_bootable' directly from the flash.

 

Seriously how big of an issue is this really?  What scripts are you storing on the flash?

8 hours ago, Benson said:

Continue follow read performance issue, I try above suggestion but result same. Then I make test on another machine and same problem found.

Please open a separate bug report for this issue.  This thread is not the place to debug issues.  thx

On 10/11/2019 at 9:46 PM, limetech said:

re: WireGuard

 

Beware the developers themselves describe this as a "work-in-progress":

https://www.wireguard.com/#work-in-progress

 

and the wg module has not yet been merged into Linux mainline kernel:

https://kubemag.net/news/wireguard-going-to-be-merged-into-linux-kernel

 

We do keep up with changes:

https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/WireGuard.git/

 

with sufficient warnings in place: We've been using it quite a long time now and this tech is really cool!

So just to be sure, is wireguard baked in-kernel for Unraid, or does the plugin run in userspace?

39 minutes ago, Altheran said:

So just to be sure, is wireguard baked in-kernel for Unraid, or does the plugin run in userspace?

There's a wireguard kernel module and the plugin uses the 'wg' user space configuration tool.

 

I also see an update has been published today so we'll include that in next -rc

https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/WireGuard.git/

thx for nice build but now i can´t wake up my server via wol after going to sleep....

 

any tipps?

14 hours ago, ljm42 said:

Settings -> Network Settings -> Network protocol -> IPv4 only

 

EDIT - OK, I see this in my IPv4 system log once also:

Oct 11 20:38:14 Tower ntpd[1876]: bind(19) AF_INET6 fe80::7462:deff:fe79:8567%12#123 flags 0x11 failed: Cannot assign requested address
Oct 11 20:38:14 Tower ntpd[1876]: unable to create socket on br0 (3) for fe80::7462:deff:fe79:8567%12#123
Oct 11 20:38:14 Tower ntpd[1876]: failed to init interface for address fe80::7462:deff:fe79:8567%12

Is it causing a problem or just don't like seeing it in the log? 

 

(Just trying to help triage  )

harmless

4 hours ago, limetech said:

Seriously how big of an issue is this really?  What scripts are you storing on the flash?

It's small. As you say, there are workarounds. I was thinking about the principle of least surprise, or "how many things will break with alt A vs. alt B.".

For me its some logic for setting up /root/keyfile ; for others it might be something else. Anyway - minor annoyance at most, easy to resolve.