CallOneTech

@dlandon Thank you for putting the effort into making that plugin. Hopefully, it will spark a solid fix that gets implemented into the core of unraid at some point. Until then, it's definitely a step in the right direction.

A value of Forced lower is special: the case of all incoming client filenames, not just new filenames, will be set to lower-case. In other words, no matter what mixed case name is created on the Windows side, it will be stored and accessed in all lower-case. This ensures all Windows apps will properly find any file regardless of case, but case will not be preserved in folder listings. Note this setting should only be configured for new shares. If it doesn't actually write everything as lowercase then that tooltip needs a rewrite. I may be having a brain cramp, but it sounds like setting everything to lowercase is exactly what it does. With that said, I'm willing to test it on a new share if I am mistaken.

I have not. Also, the prospect of making EVERYTHING lowercase makes my soul hurt. Sure, there are Samba limitations with huge folders and I get that. However, unraid's implementation of SMB shares benchmarks at the bottom of the barrel every time it is compared against a similar system. If every other device or storage OS had the same trash performance that would be one thing, but clearly they don't because people keep switching to them and getting better results. The nuclear option is a pass from me until everything else has been explored.

Trying my best to be constructive here, but sadly, the devs don't care about the AD issue or the ungodly poor SMB performance. @nedbrew99 try opening a video inside a folder with 1,000-2,000+ other files in it over SMB. You will have a fresh issue to be sad about after losing your access control options. This is another extremely well documented bug that gets ignored... The goal seems to be piling on new and exciting features that barely work and ignore the past. Before long, the list of broken things will probably be longer than the news of shiny new features. It's a shame that quality support is a thing of the past. I wanted to believe they would fix these issues, but it's been ages since I started shaking trees over it. I wouldn't write them off completely... but it's looking MIGHTY pathetic at the moment. I wonder if creating a public outcry with YouTubers is the better way to get this fixed. No one is willing to do the right thing anymore until they are publicly shamed into acting. Food for thought...

So did this change make it into the latest version or not? Looks like we are getting conflicting reports... Hell, I'm still on 6.10.3 because it FINALLY works and I'm afraid to piss it off, so I'd be the last person to know. Although, it would be nice if it was safe to finally update without fear.

That is a terrible cop-out proving once again that the interest of paying customers doesn't matter until it reaches angry mob status. The official response after an update broke this essential feature to almost everyone running MS systems shouldn't be "Sucks to suck... deal with it". We should not have to start a change.org petition, or get a hoard of twitter and YouTube people to whip the community into a frenzy to get you to do the right thing. You have a 4 page forum post about an issue right in front of you and a bunch more threads elsewhere. That is just the people that actually brought it to your attention. This works like polling, multiply each of our voices by at least 10x and you will start to scratch the surface about how many users are having this issue. Finally, AD is the only way to get proper permissions for any windows based network. It may be an "enterprise feature"... but so was DHCP. That makes your reasoning a very strange excuse to ignore a VERY known (AND FIXABLE) bug in unraid. @dlandon I hope you change your mind of this issue quickly, because your above response is beyond unacceptable and I would expect ALOT of community fallout if that becomes the official hill you folks want to die on. P.S. We can start knocking out the rest of the SAMBA issues that cause terrible overall user quality of life once we get you folks warmed up fixing this mess.

Whoops... Looks like I kicked off yet another firestorm of replies. As a long standing IT veteran (like many of you) I always say, passing the buck to another vendor is the most toxic thing that happens in this industry. We routinely deal with problems that are super complex, and that speck of doubt provides enough cover to yell "NOT MY JOB!!!" from the rooftops. It's annoying when my vendors still do it to me 30 years into the game and it really sucks for end-users, because they don't know any better. I don't think it needs to be repeated that this is a problem with unraid's implementation, and not windows. We can quickly prove that statement by looking at the similar storage solutions out there that work perfectly fine. Here is to hoping we can keep this alive until we get a proper fix that gets merged into future unraid updates.

100% agree that this problem isn't solved. But, it was much worse before it got the traction that it has today. It was basically ignored as an edge case issue that's not worth the effort and now we might actually see a proper fix (on of these days?). Forward progress is progress... We just need to cross the finish line now.

I just want to chime in and say thank you @Geoff Bland for carrying the ball as far as you did 👍 Back when I started rattling cages about this issues ages ago I didn't think we would get a workaround/semi-fix like we have now (2 months, 8 hours and 26mins of uptime as I type this). Thanks to everyone else on the unraid side for finally taking this serious as well. I really wish more was done MUCH sooner, but I'm just happy to get any dev eyeballs at this point. Here is to hoping for an official patch in a future build, so I won't be terrified to upgrade sometime down the road.

@Geoff Bland It's been over a week, how have things been running for you since your config edits were made? I just had an important user account fall off moments ago, during the middle of a 2 day parity rebuild, so it's fresh in my mind... Assuming everything is going well I'll be making these changes the moment I'm able to reboot again.

@Geoff I gave it a shot because it's been 7 days and 1 hour of uptime and unraid started throwing "check_account: Failed to convert SID" errors right in the middle of watching a show off a share. It seems to happen every 7 days or less, it's like unraid just forgets it joined AD. I wasn't able to replicate your issue completely, but I did get a ton of errors while adding the user. It threw a bunch of: auth3_generate_session_info_pac: winbindd not running - but required as domain member: NT_STATUS_NO_LOGON_SERVERS Then it started streaming more of the "check_account: Failed to convert SID" errors. I assume the Failed to convert SID was triggered by all the active sessions that got knocked off when unraid deiced it couldn't see the domain controller anymore. It did create the tester user, but it took about 30-40 seconds to create the account (probably due to the background errors). This is even more annoying for me because my unraid server runs as an esxi vm and usually crashed the esxi host when I reboot it(8 out of 10 times)... but that's a problem for another another day. I'm currently booting my host back up and going through the worlds most awesome workaround to make my unraid server hopefully work for 7 more days 🤢🤮

Dlandon, thank you for jumping in to this thread, it's great to have you here. It would be awesome if samba (4.15.8) was a magic bullet, but please keep in mind that the slow transfer issue mentioned by Steve-UnraidUser doesn't have anything to do with the original bug that the rest of us are trying to resolve. I'm sure you noticed that, but I assume your extremely busy and the last thing I want is for us to miss our chance at a fix because the thread got mixed up with multiple bug reports. Also, thank you Geoff Bland, for offering up the speedy logs and TeamViewer access (when needed).

Frank1940, not an attack against you, and that is a fair point, but it feels like something is broken with unraid itself. My primary evidence to support this claim is that the Join and Leave domain buttons in the web GUI stopped working at some point after 6.8.x too. The only workaround I'm aware of is to shutdown (reboot sometimes doesn't solve it), startup, leave and finally rejoin AD, which seems to refresh whatever keeps spoiling like a jug of milk. However, with the leave & join buttons being broken, you must reboot the server repeatedly to "fix" them. That means you need to do a restart every 3-6 days and then leave/rejoin your domain to keep it working. I understand what you're saying, and I'm happy for any efforts to help with this... but MANY folks from the unraid community are IT veterans. They can all see this is clearly a pass-the-buck type play rather than deep diving into the genuine issue inside unraid. We have all seen it before, anytime you call retail support for anything and everything. The fix is always oddly found by leaving the current support team you're dealing with alone and bugging someone else 🙄 As sad as it is, it seems these days that the only way to get a proper resolution is to shame a person/company into doing what they are supposed to do. It takes a constant pressure campaign that most people don't have the stomach for (and companies know this!). It shouldn't work that way, but it's just how it is. I'm 110% positive that if the talented unraid devs got serious about this issue, they could either resolve it or explain it well enough for the Samba devs to make a patch (if that's the root cause).

Windows server 2019 Standard Fully patched (VM on ESXi) over here. This all started somewhere between 6.8.x and now. Geoff summarized this issue very well, but I'm more than happy to do any testing or give over any info that will lead to this getting patched. Hopefully we can finally get an official response to this... I have been rattling cages, resurrecting threads and asking on the discord. So far all I have founds is that everyone using AD is suffering from the same issue and crickets from support. It's a bit frustrating to not at least get a "sucks to suck, deal with it" message after all this time.

First, thank you to everyone for contributing to this thread so far. There is 100% something funky under the hood regarding the AD integration and samba in general. I came to the same conclusion as Brianara3 and mouseskowitz about needing to reboot the server to rejoin AD. However, restarting the server just for the sake of regaining the ability to leave and rejoin the domain isn't a proper fix. Without a clear cause as to why the connection with AD failed, we are just waiting for it to randomly break again. Please post back on this thread the next time your connection breaks, and maybe we can start to identify a pattern. For all we know, this bug could be time-based, like a jug of milk.

Frank1940, Sorry if I was unclear. I was trying to say I could NOT find the scripts and was asking for an example of any such script to manage the AD related stuff via terminal that I can study.

As the topic states, I'm trying to manually join and verify AD domain membership via the terminal. There seems to be a bug in the web GUI that doesn't allow you to leave a domain. I also have a feeling it is in some strange stuck state that could easily be proven or disproven with manual testing in the terminal. I have seen posts mentioning doing exactly what I am attempting with scripts, but I haven't seen any examples of exactly how it was done. I always could dig through the code to see how the web GUI button works, but I was really hoping to avoid doing that if possible.

Glad to see this isn't just an isolated issue I'm having. I'm starting to think this is a a legit bug in need of fixing... I was hoping to hear a little more helpful feedback from folks that focus more on the AD integration features. Hopefully if we make enough noise we can get some official input on why the AD/file permissions side of things is so buggy. My plan is to take another deep dive into this issue today and I'll try my best to share my findings in this thread until it gets the attention it needs for a resolution.

Did you ever find a solution? I'm also having AD related permissions issues. All the forum posts I have found so far lead to dead ends, so I figured if I shake enough trees something might just fall out 🤷‍♂️

Sorry to dig up this old post, but how did you go about joining the domain from the terminal? I'm having a domain related issue and I believe that may help.

Summary: I noticed some seemly random issues with my SMB shares since updating from 6.9 to 6.10.2. The latest example is losing access to a media share in the span of 6 hours after making no changes to any systems. It literally worked at 3am, I went to sleep, I then woke up and found I had lost access to the SMB share. Bizarre stuff... Log entries (identifying info removed): [2022/06/10 12:02:55.282902, 0] ../../source3/auth/auth_util.c:1927(check_account) Jun 10 12:02:55 unraid smbd[2715]: check_account: Failed to convert SID S-###removed### to a UID (dom_user[DOMAIN\username]) Troubleshooting: left and rejoined the domain via the UNRAID web GUI Verified AD health (Repadmin /replsummary and DCDiag /Test:DNS /e /v) all tests passed Verified no errors in domain controller event logs Rebooted client computer (standard window access denied error: \\unraid is not accessible. You might not have permission.. blah blah...) Restarted UNRAID array (while leaving and rejoining AD in web GUI) I'm fine with things breaking after changes or updates, but it's annoying when things randomly crap out like a jug of bad milk. I'm happy to take any suggestions or post any additional information/logs. EDIT #1 After sinking more time into this issue I believe I narrowed it down to UNRAID not being able to successfully communicate with AD. The check_account entry appears with the same username ( same one I joined AD in the web GUI with) regardless of which account tries to access a share on the client end. I also don't see the UNRAID listed anywhere on my AD domain side which tells me it probably isn't correctly joining the domain. What are some command line things I can run from UNRAID to verify or reestablish the AD connection? Leaving, switching to workgroup and then rejoining AD on the web GUI doesn't seem to be getting it done for me. EDIT #2 Since the AD connection is broken (but UNRAID doesn't seem to know this) I disabled AD and went to workgroup mode. This allowed my shares to be accessible again by setting all the shares to public, BUT it means I lost complete control over everything because it's 100% public and ignoring my previously working AD file security settings. Needless to say this is a sucky Band-Aid solution and I hope someone can chime in with a proper way to correctly reestablish my AD link between UNRAID and my domain. EDIT #3 Seems I was able to view and list the files, but I can't play or copy them without getting a permissions error. This is officially a crap "day off" that was supposed to be spent lazing around catching up on tv shows...

I'm not sure if I would call this 100% fixed, but it's definitely a usable work around if anyone with a similar issue is reading this thread in the future. I didn't mess with the RAM cache settings yet, but I did turn on Turbo Write. Since enabling it I have been able to run a MS Explorer SMB drag and drop style transfer from another machine (2 huge writes total) without having either transfer fail. The Explorer based copy has slowed a bit. The bulk of it happens between 80-100MB/s which tells me it is still RAM caching like crazy. It still goes near 0B/s when flushing and if it is a single huge file it will completely bottom out at 0B/s. The good news is these stalls don't last long enough to cause the transfers to fail anymore 🥳 Turbo Write seems to allow it to flush fast enough and prevent the major stalls that I was seeing before. My attached graph seems to verify this because the gaps between the bursts of array write activity are MUCH tighter than they were before. I haven't timed it, but I assume it was stalling at 0 for ~60-90 seconds VS maybe 5-15 seconds with Turbo enabled. I assume I could reduce the stalls even more by changing the max RAM cache to 4GB as per @JorgeB, but I dont want to touch anything because it is finally running without me having to babysit. Big thanks to everyone for the helpful insights.

I'm looking into turbo write and will give that a try when I move my next batch of data over. What do you think a good starting point would be for decreasing my RAM cache? Also, what is the preferred method for setting my new RAM cache amount in Unraid?

I am in the process of moving ~15TB of data to a 28TB array and seem to be seeing some strange behavior. I believe it might be explained with the core function of how Linux manages memory, but I wanted to double check before going down a rabbit hole... Setup: Unraid machine has 72GB of ram with a 10GBit NIC. Caching is Disabled Parity is Enabled All Disks are Spinning Transfer Methods: Windows Server 2012 drag and drop between a local disk and Unraid share (causes the stall) MS Robot copy (works fine unless another machine uses drag and drop to cause a stall) Experienced Behavior: I attempt a copy using MS Explorer via drag and drop or copy and paste. The transfer begins at 150-180MB/sec. This part strikes me as odd because it seems to be the max read speed of the source disk. However, I would expect the write speeds to be closer to ~50MB/sec with parity on and no Unraid cache drive. The only thing that makes sense is that Unraid is caching my transfer into a slice of the system's 72GB of ram. This theory is also supported because the chart for array writing activity is near 0/MB at the start of the SMB transfer (while the ram cache is filling). The problem seems to be that once the ram cache fills, it begins to flush its data to the array at a much slower write speed. This process bogs down the whole system and causes any SMB writing from other machines in the network to drop to 0. I also see the array write speed chart spike up to maximum write speed. If all the SMB writes have stalled, this must be the ram cache trying to flush? It feels like I'm filling my ram cache with a fire hose and then trying to empty it with a straw. This behavior would be completely fine if I were transferring ~50GB or less... but not so much with the big load ups. My MS Robocopy has been running like a champ for the last 15 hours. It copies slower than MS Explorer and that slower speed seems to avoid the stalling situation. However, I can instantly replicate the stall if I start a drag and drop transfer in MS Explorer from another machine. How can I better manage some settings to stop my transfers from stalling? I'm fine with the slower write speeds because all this stop and go nonsense is probably just as slow. Or do I have it completely wrong?