Problem: Suddenly can't access SMB Shares on any PC

[Anon]

Hi,

 

this morning after shutting down my Unraid server to do some changes I corrupted my boot drive. Because of this it went to read only mode. I shut my server back down and repaired the drive via checkdisk from windows. Because Checkdisk detected a few problems with the drive I then decided to restore a backup I had previously made.

So I ran the usb creator and used the backup file that I took when the usb drive went into read only mode.

 

The server booted fine. No Errors that I could see. All dockers came up and are happily running. After a while I noticed that none of my windows PCs can access any of the SMB shares.

 

Steps tried:

- Rebooted a few of my VMs

- directly tried to open \\TOWER and \\192.168.50.3 of my Server (as well as directly tring a public no password share)

- pinged both tower and 192.168.50.3 -> worked

- removed my stored credentials in the credential manager

 

The Error I get:

 

If I click on Diagnose and let it run for a while  this shows up:

 

Anyone got an idea what I could try?

tower-diagnostics-20240303-2106.zip

Edited March 3 by Anon
Added more Info

[Frank1940]

Found this:

Mar  3 19:05:07 Tower winbindd[13208]:   Copyright Andrew Tridgell and the Samba Team 1992-2022
Mar  3 19:05:07 Tower winbindd[13208]: [2024/03/03 19:05:07.912296,  0] ../../lib/tdb_wrap/tdb_wrap.c:65(tdb_wrap_log)
Mar  3 19:05:07 Tower winbindd[13208]:   tdb(/var/lib/samba/private/secrets.tdb): tdb_oob len 16408 beyond eof at 4096
Mar  3 19:05:07 Tower winbindd[13208]: [2024/03/03 19:05:07.912313,  0] ../../lib/tdb_wrap/tdb_wrap.c:65(tdb_wrap_log)
Mar  3 19:05:07 Tower winbindd[13208]:   tdb(/var/lib/samba/private/secrets.tdb): tdb_transaction_recover: failed to read recovery record
Mar  3 19:05:07 Tower winbindd[13208]: [2024/03/03 19:05:07.912325,  0] ../../source3/passdb/secrets.c:67(secrets_init_path)
Mar  3 19:05:07 Tower winbindd[13208]:   Failed to open /var/lib/samba/private/secrets.tdb
Mar  3 19:05:07 Tower winbindd[13208]: [2024/03/03 19:05:07.912332,  0] ../../source3/winbindd/winbindd.c:1578(main)
Mar  3 19:05:07 Tower winbindd[13208]:   Could not initialize domain trust account secrets. Giving up

 

On the GUI, go to   USERS    and see that you still have the Share Access users in place.  ( You might want to recreate them...)    Are you using Active Directory?

 

GUI again, go to   SETTINGS    >>>   Global Share Settings   and verify that you have enabled   'User Shares'   and   'Disk Shares'

 

I believe you have a lot of hidden shares.  There was an instance a while back where a user had problems accessing hidden shares. 

[Anon]

Hi Frank,

 

thanks for the reply. I am able to see all my users. Following your advice i deleted and recreated 2 of them for further testing.

=> Rebooted VM -> Same Error. Added the user back to the credential manager + reboot -> Same Error.

 

A while back I had once activated the Active Directory feature in unraid though I had problem so I turned it back of. I currently have some PCs that are in the Domain and some that are not. Before the read only incident the shares where working on both types of PCs.

 

Global Share Settings has Disk on Auto and User on Yes. (This is analog to a second Unraid maschine that I am using that still works just fine.

[itimpi]

Just a thought - have you checked the Export settings for the shares to make sure they are being exported and not exported hidden?

[Anon]

Hi Itimpi,

 

yes they are all still exported. Some hidden, some normal export and some public export.

I even made a new test share -> exported -> public

 

I have also disabled and reenabled SMB in this menu (+ Server restart)

 

sadly error message is still stayin the same.

I do have a second and third unraid server running. Those still work as expected.

Maybe something went bad due to the backup restore? I did take the backup during a phase where unraid put the usb stick in a errored state.

But aside from the smb not working all else seems to be okay...

[Frank1940]

Problem is that I suspect that you should not have any reference to the     secrets.tdb   file in your syslog.    ( You could check this on your other server...)

 

A quick google of the file name confirmed that is involved in the Samba password scheme.  With an error message that indicates a problem with that file, I would suspect that you would have a problem.   

 

In the    /config   Folder on your flash/boot drive, you will find these three files:

 

You can open then with a straight text editor (Even NotePad with recent Windows releases will handle these files correctly)  and have a look at them.  All of the should look something like this:

You could also look at these files on your other server. 

 

I know that if you forget the passwords, the following procedure can be used to reset all the passwords for both root and Share Access users:

 

    https://docs.unraid.net/unraid-os/manual/troubleshooting/#lost-root-password

 

[Anon]

On my Flash drives config I have the following files:

On my other Server that is working perfectly I do not have a "share.cfg" file. Could this be a potential cause? (I could try deleting it / renaming it?)

I do not know why this file was created and what exact job it has. I do have disk2 disabled currently for shares and am wanting to replace it soon due to some errors.

[Anon]

Here the contents of the WORKING Unraid Servers config folder:

[Frank1940]

10 minutes ago, Anon said:

Maybe something went bad due to the backup restore? I did take the backup during a phase where unraid put the usb stick in a errored state.

 

That is a distinct possibility.  (I make it a practice to always make a backup of the boot drive any time I update the system as soon as I am sure it is running properly.) 

[Anon]

Regarding the 3 files: "passwd, shadow & smbpasswd they do look like in your example.

Is there a way to maybe just reset all of it?

 

I have no problem with just starting fresh and recreating all necessary users. I have all saved in a password database and could easily recreate them all and associate them to my shares

 

That said I did recreate 2 users already and then used a Testing VM to try accessing the SMB Shares but no luck

Edited March 3 by Anon

[Anon]

I am not quite sure what the best way forward would be. I could let the USB creator just flash a working happy version without problems onto my usb-drive.

But if I then just copy almost everything from the config folder to the drive I am not sure if it will solve the issue.

And if I do not copy it over I would probably have a lot of configuration that would get lost..

 

 

[Frank1940]

You do have a    secrets.tbd    file in the /config folder on the flash drive on both of your servers.  (I believe this file is copied from the Flash drive to the RAM disj as Unraid boots up.)   I looked at my two servers  and the size on both servers is 420KB (430,080 bytes).  (Both are these server are configured almost identically so this was not surprising.)  On your working server, the size was 430KB.  What is the size on the one with the problem? 

 

Here is one result of a Google search on Unraid net for secrets.tdb:

 

https://forums.unraid.net/topic/149487-how-do-i-fix-these-samba-errors/

 

And a second one:

 

https://forums.unraid.net/topic/38469-smbd-fails-to-start/

 

[Frank1940]

You don't have to delete file, just rename it to secrets.tdb.old

[Anon]

Thanks the size difference does seem to be a great indicator that the secrets.tdb is the problem. All my servers and old backups have it at the 430 size. Thanks I will rename it to old and see what happens after a reboot

=> After stopping array it recreated the same secrets.db with the wrong size. I deleted that one and then restarted. Lets see what happens

Edited March 3 by Anon

[Anon]

Sadly the secrets.tdb gets recreated to the same wrong size after reboot. And the error still appears.

[Frank1940]

Let me ping @dlandon as he seems to have some knowledge in the area.  I don't think he is based in the USA so it may be a while before he responses...

[Anon]

Thank you. My most critical services run as a docker and those can still access the files so its not too bad for now. I'll go to bed soon anyways and check back in tomorrow. Thanks so much for your help so far!

I hope I can find out how exactly this secrets.tdb is being created and fix it at the root.

[dlandon]

12 hours ago, Frank1940 said:

Let me ping @dlandon as he seems to have some knowledge in the area.  I don't think he is based in the USA so it may be a while before he responses...

I'm actually in Texas, US of A.

 

I really don't see anything in the diagnostics that necessarily indicates an SMB issue.  I'm leaning towards a network/routing issue.

 

I see a few things that should be checked/confirmed:

• Gateway is 192.168.50.1 but DNS server is 192.168.50.5.  Is this correct?
• It appears the router is supplying the Unraid IP because Unraid is setup to use DHCP?
• You have said you can ping and log into Unraid so I'm confused why SMB wouldn't work, especially when using the IP address.

There is a domain defined - 'loesle'.  I suspect this may have been from using AD at some point and is left over.

 

You might try re-configuring SMB Settings.  Change a setting and the apply it to regenerate the config file.  Do the same for your network settings.

 

As a side note, your access to Unraid is limited to http://.  Redo the 'Management Access" settings and enable https://.

[Anon]

Hello Dlandon,

 

thanks for your reply. The Gateway and DNS ist correct.

I could change to static IP but I have also just set my router to give it a static IP via MAC-Address

And yes I can ping the Unraid Server both via IP and Name. And the Access does not work neither with IP nor Name.

The Domain was indeed loesle but currently I do not want to use it via AD.

 

 

I have turned SMB Support fully off and back on again. which sadly didn't change it.

So now I have disabled/enabled netbios for SMB and disabled and reenabled bridging for Network. Afterwards I started the array back up => Still same error on main PC and VM I tested it with.

The  troubleshooter still gets me the following error:

If I do the same with a known wrong IP to cause the same error message it gets me a different result:

So it is detecting something.

 

I also turned on the HTTPS support thanks!

 

[dlandon]

44 minutes ago, Anon said:

The  troubleshooter still gets me the following error:

That looks like it might be a port issue.  SMB uses porrt 445.  Is there a chance it's being blocked somewhere or in use by a docker or VM somehow?  It's very close to port 443 used by https://.

[Anon]

Hello dlandon,

I have now switched to a totally new USB-Drive as the other one didn't recognize anymore on my windows PC when I went to analyze it further.

I redid your steps above and still getting the same error.

 

With the Port 445 -> I fully disabled Docker to test around and have zero VMs running on that machine.

I do believe the error is somewhat related to the corrupt secrets.tdb as its a totally different size than my other 2 servers and to franks.

But deleting it only makes it recreate the same corrupt version..

[Anon]

As I created the USB Stick from a backup that might have already been corrupt:

 

- Could it be a viable idea to just make a fully fresh system with the USB-Flash Creator (V. 6.12.8) and then copy the config files from the current backup (V 6.12.6) onto it?

 

Another Idea would be to use the internal Upgrade System that is available. It is showing me that the new version is available but I am not sure if it will be as fresh of a system as writing it completely new.

[dlandon]

1 minute ago, Anon said:

 

- Could it be a viable idea to just make a fully fresh system with the USB-Flash Creator (V. 6.12.8) and then copy the config files from the current backup (V 6.12.6) onto it?

Yes.

 

1 minute ago, Anon said:

 

Another Idea would be to use the internal Upgrade System that is available. It is showing me that the new version is available but I am not sure if it will be as fresh of a system as writing it completely new.

That won't change the configuration, but will update the system and might be worth a try.  I would do this of the two choices.

[Anon]

I did the Upgrade via the internal updater. The update was succcessfull but the error is sadly still there

 

Idea: Is it possible to just delete all contents of the config?

If so I would back up the current config. Then delete everything. Reboot. Set up one share to export and create one test user.

 

That way I could test that smb at least works if I start completely fresh.

Then I either go from there and manually configure everything again.

Or I can copy over a few of the backed up files (depending on which are safe to copy back and which could be related to the smb error)

 

Edited March 4 by Anon

[Frank1940]

37 minutes ago, Anon said:

- Could it be a viable idea to just make a fully fresh system with the USB-Flash Creator (V. 6.12.8) and then copy the config files from the current backup (V 6.12.6) onto it?

 

 

If you go down this route, use a new quality USB drive,  install a trial license, and make sure that SMB is working.  Then make a back-up that new flash drive.   Instructions are here (if you need them):

 

       https://docs.unraid.net/unraid-os/manual/changing-the-flash-device/#backing-up-your-flash-drive

 

(I am suspecting that there are some corrupted files on that flash drive...)  When you get that new flash drive working, you can transfer the old license to that new drive.