1 hour ago, bonienl said:

 

newperms only operates on user content in /mnt, it doesn't touch internals.

 

 

Try it as shown in the previous screen attachment and you will see that when passing in "." instead of using the current directory the user is in, it for some reason interprets it to mean the current location of the script which is /usr/local/emhttp/plugins/dynamix/scripts/

 

It used to work perfectly before whenever these changes were done.

 

Do you need me to attach another screenshot to show how to reproduce the bad behavior?

 

 

 

 

 

Setup for "newperms ." misbehavior, here are the raw command to duplicate this from a root command prompt:

 

cd /mnt/cache

mkdir tmp

cd tmp

touch testfile.txt

ls -al .

ls -al  /usr/local/emhttp/plugins/dynamix/scripts/

newperms .

ls -al /usr/local/emhttp/plugins/dynamix/scripts/

ls -al .

 

 

Setup:

 

Execution:

 

Examination of the bad behavior:

 

Edited June 18, 20224 yr by BRiT

Working perfect then upgrade to 6.10.3 online. Reboot after upgrade to 6.10.3 fails.

"Boot error" 

 

Download the zip file, then overwrite all of the bz* files (and changes.txt) on the flash drive with those in the zip.

 

If it still fails, run make_bootable.bat as administrator

 

Failing the above, your flash drive is pooched and should be replaced.

Thanks for the quick reply.

I had tried this solution from reading a prior post but forgot the "run make_bootable.bat as administrator".

Up and running again.

Thanks for the reminder!

Updated from 6.10.2 with no issues.

Wow, the upgrade process for Unraid sure is simple. Upgraded on Saturday and everything is smooth and as stable as a vintage small block Chevy V8!!!! Excellent work guys. Quite impressed with Unraid.

On 6/15/2022 at 7:14 PM, wgstarks said:

The TimeMachine docker is working great for me. You might want to check that out. Supports AFP too although I haven’t tried that.

I had a Time Machine issues too on Unraid 6.10.x. So I tried the TimeMachine docker and its working for me too 👍

On 6/15/2022 at 12:42 PM, Kagami Hiiragi said:

there's no anything on the screen after the BIOS screen

I've found the problem, it was related to fast boot option & uefi boot settings of my motherboard's UEFI.

I don't know why I didn't discover it earlier. I've made some changes to boot settings and now it boots correctly on 6.10.3 too.

Was removing the Shared acces whit the root login intentionall ? I was generlly confused that none of my Folders and some Dockers worked anymore and only sayed acces denied.

52 minutes ago, CEO Primesky said:

Was removing the Shared acces whit the root login intentionall ? I was generlly confused that none of my Folders and some Dockers worked anymore and only sayed acces denied.

Not sure what you mean?    The ‘root’ user has never been permitted to have private or secure access to network shares - and accessing a Public share makes the username irrelevant.

I've been waiting for things to settle down, and looks as the dust has finally settled.  I've never been one to trust any software release that ends in ".0", especially on a system that I rely on daily.

 

Have a few days off, so I decided it was finally time to update from 6.9.1 to 6.10.3.  With a recent flash and appdata backups, all plugin and docker updated, I updated from the remote GUI.

 

And just like that, Malta-Tower is updated, back up and running.  I did a restart (from the GUI), and my heart started racing when the system reported several of my drives were missing.  Then I noted they all shared the same HBA.  Powered down/up, and all is happy.  Guess my HBA wanted that hard start to reinitialize.  After a day of poking around, all is working great.

 

Thanks to all at LT and the folks who worked through the issues with 6.10.  Just dumb bad luck with the kernel bug discovered at the same time this was rolled out.  Stuff happens.  It is how you deal with the stuff once you find you've stepped in it which matters.  Some dev teams will insist nothing is wrong.  You folks took the flack, stayed in communication with the community, and found the needed work arounds.  Kudos to all.

Lost my GPU passthru to Windows VM on upgrade from 6.9.2 to 6.10.3

 

The Windows VM sees the passthru but stops the GPU for reported problems code 43.

 

Tried removing the Iommu binding, restart, add Iommu binding and reboot, no go.

 

Trying updating GPU drivers in Windows now.   Triangle gone in device manager now, reboot VM.

 

Ok solved now.

 

 

Edited June 26, 20224 yr by Paul_Ber
Solved

12 hours ago, Paul_Ber said:

The Windows VM sees the passthru but stops the GPU for reported problems code 43.

Which GPU model? For older Nvidia GPUs we found that the below fixes it:

 

https://forums.unraid.net/topic/124890-gtx650ti-code-43-with-windows-10/?do=findComment&comment=1139615

 

Just now, Ruato said:

From the 6.10.0 summary of changes: "Added ability to schedule pool 'balance' and 'scrub' operations and calculate whether a full balance is recommended."

 

How can I setup the above operations? That is, I don't find related settings from Settings -> Scheduler.

 

Thanks!

 

It's done on a per disk/pool basis on their individual settings page, which you can get to from main tab 

34 minutes ago, tjb_altf4 said:

It's done on a per disk/pool basis on their individual settings page, which you can get to from main tab 

 

Yes, I noticed and tried to delete the post but I was too slow.  Thank you!

 

Updated from 6.10.0 rc3, so far so good.

Upgraded from 6.9.1 and good so far

Hi, just upgraded from 6.9.3 and everything seems to be working fine so far except for what seems like a permissions issue with Sonarr.

 

Whenever I try searching I'm getting the following error:

 

[v3.0.4.1126] System.Data.SQLite.SQLiteException (0x80004005): attempt to write a readonly database

 

Looking at the permissions in the appdata folder between Radarr and Sonnar I noticed that Sonarr has more files owned by root/root vs nobody/users (specifically the .db file which I'm assuming is the cause of the error)?

 

Searching led me to suggestions to use "Docker Safe New Perms" but that doesn’t appear to touch the appdata folder.

 

Should I just manually chmod the files/folders?

Edited July 5, 20224 yr by unRaide

7 minutes ago, unRaide said:

Hi, just upgraded from 6.9.3 and everything seems to be working fine so far except for what seems like a permissions issue with Sonarr.

 

I had permission issues with my dockers after the upgrade and fixed the problems by running the following:

chown -cR nobody:users /mnt/user/appdata/*
chmod -cR ug+rw,ug+X,o-rwx /mnt/user/appdata/*

 

Updated from 6.9.2 to 6.10.3 via the GUI.  After downloading the newer version, I clicked on reboot in the GUI as prompted and the server froze with a kernel panic.  I had to reboot via IPMI and the server booted up under 6.10.3 and started a parity check, even though a parity check had just been run at the beginning of the month.

Now my SSL key and HTTPS certificate is not working.  Other than the SSL key and HTTPS certificate, everything seems to be running.

2 hours ago, mifronte said:

started a parity check, even though a parity check had just been run at the beginning of the month.

You will always get a parity check for unclean shutdown

Anyone having issues with the plugin "system temp" after the update I can no longer get the plugin to display sensors on both servers. I posted under the plugin thread, but no one there.

1 hour ago, PSYCHOPATHiO said:

Anyone having issues with the plugin "system temp" after the update I can no longer get the plugin to display sensors on both servers. I posted under the plugin thread, but no one there.

No problem. ( Syslinux with "acpi_enforce_resources=lax" )

Edited July 7, 20224 yr by Vr2Io

Upgraded from 6.9.2 . .

No issues.

 

A small delay as Nvidia driver downloaded, but system message explained it all.