Leaderboard

Should be noted that right now, the only SAS chipsets definitely affected is the SAS2116 ie: the 9201-16e. My controller running SAS2008 (Dell H200 cross-flashed) is completely unaffected.

This is great! I've been coming back to this forum multiple times a day waiting for an update. Just today I'd decided to clear & reformat my cache as I don't really trust btrfs, and this update has come just at the right time for me to upgrade with an empty cache and reconfigure things nicely. Hope that the "various non-work-related challenges" have all been resolved and you and your families are safe & well. Thanks for providing such a great system. Will be moving to this in the next day.

Just upgraded my AMD 9300X system, and can now use Host passthrough for the CPUs again without having to make changes to the XML. noVNC error here on any of my VMs. Only thing I see is HT thread 12 is being loaded up to 100%, but I doubt that has anything to do with the beta.

@limetech, could you please add a link to a download for this beta release to the first post in this thread. The reason is that that have been several folks who have update their hardware and find that the new hardware has a NIC that is not supported in the staple releases but is supported in this beta release. Without a link, it is a convoluted process to get the beta installed on their boot drive.

Ok, let me be a little more clear. There is no publicly accessible official timeline. What limetech does with their internal development is kept private, for many reasons. My speculation of the main reason is that the wrath of users over no timeline is tiny compared to multiple missed deadlines. In the distant past there were loose timelines issued, and the flak that ensued was rather spectacular, IIRC. Rather than getting beaten up over progress reports, it's easier for the team to stay focused internally and release when ready, rather than try to justify delays. When you have a very small team, every man hour is precious. Keeping the masses up to date with every little setback doesn't move the project forward, it just demoralizes with all the negative comments. Even "constructive" requests for updates take time to answer, and it's not up to us to say "well, it's only a small amount of time, surely you can spare it". The team makes choices on time management, it's best just to accept that and be happy when the updates come.

Correct!

Painless update from beta 25

While on Beta 25, I already erased/reformatted my Cache Pool (Samsung EVO SSDs).....My Partition Format says "MBR: 1MiB-aligned". Does that mean I'm already good...no need to do any of the erase/reformat stuff in Beta 29????

Wouldn't hurt to check. The only reports thus far with this issue are 9201-16e's. If it doesn't work, all of your drives connected won't be detected. A simple roll back to beta 25 and everything will be back to normal.

Yep. That was it. So dumb 😅

Changed Status to Retest

Just found your posted after I already posted in the mainthread: https://forums.unraid.net/bug-reports/prereleases/unraid-os-version-690-beta25-available-r990/page/12/?tab=comments#comment-10632 I am encountering the same issue and waiting for upstream fix to be merged.

Put it this way. A while ago I implemented code to handle these edge cases with regards to naming of docker containers. It introduced a number of problems and the easy solution was to revert back to the original code as no one noticed the edge case I was trying to solve. The code change I just submitted should handle the all explicitly disallowed characters on the flash. The other edge cases are very rare (if anyone would even set up SHARE1 and share1 with differing permissions) It is an issue, but as you said priorities aren't always in line with something that may only come up once every 10 years, and only if the user has no common sense

If the primary means of configuring Unraid (the web interface) can easily create corner cases that the boot media can't support, should the UI consider that limitation and make adjustments as necessary? As you noted, substitution could just open up another can of works with regard to how this is supported. Other approaches are to leave it as it is with known exposed corner cases that break the UI/functionality, or further limit the UI so those corner cases can't be reached. There are probably more important things to fix, all things considered, but at absolute least I'd hope there would be a warning in the UI saying that share naming containing certain characters could cause complicated conditions (😊) to arise.

Fixed for next release https://github.com/limetech/webgui/pull/748

Depends on when you start counting. This post was yesterday 😉

same here, 6.9 beta25 is stable and no real issues ... besides my docker size point which i couldnt figure out yet ... but thats prolly not beta related.

I've been running 6.9beta25 now for a month and it's great guys. Thanks for all the hard work. Nothing bugging me. Look forward to the stable release.

Soon™

Are Unraid team alive? Last update 12 July. I understand all that covid etc... But beta 25 realy buggy and 6.8.3 didn't have QEMU 5.0 Is there any estimates of release date stable 6.9

This totally seemed to have fixed it for me as well. Over 300GB in a few hours, where earlier I would barely see a few GB before it seemingly crapped out. Thanks for the tip!

@ptr727 (and all other users) I have a theory regarding this problem. I guess its the same thing that causes different transfers speeds for different unraid users with 10G connections. Unraid uses a "layer" for all user shares with the process "shfs". This process is single-threaded and by that limited through the performance of a single cpu core/thread. You are using the E3-1270 v3 and it reaches 7131 passmark points. As your CPU uses hyperthreading I'm not sure if the shfs process is able to use the maximum of a single core or splits the load. If its using 8 different thread, one has only ≈891 passmark points. Since a few days I'm using the i3-8100 and with its 6152 passmark points its weaker than yours, but as it has only 4 cores/threads its core performance is guaranteed at ≈1538 points. Since I have this CPU I'm able to max out 10G and have much better SMB performance. I would be nice if we could test my theory. At first you need to create many random files on your servers cache (replace the two "Music" with one of your share names): # create random files on unraid server mkdir /mnt/cache/Music/randomfiles for n in {1..10000}; do dd status=none if=/dev/urandom of=/mnt/cache/Music/randomfiles/$( printf %03d "$n" ).bin bs=1 count=$(( RANDOM + 1024 )) done Then you create a single 10GB file on the cache (again replace "Music"): dd if=/dev/urandom iflag=fullblock of=/mnt/cache/Music/20GB.bin bs=1GiB count=20 Now you use your Windows Client to download the file "20GB.bin" through the Windows Explorer. While the download is running you open in Windows the command line (cmd) and execute the following (replace "tower" against your servers name and "Music" against your sharename): start robocopy \\tower\Music\randomfiles\ C:\randomfiles\ /E /ZB /R:10 /W:5 /TBD /IS /IT /NP /MT:128 This happened as long I had the Atom C3758 (≈584 core passmark points😞 And this with my new i3-8100: Finally you could retry this test after you disabled Hyperthreading in the BIOS. By that we could be sure how relevant it is or not.

As of Safari 14.0, the VNC Viewer seems to be working perfectly fine. The other pop-ups windows still require a double opening as @CS01-HSsuggested.

New Linux kernel firmware again with newer AMD-SEV. https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=00a84c516078defb76fbd57543b8d5c674a9a2be Can you include it in next build ? @limetech

It's not the superblock, first error lines are the important ones, it's extent tree corruption, loos like part of it was wiped/trimmed, if it's just the extent tree btrfs restore should be able to recover most of your data.

Unmountable, possibly unrelated to the beta. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

ACL is access control list. It's a way of controlling permissions. On a Windows machine you have NTFS filesystem permissions with an ACL and you also have the share level permissions. Typically you control permissions using the filesystem since it offers more control. On *nix with Samba, it will try to map the filesystem permissions to NT filesystem permissions. Since unRAID really only relies on share level permissions to control access this may eliminate some extra overhead. I'm going to test it myself to see if I notice any improvement. If you're not interested in having a public share that you can restrict access to individual folders under the share, you don't really need this enabled.

Just to add for others, the disks that weren't needed seemingly were not spun up until needed so that's good. However, they also seemingly didn't spin down. I have since noted the default spin down delay has been reset to never. I assume it's that. Still testing.

"Time is an illusion. Lunchtime doubly so."

Switching Case-Sensitive Names to 'Yes' on my Time Machine user shares seems to have solved most of it here. My large (~2.6 TB) backups are completing normally again. No other changes. Unraid 6.8.3 + macOS Catalina 10.15.6 (just updated, same in Mojave)

I can and confirm that setting "Settings => Global Share Settings => Tunable (support Hard Links)" to NO resolves the problem. Strange thing is that I never had a problem with nfs shares before. The problems started after I upgraded my Unraid Server (mobo, cpu, ...) and installed a Linux Mint VM as my primary Client. I "migrated" the nfs settings (fstab) from my old Kubuntu Client (real hardware, no VM) to the new Linux Mint VM and the problems started. The old Kubuntu Client does not seem to have those problems... Perhaps also a client problem? kubuntu vs mint, nemo vs dolphin? I do not agree that NFS is an outdated archaic protocol, it works far better than SMB if you have Linux Clients!

Upon further inspection of the code i can see there is already work in progress code for an API in 6.8 via a plugin called unraid.net so this may solve my issue, it doesn't solve the OP's issue though. in the /boot/config/plugins/dynamix/dynamix.cfg file you have this [remote] apikey="bbff6d7320a3cfa74964c58b5c5d3b0XXXXXXXXXXXXXXXXXXXXXXe2bc79518f2e4f0c4" wanaccess="no" wanport="0"