drevel123

Mein Problem konnte glücklicherweise im englischen Thread von @Frank1940 gelöst werden. Im /config - Ordner auf dem Stick liegen drei Dateien, die Infos zu den (SMB-) Nutzern in Unraid enthalten. Löscht man diese (oder benennt sie um/ verschiebt sie in einen anderen Ordner), werden diese beim nächsten Systemstart neu erstellt. Dies heißt natürlich auch, dass dann alle Nutzer neu angelegt und die Berechtigungen neu vergeben werden müssen (beim ersten Systemstart muss auch das root-Passwort neu angelegt werden). Dies habe ich gemacht und nach dem erneuten Anlegen der Nutzer & Berechtigungen funktionierte alles wieder. Wo genau das Problem lag weiß ich jedoch nicht - vielleicht war eine der Dateien beschädigt oder das Neu-Erstellen der Dateien hat ein notwendiges Reset an anderer Stelle ausgelöst. Es handelt sich um folgende drei Dateien. Diese können auch mit einem Text-Editor geöffnet und inspiziert werden, es sollten jeweils Zeilen mit den Nutzern enthalten sein: passwd smbpsswd shadow Es kann natürlich sein, dass dies ein sehr spezielles Problem war - verursacht durch den Systemabsturz. Sollte zukünftig aber jemand anders ein ähnliches Problem haben, kann es sicher nicht schaden diesen Lösungsweg auch einmal zu probieren Hier der Link zum originalen Lösungs-Post:

I recreated all users and set permissions as they were before the crash. Everything is working just fine, again - wether on Windows, Linux or Android. So there was indeed something off with these files or deleting them triggered something else to reset. It's a pity I may never know the real problem, but for now a working system is all that counts. I just hope this won't occur again in the future. Anyway: Thank you very much, again!

The passwd as well as the shadow files contain rows for each of my users. The smbpasswd file on the other hand only contains one row beginning with 'root'. I moved those into another directory and booted the server. As you said I will have to recreate all users, I only did so with the 'test' user so far. But as far as I can see, everything seems to be working with this newly created user I have write acces on 'secure' shares and can access 'private' shares as before the crash! I will do some testing with different users and systems the day after tomorrow (I am quite busy tomorrow). If everything works as expected, I will mark your answer as the solution to my problem (as I don't know wether it would be possible to take it back if problems persist?) Anyway: thank you very much so far for your quick and helpful answers!

I am sorry, I have not expressed myself clearly. The windows machines use a microsoft account for logging into windows, but that account is not used for SMB. The SMB-users (which only consist of lower case letters) have been added via the credentials manager in Windows like stated in your PDF-manual. It worked fine this way for a few months until my server crashed once and I restored the USB-stick.

I created the 'test'-user only for testing purposes after the problem occured. I used this user on three different windows machines after deleting the credentials that were there before. Five of the other users are used on different Windows-machines by me and my family (, too). Two users are only used to connect Linux Machines (Proxmox & a Debian 12 LXC Container). Unfortunately most of the windows machines are bound to a microsoft account, so I had to enter the users via the credentials manager.

The output is shown in the screenshot attached. The first sub-directory was created a few days ago via SMB set to public. I renamed it and created a second one right now via the web-ui of unraid.

Hello everyone, I'm experiencing a recent issue where I can no longer properly access my SMB network shares. I already tried to ask this question at the German forums, but as I wasn't able to find a solution there I am seeking for help here. There is a thread with a very similar problem by @Revan335 but as far as I can see the root cause for his problem seemed to be the folder permissions. Those seem to be set right in my case, so I am opening a new thread. Symptoms: Previously, all shares were set to Private, now no users can access private shares (even if they have permissions) When switching to Secure, I can connect again under Linux (Debian 12) and Android, but only with read permissions (despite write permissions being set for the respective user) Under Windows, I can no longer mount the shares, even when adding the user in the credential manager as a Windows user (deleted all other users). If I disable Windows group policies according to the guide linked in the latest version's changelog, I can connect again but only have read permissions like in Linux. For me it seems like all useres are treated as guests. The missing write permissions apply to both the root directory and subdirectories. Randomly checked shares are all affected, including the newly created "test" share When setting a share to Public, I have write permissions - but I absolutely don't want to keep it that way... When did the problem start? The Unraid server recently crashed for unknown reasons (still powered on but unreachable) and couldn't boot from the USB stick anymore. I then restored a backup (three days old at the time) to a new (unused) USB2 stick, transferred the license, and immediately updated from 6.9.13 to 6.9.14 after starting. That's when I first noticed these symptoms. I'm quite certain the shares were working at the time of the backup. What have I tried? Multiple server and client system restarts Testing with different client machines (Windows 10 Edu, Windows 11 Pro, Android 13, Debian 12) Downgrade to 6.9.13 Restored the backup again, this time without updating Changed the (previously working) SMB settings Accessing via hostname or IP address Deleted all credentials to the server in Windows and ran 'net use * /del' command and set the credentials like mentioned in the guide by @Frank1940 Set server signing = auto in the SMB Extra settings Upgrade to 7.0.0-Beta4 (where I am now) Created three shares for testing purposes as well as a new user 'test'. The symptoms are identical Share 'test' on my array of two HDDs + one parity Disk Share 'test_SSD' on my pool of two SSDs (RAID 1) Share 'Test_Virtual' on a pool of a single virtual disk Notes: I'm using Unraid in Proxmox with the SATA controller passed through via PCIe. This has been working fine for a few months. I don't suspect Proxmox to be the problem in my case, as the problem doesn't stick to the physical discs which would have indicated a problem with PCIe passthrough. I therefore post in the 'General Support' section. If I am doing wrong please move this thread to the correct section. I only installed Nextcloud AIO as Docker container, and these containers don't access the affected shares. There are no VMs inside of Unraid. The old USB3 stick is still untouched. Windows shows filesystem errors but can read the data, so if there is anything on this stick that might help I should be able to retrieve it. Another user in this forum seemed to have similar problems due to their BTRFS filesystem, but I'm using XFS. The fact that public shares are writable would also seem to argue against filesystem errors. To me, it looks like all users are being treated as guests. I greatly appreciate any help or ideas, as I seem to be stuck on my own... Thank you in advance! Output of the ls -la commands (family names covered): SMB Settings: Settings of one of my shares: Array and pools:

In meinem Fall scheint das Problem leider wo anders zu liegen, auch wenn die Symptome identisch waren. Während bei dir die Korrektur der Berechtigungen geholfen hat, scheinen diese bei mir schon korrekt gesetzt... Trotzdem danke! Ich mache dann mal einen neuen Thread auf. Edit: Ich habe hier jetzt einen neuen Thread auf Englisch geöffnet. Sollte sich dort eine Lösung finden lassen, vermerke ich das natürlich auch noch einmal hier.

Den Post hatte ich bislang übersehen, werde ich morgen einmal in Ruhe durchgehen (ist ja recht umfangreich). Danke! Wenn ich daraus keine Lösung für mich finde werde ich je nach Ähnlichkeit des Problems einen neuen Thread eröffnen oder unter dem Thread weiter nachfragen (wenn nicht i.O. gerne Rückmeldung, bin noch recht neu in solchen Foren).

Danke für die Rückmeldung! Das habe ich mir schon fast gedacht (und schon vor dem Post befürchtet - wollte aber direkt mit offenen Karten spielen). Im Englischsprachigen Teil gibt es ja ein Forum "Virtualizing Unraid", dort würde ich anfragen, auch wenn ich eigentlich weniger davon ausgehe dass dort das Problem liegt (daher zuerst die allgemeine Anfrage).

Da ich hier im deutschen Teil des Forums bislang keine Antwort erhalten habe (kein Vorwurf! Ist ja alles freiwillig hier ), würde ich diese Anfrage gerne im englischsprachigen Bereich des Forums neu erstellen, sofern niemand Einwände hat. Falls dies als unerwünschtes Cross-Posting gilt, bitte ich um einen kurzen Hinweis. Dieser Thread könnte dann geschlossen werden, wobei ich für künftige Interessenten einen Verweis auf die englische Version setzen würde

Hallo zusammen, ich habe seit neustem das Problem, dass ich nicht mehr richtig auf meine SMB-Netzwerkshares zugreifen kann. Symptome: - Bislang hatte ich alle Shares auf Privat, nun können keine Nutzer mehr auf private Shares zugreifen (auch wenn sie berechtigt sind) - Stelle ich auf Sicher um, bekomme ich unter Linux (Debian 12) und Android wieder die Verbindung hergestellt, allerdings nur mit Leserechten (obwohl für entsprechenden User Schreibrechte eingestellt) - Unter Windows kann ich die Shares nicht mehr einbinden, auch nicht wenn ich den Nutzer in der Anmeldeinformationsverwaltung als Windows-Nutzer hinzufüge (alle anderen Nutzer habe ich gelöscht). Schalte ich die Gruppenrichtlinien von Windows gem. in Changelog zur neusten Version verlinkten Anleitung ab, kann ich mich zwar wieder verbinden, habe aber wie unter Linux nur Leserechte - Die fehlende Schreibberechtigung gilt sowohl im Root-Verzeichnis als auch in den Unterverzeichnissen. Stichprobenhaft geprüfte Shares sind alle betroffen, auch das neu angelegte Share "test" - Stelle ich einen Share auf Öffentlich, habe ich Schreibrechte - aber das möchte ich unter keinen Umständen so lassen... Seit wann tritt das Problem auf? Der Unraid-Server ist kürzlich aus mir unbekannten Gründen abgestürzt (noch eingeschaltet, aber nicht mehr erreichbar) und konnte vom USB-Stick nicht mehr booten. Ich habe daraufhin eine (zu dem Zeitpunkt drei Tage alte) Sicherung auf einen neuen (unbenutzten) USB2-Stick wieder hergestellt, die Lizenz übertragen und nach dem Start direkt von 6.9.13 auf 6.9.14 geupdated. Danach sind mir die Symptome zum ersten Mal aufgefallen. Ich bin mir ziemlich sicher, dass die Shares zum Zeitpunkt der Sicherung noch funktioniert haben. Was habe ich schon probiert? - Mehrfacher Neustart des Servers sowie der Client-Systeme - Downgrade auf 6.9.13 - Erneutes Wiederherstellen der Sicherung, diesmal kein Update - Änderung der (zuvor funktionierenden) SMB-Einstellungen - Zugriff über Hostname oder IP-Adresse - Befehl 'net use * /del' unter Windows ausgeführt um alle Freigaben zu bereinigen - Upgrade auf 7.0.0-Beta4 (hier bin ich jetzt gerade) Hinweise: - Ich nutze Unraid in Proxmox und habe den SATA-Controller per Pcie-Passthrough durchgereicht. Dies hat nun schon ein paar Monate problemlos funktioniert. - Die Shares befinden sich auf dem Array bestehend aus drei HDDs (XFS; 1x davon Parität) - In den Logs zu Unraid steht nichts Auffälliges (in meinen Augen) - An Docker-Containern habe ich bislang nur Nextcloud AIO installiert und diese Container greifen nicht auf die betroffenen Shares zu - Der alte USB3-Stick liegt noch unangetastet vor. Windows zeigt zwar Dateisystem-Fehler an, kann die Daten aber lesen. Ein anderer Nutzer in diesem Forum schien ähnliche Probleme aufgrund seines BTRFS-Dateisystems zu haben, ich nutze allerdings XFS. Gegen Fehler im Dateisystem würde in meinen Augen auch sprechen, dass öffentliche Shares beschreibbar sind. Für mich sieht es so aus, dass alle Nutzer als Gäste gewertet werden. Ich bedanke mich schon einmal herzlich für jegliche Hilfestellungen oder Ideen, allein scheine ich nicht mehr weiter zu kommen... Konsolenausgaben, die in ähnlichen Threads gewünscht wurden (Nutzernamen/ Namen von Familienmitgliedern durch ANONYMISIERT ersetzt): root@Zima:~# ls -la /mnt total 17 drwxr-xr-x 12 root root 240 Dec 1 03:34 ./ drwxr-xr-x 20 root root 420 Dec 1 03:34 ../ drwxrwxrwt 2 nobody users 40 Dec 1 03:31 addons/ drwxrwxrwx 9 nobody users 146 Dec 1 03:44 disk1/ drwxrwxrwx 6 nobody users 65 Dec 1 03:44 disk2/ drwxrwxrwt 2 nobody users 40 Dec 1 03:31 disks/ drwxrwxrwx 5 nobody users 5 Dec 1 03:44 hotstorage/ drwxrwxrwt 2 nobody users 40 Dec 1 03:31 remotes/ drwxrwxrwt 2 nobody users 40 Dec 1 03:31 rootshare/ drwxrwxrwx 1 nobody users 146 Dec 1 03:44 user/ drwxrwxrwx 1 nobody users 146 Dec 1 03:44 user0/ drwxrwxrwx 1 nobody users 40 Dec 1 03:44 virtual/ root@Zima:~# ls -la /mnt/user total 43 drwxrwxrwx 1 nobody users 146 Dec 1 03:44 ./ drwxr-xr-x 12 root root 240 Dec 1 03:34 ../ drwxrwxrwx 1 nobody users 18 Sep 8 05:57 appdata/ drwxrwxrwx 1 nobody users 0 Jul 20 06:09 domains/ drwxrwxrwx 1 ANONYMISIERT users 45 Oct 22 00:43 ANONYMISIERT/ drwxrwxrwx 1 nobody users 68 Sep 21 10:51 infrastructure/ drwxrwxrwx 1 nobody users 6 Jul 31 00:33 isos/ drwxrwx--- 1 ANONYMISIERT users 4 Sep 21 13:55 ANONYMISIERT/ drwxrwx--- 1 ANONYMISIERT users 27 Sep 22 11:58 ANONYMISIERT/ drwxrwxrwx 1 nobody users 4096 Mar 11 2024 media/ drwxrwx--- 1 sshd users 3 Sep 21 09:47 nextcloud_data/ drwxrwxrwx 1 ANONYMISIERT users 6 Sep 22 13:08 ANONYMISIERT/ drwxrwxrwx 1 nobody users 26 Jul 20 06:09 system/ drwxrwxrwx 1 nobody users 4096 Oct 14 15:31 temp/ drwxrwxrwx 1 nobody users 6 Nov 28 05:41 test/ SMB Einstellungen in Unraid: Einstellungen für ein Share: zima-diagnostics-20241202-0853.zip