susa
-
Posts
13 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by susa
-
-
1 hour ago, mgutt said:
Nun dann bist du in der selben Situation wie zuvor als du uid=1000,gid=1004 verwendet hast.
Ich denke dein Problem ist die umask und nicht die UID oder CHMOD. Soll heißen deine Maschine nutzt beim Mount nicht die selbe umask wie Unraid und erstellt daher mit "falschen" Dateirechten die Dateien. Oder welches System hatte die erstellt, die du nachher nicht mehr ändern kannst?
Ok, ich bin also wieder auf Los 🙂
Habe das mit den Rechten wohl noch nicht ganz durchdrungen.
Mit umask klingt erstmal plausibel, habe daran aber noch nichts verändert/benutzt. Die Eingabe von umask auf dem Client bringt 0002.
Per SSH auf dem unraid bringt 0000 (ist dann aber als root, bringt vermutlich nichts? )
Die Daten wurden mit dem Client-System erstellt, ja. Das Problem war aber nicht, dass ich die Datei nicht mehr ändern kann, sondern vielmehr war der Ganze Sharepoint weg, immer direkt nach Kopier oder Löschvorgängen (sporadisch). Der Krusader oder Dolphin reagieren dann nicht mehr und brechen irgendwann ab (auf dem Client). Der Zugriff ist dann nicht mehr möglich und die der Mountpunkt ist dann grau dargestellt.
Demnach müsste ich auf dem Client-System die umask ändern?
-
36 minutes ago, mgutt said:
Bitte auf deinem Rechner eingeben:
id nobody
getent group users
id nobody
uid=65534(nobody) gid=65534(nogroup) Gruppen=65534(nogroup) -
11 hours ago, mgutt said:
Das hier könnte ein Problem sein. Welche ID hat users in der VM?
ID des Clients: uid=1000(susa) gid=1004(susa) Gruppen=1004(susa)
(virtuelle maschine habe ich nicht im Einsatz, ist ein normaler Rechner)
-
hier scheint ein ähnliches Problem vor zu liegen:
Ich habe den Tip von mgutt ausprobiert und hatte zumindest 4 Stunden den Eindruck, dass alles normal funktioniert, bis dann ein Laufwerk wieder weg war, schade.
Testreihenfolge:
1. ursprünglicher Eintrag in fstab
//192.168.178.23/Projekte /media/unraid/Projekte cifs uid=1000,gid=1004,iocharset=utf8,nounix,_netdev,noauto,credentials=/etc/.winshare-pw 0 0
->Laufwerke fallen sporadisch aus2. Empfehlung: ohne uid=1000,gid=1004
//192.168.178.23/Projekte /media/unraid/Projekte cifs noauto,credentials=/etc/.winshare-pw 0 0
->Ohne Rechtevergabe werden die Laufwerke stabil eingebunden aber die Ordner erhalten die Rechte 755, sind dann nur für den Root schreibbar, vermutlich, da die fstab immer als root ausgeführt wird... ?
3. Variante mit unraid Nutzer/Grupen id`s
//192.168.178.23/Projekte /media/unraid/Projekte cifs uid=99,gid=100,noauto,credentials=/etc/.winshare-pw 0 0
->gleiches Verhalten wie (2.)
4. file_mode bzw. dir_mode setzen
//192.168.178.23/Austauschlaufwerk /media/unraid/Austauschlaufwerk cifs credentials=/etc/.winshare-pw,noauto,nofail,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0
->gleiches Verhalten wie unter (1.)5. uid=nobody,noperm,gid=users
//192.168.178.23/Projekte /media/unraid/Projekte cifs uid=nobody,noauto,iocharset=utf8,noperm,gid=users,credentials=/etc/.winshare-pw 0 0
->bisher bestes Verhalten
->aktuell warte ich auf Netzlaufwerk Ausfall 😁
->ich beobachte weiter und poste die syslog wenn es wieder ausfällt
Fazit: Die Nutzerrechte müssen zum unRAID passen, hier werde ich mich noch etwas einarbeiten müssen 😉, dennoch merkwürdig, dass bei Nutzung von uid=1000,gid=1004, das Ganze auch funktioniert aber nicht lange. Ich bin ja eigentlich eher der Fan von "geht" oder "geht nicht".
Zumindest konnte ich wieder viel lernen, danke dafür.
Besonderer Dank an mgutt und hawihoney, für Ihre Mühe!
Eure Hinweise haben mich echt weiter gebracht 🙂
-
Ja, vermutlich liegt hier das Problem.
Erstellt habe ich die Mountpunkte unter /media/unraid als root, somit haben sie 755.
Ich konnte als user dort keine Dateien erstellen.
(Sicht auf den client)
Ich habe dann chmod 666 gesetzt, im ausgehängten Zustand.
Nun das Austauschlaufwerk wieder einbinden:
sudo mount /media/unraid/Austauschlaufwerk
und schwub, sind die Schreibrechte wieder weg.
Zum test habe ich unter dem home Verzeichnis des users ein Verzeichnis erstellt mit Schreibrechten. wenn diese dann aber gemountet werden sind sie wieder weg.
-
Ja, das darf er Read/Write. Oder gibt es noch an anderer Stelle etwas zu bedaten? Auf der rechten Seite gibt es noch dieses Feld:
das habe ich bisher ignoriert.
-
ls -la liefert folgende Ergebnisse:
Ordner
Dateien
Schaut für mich rechtemässig ok aus... 🤔
Unter der share Verwaltung:
-
Quote
Hallo mgutt,
viele gute Hinweise 🙂
Ich habe nun die fstab angepasst unter Weglassung der user id bzw. gruppen id.
//192.168.178.23/Projekte /media/unraid/Projekte cifs ,noauto,credentials=/etc/.winshare-pw 0 0
->Im Ergebnis: zügiges Einbinden, scheint stabil zu laufen, Aber keine Schreibrechte mehr 🤔
Testweise mal mit den unraid Werten 99:100
//192.168.178.23/Projekte /media/unraid/Projekte cifs uid=99,gid=100,noauto,credentials=/etc/.winshare-pw 0 0
->Im Ergebnis: dito
-
Nein ist kein Mac, es handelt sich um einen Lenovo P50 PC mit Ubuntu 22.04 aus der Distribution von Tuxedo.
Der Hinweis mit den Rechten unter Unraid scheint mir sehr hilfreich zu sein, vielleicht gibt es hier den Konflikt... . 1000:1004 ist quasi die User id und die Gruppen id, ich habe mich da gehalten an das Buch von Michael Koffler:
https://www.rheinwerk-verlag.de/linux-das-umfassende-handbuch/ (Seite 1518)
Teilweise wird im Netz auch folgender Eintrag in der fstab genutzt:
#//192.168.178.23/Projekte /media/unraid/Projekte cifs credentials=/etc/.winshare-pw,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0
Quasi sowohl Datei als auch Ordner Rechte auf maximal. Getestet habe ich auch dies, leider mit dem selben Verhalten.Beim Thema Log Dateien habe ich noch vermehrt Fragezeichen um mich herum, da ich so recht keine finde.
Unter /var/log/ liegen nur ein paar ältere Sachen und die /var/log/syslog finde ich gar nicht. Bin ich vielleicht im falschen Ordner?
In meinem ersten Post hab ich diesen kompletten Log angehängt, dort findet sich die syslog datei (2 mb) syslog.txt
(wurde von unraid automatisch erzeugt, nachdem das log zu 98% gefüllt war)
RPC fault code DCERPC_NCA_S_OP_RNG_ERROR received from host unraid!
smb2_server.c:3955(smbd_smb2_request_error_ex)
idx[1] status[NT_STATUS_BAD_NETWORK_NAME]
smb2_server.c:3955(smbd_smb2_request_error_ex
idx[1] status[NT_STATUS_BAD_NETWORK_NAME
...
die tauchen vermehrt auf und scheinen mit den Ausfallzeiten zu korrelieren, leider kann ich sie nicht deuten.
-
Hallo @Asgard,
kannst Du mir Deinen Workaround mit dem umbenennen kurz schildern? Wenn ich versuche den Ordner umzubenennen bekomme ich "ist nicht vorhanden".
Mein Workaround schaut momentan so aus:
sudo umount -f /media/unraid/Projekte
sudo mount /media/unraid/Projekte
In Summe schaut der Morgen bei mir so aus:
8:00 Datei erstellen
8:10 speichern auf Unraid SMB share unter Projekte
8:20 Datei überarbeitet
8:30 Netzlaufwerk weg
8:35 umount -f /media/unraid/Projekte
8:36 mount /media/unraid/Projekte
8:36 Netzlaufwerk wieder da
8:37 das Leben hat wieder einen Sinn 🙂
Was mich wundert, wenn ich den Unraid Server neu starte sind auf dem Linux PC alle Share Points von alleine wieder da, quasi so wie man es erwarten würde ohne erneutes mounten.
-
Hallo hawihoney,
das Wissen über die Unraid Spezifika ist bei mir noch im Aufbau 😉, ich hoffe, dass ich von Euren Erfahrungen profitieren kann.
192.168.178.23 ist der Unraid Server. Der Pfad /media/unraid ist der Ort an dem der Unraid Sharepoint eingehängt wird innerhalb des clients.
Der Aufbau schaut etwa so aus:
-
Hallo zusammen,
ich bin neu bei unraid und hoffe Ihr habt einen Tip, wie ich den Fehler beheben kann.
Das Problem taucht sporadisch auf oder wenn im Anschluß eines Kopiervorgangs die Zieldatei gelöscht oder bewegt wird, dies dauert erst recht lange und dann verschwindet der SMB-Share Point, die anderen bleiben aktiv.
Einbindung in /etc/fstab:
//192.168.178.23/Syncordner /media/unraid/Syncordner cifs uid=1000,gid=1004,iocharset=utf8,nounix,_netdev,noauto,credentials=/etc/.winshar>
//192.168.178.23/Projekte /media/unraid/Projekte cifs uid=1000,gid=1004,iocharset=utf8,nounix,_netdev,noauto,credentials=/etc/.winshare-pw>
//192.168.178.23/Multimedia /media/unraid/Multimedia cifs uid=1000,gid=1004,iocharset=utf8,nounix,_netdev,noauto,credentials=/etc/.winshar>
//192.168.178.23/Downloads /media/unraid/Downloads cifs uid=1000,gid=1004,iocharset=utf8,nounix,_netdev,noauto,credentials=/etc/.winshare->
//192.168.178.23/Backups /media/unraid/Backups cifs uid=1000,gid=1004,iocharset=utf8,nounix,_netdev,noauto,credentials=/etc/.winshare-pw 0>
//192.168.178.23/Austauschlaufwerk /media/unraid/Austauschlaufwerk cifs uid=1000,gid=1004,iocharset=utf8,nounix,_netdev,noauto,credentials>
Gemountet wird dann später wenn das Netz sicher da ist von Hand:mount /media/unraid/Syncordner
mount /media/unraid/Austauschlaufwerk
mount /media/unraid/Backups
mount /media/unraid/Downloads
mount /media/unraid/Multimedia
mount /media/unraid/Projekte
Dann habe ich heute das logging für SMB aktiviert:
log level = 3 logging = syslog
nach:
Nun habe ich die Fehlermeldung, dass die Log´s vollaufen.
/var/log is getting full (currently 98 % used)
Hat sicher etwas zu tun mit (log level = 3 logging = syslog) ... ?
Einige Error Meldungen gibt es:
11:29:45 unraid smbd[2190]: smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_BAD_NETWORK_NAME] || at ../../source3/smbd/smb2_tcon.c:151
Häufig taucht dieser status[NT_STATUS_BAD_NETWORK_NAME] auf ...,
wo könnte das Problem liegen?
Schon mal vielen Dank für die Mühe!
-
1
-
SMB Verbindung geht verloren, oft nach einem Löschvorgang
in Deutsch
Posted
Der Parameter "noserverino" soll helfen...
Meine /etc/fstab schaut nun so aus:
//192.168.178.23/Projekte /media/unraid/Projekte cifs noserverino,nounix,gid=users,noauto,iocharset=utf8,noperm,uid=nobody,gid=users,credentials=/etc/.winshare-pw 0 0
Bisher 1 Tag ohne Abbrüche, bin gespannt was die Zeit bringt.
Eine Erhöhung der Prozessorlast (20% idle), konnte ich nicht feststellen.