[6.10.3] Intermittent SMB Issues After 6.10.2 Upgrade

On 10/31/2022 at 12:01 PM, nomadgeek said:

I have also been experiencing this issue for quite a while. I don't have a lot to add that others haven't already said but I wanted to register my voice anyway.

 

The only thing I can suggest to everyone experiencing the problem where Samba forgets users exist after ~ a week and you need to leave/join. I have found that giving the command 'net cache flush' a few times on the unraid console solves this problem.

 

I did use tdb for a while but switched back because I was having other issues using that. I may go back and try that again.

Hope we get an official fix soon; we've been dealing with this problem for months and I'm really getting tired. FreeNAS may be in my future.

 

I haven't seen any other mention of your comment, and while I hadn't tried anything beyond just rebooting, which did resolve it for a bit, I ran the 'net cache flush' once while receiving the 'Failed to find local account with UID for SID' error and all my users were immediately able to access the shares again. Here's to hoping this continues working until a permanent fix is released.

Edited December 15, 2022 by giggity

On 12/14/2022 at 9:30 PM, giggity said:

 

I haven't seen any other mention of your comment, and while I hadn't tried anything beyond just rebooting, which did resolve it for a bit, I ran the 'net cache flush' once while receiving the 'Failed to find local account with UID for SID' error and all my users were immediately able to access the shares again. Here's to hoping this continues working until a permanent fix is released.

I went back to tdb after the latest release and it seems to be working. I'm probably going to move away from unraid for my org. file storage to something with better AD integration in the future though.

Looks like your problem is solved.  This is from 6.11.5 (testparm):

        idmap config * : range = 3000-7999
        idmap config * : backend = tdb

 

On 12/22/2022 at 11:20 AM, dlandon said:

Looks like your problem is solved.  This is from 6.11.5 (testparm):

        idmap config * : range = 3000-7999
        idmap config * : backend = tdb

 

I don't seem to have the same on my setup, unfortunately.

 

       idmap config * : range = 10000-4000000000
        idmap config * : backend = hash

 

The more SMB connections, the more frequently it occurs. I've had to run "net cache flush" three times thus far today, despite being on 6.11.5.

 

 

Edited February 5, 2023 by giggity

Yep, this still occurs for me too from time to time (on 6.11.5).  I haven't bothered to do the workaround posted earlier in this thread yet, but I'll probably give that a shot pretty soon.

On 12/22/2022 at 12:20 PM, dlandon said:

Looks like your problem is solved.  This is from 6.11.5 (testparm):

        idmap config * : range = 3000-7999
        idmap config * : backend = tdb

 

 

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.

Is anyone else still having issues with this? We're on 6.11.5 and I still have intermittent issues with AD users connecting to shares.
Error: 
check_account: Failed to convert SID S-1-5-21-1840556552-2515633444-774320697-5697 to a UID

Any ideas on what I'm doing wrong here? 

11 hours ago, kr295708 said:

Is anyone else still having issues with this? We're on 6.11.5 and I still have intermittent issues with AD users connecting to shares.

 

To my knowledge, there has not been a fix implemented by Unraid. And it sounds like it's not really high on the priority to fix. 

12 hours ago, kr295708 said:

Is anyone else still having issues with this? We're on 6.11.5 and I still have intermittent issues with AD users connecting to shares.
Error: 
check_account: Failed to convert SID S-1-5-21-1840556552-2515633444-774320697-5697 to a UID

Any ideas on what I'm doing wrong here? 

Yep.  I'm still getting bit every few weeks or so. 

16 hours ago, kr295708 said:

Is anyone else still having issues with this?

 

Yes, unfortunately, absolutely nothing has changed in the matter.

@unraidster has worked out that there is a second error pattern, which I had already described here in the thread, that seems to overlap with the error pattern from the initial post here.

 

I really hope that the Unraid team finally takes care of the matter!

 

anyone have any updates on this? found anything that fixes the issue for them? 

Any updates on this as I am experiencing this exact issue.  running 6.11.5 and have tried the change to set this in the smb-extras
 [global]
idmap config * : backend = tdb
idmap config * : range = 1000-7999      
idmap config <shortname> : backend = rid
idmap config <shortname>: range = 10000-4000000000

 

but was unable to access anything with windows file explorer and could not reset permissions no matter what I did.  Had to set back to old set-up and is working for the moment

when you say you had to set back to old set up... what is your old setup? how do your windows users access the shares? 

So I have an Active Directory set-up at my home and currently it is hit or miss if someone will be able to access the unraid shares.  if I look in the logs I see certain users just randomly stop being able to access things.  I just removed the idmap changes to the smb-extra, but it seems that the reboot is what actually fixes it for a day or two, then it randomly has someone not able to access the sahres

yup thats exactly what Im experiencing

So I gave up on having the UNraid in Active Directory.  I just has public shares in unraid and map folders accordingly.  So far so good, but anyone can see anything.  not a problem for my set-up but may be for others

 

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

 

@CallOneTech  have you tried switching to using case sensitive file names?   This made a big difference for me in folders with lots of files in them.

7 hours ago, itimpi said:

@CallOneTech  have you tried switching to using case sensitive file names?   This made a big difference for me in folders with lots of files in them.

 

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.

21 minutes ago, CallOneTech said:

Also, the prospect of making EVERYTHING lowercase makes my soul hurt.

It does NOT do this.   I just means that case is preserved rather than all filenames being treated as case independent within samba

21 hours ago, CallOneTech said:

AD issue

There is a new plugin to also tweak the AD settings to try and come up with the solution(s)

 

 

1 hour ago, itimpi said:

It does NOT do this.   I just means that case is preserved rather than all filenames being treated as case independent within samba

 

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.

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

Has there been any official reply on this?  I have just started running into this issue as I use Unraid as a backup destination.  Using the net cache flush command instantly returns access to my AD user.  For now I have that command running as a cron job so hopefully this bandaid will last until this gets an official 'fix'.