[Unraid OS version 6.8.0-rc1 available]

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.

[[6.80 RC1] - Safari (iPad) Logging out unexpectedly]

I can reproduce your issue on my iPad. Needs further investigation.

 

[Unraid OS version 6.8.0-rc1 available]

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

 

[Unraid OS version 6.8.0-rc1 available]

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

 

[Start Array greyed out after Stopping]

Hm, the plugin doesn't take into account encryption state and allows the array to start regardless. Normally this would fail if a passphrase was set and is now missing.

You must have set one or more devices to an encrypted file system and left the passphrase empty (=not set), that is the reason it is asking to enter one.

If you intend to use encryption it is highly recommended to set a passphrase/keyfile. Keep in mind to never loose this, because without it recovery is impossible.

 

Edit

Seeing johnnie's answer, this is indeed the most likely scenario.

[Red Power Menu on top Right disappears and requires restart]

This is not part of stock Unraid, but a Dynamix plugin.

Please close and report under the plugin support section.

[Start Array greyed out after Stopping]

The start button is disabled because you need to enter a passphrase/keyfile which is needed for encryption

(you have encryption enabled on one or more of your array or cache devices)

 

[[6.7.x] Very slow array concurrent performance]

6 hours ago, bastl said:

Quick question to all the people having issues. Is there anyone with a Ryzen or TR4 system having issues? I am on a first gen TR4 and never had any problems. Are only Intel systems affected by this, maybe because of the Spectre Meltdown mitigations??? Just an idea.

This issue is not AMD/Intel related. A fix will be available when Unraid 6.8 is released.

[Users write shows 0 on dashboard while it is writing to unraid]

I made a correction for the wrong write/read values.

Thanks

[Users write shows 0 on dashboard while it is writing to unraid]

1 minute ago, danull said:

so why does it show 0 and 0 on dashboard?

Hmm, that looks like a bug... need to check

[Users write shows 0 on dashboard while it is writing to unraid]

The read and write numbers under User indicate how many shares the user has read and/or write access to.

It is not related to any active writing to a share by this user.

 

[[6.7.2] GUI - Active-Backup network mode - Dashboard page shows errors]

Tested this and working fine for me.

 

Try to re-assign the network settings and see if that makes a difference.

 

Ah... wait

In your assignment eth0 is missing from bond0.

Did you assign a bond to eth1 with member eth2?

If so, you will need to assign a bond to eth0 as well, with just eth0 as member

[[6.7.x] Very slow array concurrent performance]

16 minutes ago, dgreig said:

Unfortunately soon tends to be a very long time!

Behind the scenes a lot of effort is made to make this work properly without any regression errors. Be patient.

[[6.7.x] Very slow array concurrent performance]

15 minutes ago, Hoopster said:

I held out as long as possible and eagerly await a 6.8 RC to test to determine if the problem has been resolved.

The problem is resolved in 6.8.

I guess the RC release isn't too far away.

[Kernel Error]

Please provide more context.

When and what is happening?

How to reproduce the problem?

 

[[6.7.x] Very slow array concurrent performance]

1 hour ago, dalben said:

I'm at breaking point where I have to do something now

Change your mover schedule to outside viewing hours. This prevents writes to the array while reading (streaming) is going on.

 

[[6.7.x] Very slow array concurrent performance]

5 hours ago, Marshalleq said:

If you can find evidence of that, I'll believe you.  And it would make the remainder of the people on this list happy.  But to my eyes, no it hasn't, only through a third party.  Quite poor form in my opinion.

For what it's worth. I can confirm it is on the todo list of Limetech and actively looking for a solution.

[[6.7.x] Very slow array concurrent performance]

1 hour ago, Ancan said:

Would be nice having some counters about disk troughput

In the Main page, click on the blue icon at top right to toggle between display of disk counters or disk throughput

[[6.7.2] Starting a 2nd VM immediately after starting a 1st VM displays 1st VM as paused]

The GUI read the status of ALL VMs at once as soon as one changes state, this may lead to a state which is not up to date and a page refresh/reload is required.

 

It can be corrected by making individual VM updates, but I haven't come around doing this.

 

[Dockers wanting to update, but don't in the end?]

44 minutes ago, local.bin said:

If there a chance of a hotfix for such an issue or is the next version due very soon?

This issue results in many false positives, but still containers which have a true update, are updated.

The -rc release of version 6.8 is imminent, just a little bit more patience 😊

 

[Dockers wanting to update, but don't in the end?]

10 hours ago, bluemonster said:

If the Accept header is instead changed to

@bluemonster excellent find. Tested it, and working fine.

I made a PR with your correction, it will be available in the next version. Thanks

[Dockers wanting to update, but don't in the end?]

My suspicion is something changed at docker hub and there is a mismatch with the Unraid implementation.

 

Needs to be investigated though and strange (if true) it only affects LSIO containers.

 

[[6.7.x] Very slow array concurrent performance]

There is an "internal" list of items/issues which need to be addressed for Unraid 6.8. This is one of them.

 

[Dockers wanting to update, but don't in the end?]

16 minutes ago, jonathanm said:

If it's unraid's fault, then unraid is preferentially picking on LSIO.

Ah, maybe I need to change this part of the code 😉

if (container_author == "LSIO")
then return_message "update ready"
else check_for_update()

 

[Dockers wanting to update, but don't in the end?]

Are you using pihole as DNS server for your Unraid machine?

 

When network connection issues exist, it may result in the behavior you are seeing.