Anon

Yeah the names are stored here: After deleting the other files it still had the references to those names saved in those files. So once I recreated the user it read that information and set the perms accordingly.

Hello everyone. I got it working again. Step taken: - Took the USB Stick and saved the config colder - Flashed the USB Stick with the USB-Creator - Copied the config folder back onto it -> Same Error - Removed the following files: "passwd", "secrets.tdb", "shadow", "smbpasswd" - Restarted -> SMB Working Then I just had to recreate the users. But the awesome thing was I only need to set the name and password. The exact permissions on the shares were retained in the share config. So it only took ~2 min to get all users back and now its happily chugging along. Thanks so so much for all your help

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)

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.

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

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!

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.

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

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

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

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

Here the contents of the WORKING Unraid Servers config folder:

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.

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

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.