tenksomm
-
Posts
34 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by tenksomm
-
-
2 minutes ago, mgutt said:
Falls das so war, dann würde ich auf ein defektes BTRFS Dateisystem tippen.
Ok, dann stelle ich mal auf XFS um
-
Just now, mgutt said:
Wo war denn das docker.img vorher gespeichert? Auf einer disk?
Jap, das habe ich erst vor 1 - 2 Wochen auf den Cache geschoben, da ich es vorher nicht besser wusste, außerdem war das Docker.img beschädigt, also korrupt.
-
10 minutes ago, mgutt said:
Musstest du den Server mal hart abschalten? In so einem Fall soll man immer einen Scrub bei BTRFS Laufwerken machen. XFS ist da deutlich dankbarer. Daher wäre meine Empfehlung XFS.
Ok, werde ich mal ausprobieren
Gehen da Daten verloren?:
10 minutes ago, mgutt said:In so einem Fall soll man immer einen Scrub bei BTRFS Laufwerken machen
-
It already happend befor I moved the docker.img to the cache drive...
Take a look here:
-
-
Es ist eine einzelne SSD
-
Ich habe den Grund gefunden und habe dafür ein neues Topic aufgemacht:
-
Hey,
Ich habe ein Problem mit meinem btrfs filesystem des Caches. Hier sind die Fehlercodes aus dem Syslog, vielleicht könnt ihm damit was anfangen:
Durch das Problem sind alle Shares betroffen, welche die Cache nutzen. da das btrfs system auf "readonly" schaltet, keine Ahnung warum.
Danke schonmal
-
Das Problem ist schon wieder aufgetreten, ich weiß nicht woran es liegt. Diesmal hat er wieder nach ein paar Dateien die Rechte umgeschrieben
-
When you create a new share, you can choose which disk you want to use. In the share-create menu is a section called Included Disks / Excluded Disk. In this way you can manage, on which Disk your share is placed
-
So, da bin ich wieder. Das Problem ist wieder aufgetreten. Es tritt auf, wenn man viele kleine Dateien überträgt (Backup von einem iPhone oder viele Bilder). Hat jemand eine Lösung oder eine Ursache?
Nochmal zum Problem: Das Share sei schreibgeschützt bzw. besitzt der User nicht die nötigen Zugriffsrechte. Wenn man aber nur auf einen Share Daten überträgt, betrifft das dann alle Shares
PS: ein Neustart des Servers hat geholfen
-
Danke dir, ich melde ich wieder, wenn es wieder Probleme gibt und werte gleich von mir aus alles aus. Wenns Probleme gibt, geb ich einfach wieder Bescheid
-
13 minutes ago, mgutt said:
Hast du mal einen Screenshot von der Windows Fehlermeldung zur Hand?
Nein, leider nicht, aber ich denke, der Fehler wird noch einmal auftreten, da mache ich dann einen. Eine andere Frage, ich habe jetzt mein SMB auf Active Directory umgestellt und kann nicht mehr darauf zugreifen, einfach wieder umstellen?
4 hours ago, mgutt said:so lange man in den SMB Einstellung nicht "Ja", sondern "Ja (Active Directory" gewählt hat.
-
Ich möchte noch einmal daran erinnern, dass ich eine Beta nutze, also kann es einfach auch ein Beta - Bug sein. Ich wollte mal den iSCSI Support ausprobieren
-
2 hours ago, mgutt said:
Noch mal zu diesem Problem. Gilt dieser Schreibschutz für den kompletten Share, also auch im obersten Verzeichnis des Shares oder nur in bestimmten Unterordnern?
Das gilt für den ganzen Share, also auch Unterverzeichnisse. Und auch andere Shares sind betroffen, was man weiter oben im thread lesen kann, da auch speedtest-tracker Probleme auf Verzeichnisse zuzugreifen
On 2/3/2021 at 10:05 PM, tenksomm said:/config/www/storage/logs/laravel-2021-02-03.log
2 hours ago, mgutt said:Hast Du Docker Container oder Plugins, die auf diese(n) problematischen Share(s) zugreifen?
Nein, eigentlich nicht, ich habe noch ein iSCSI Plugin, welches aber nur auf den iSCSI Share zugreifen sollte
-
Ach so, habs gefunden, bei mir steht noch Workgroup drin
1 hour ago, mgutt said:so lange man in den SMB Einstellung nicht "Ja", sondern "Ja (Active Directory" gewählt hat.
-
Bei mir sieht es ähnlich aus, nur dass bei meinen Ordnern nobody statt mein Name steht
1 hour ago, mgutt said:so lange man in den SMB Einstellung nicht "Ja", sondern "Ja (Active Directory" gewählt hat.
Welche Einstellung meinst du genau?
-
Nach einem reboot hat es wieder funktioniert, aber muss ich immer einen reboot ausführen, um das Problem zu beheben?
-
Das Problem ist wieder aufgetreten, durch den Befehl
On 2/3/2021 at 10:42 PM, ich777 said:'ls -la /mnt'
habe ich auch bemerkt, das users nur Lese Rechte haben, habe aber schon umgeschrieben auf meinen Share, da kommt das
also auch hier keine Schreibrechte. Kann sich das jemand erklären?
On 2/4/2021 at 12:32 AM, mgutt said:Das sollte es auch fixen.
Hat es leider auch nicht.
-
8 minutes ago, ich777 said:
Welcher Docker Container?
Es wäre Speedest - Tracker gewesen, auf welchen ich aus irgendeinem Grund immer noch nicht zugreifen kann, aber das ist auch egal.
-
Habs hinbekommen, ein reboot hat es getan. Habe mich immer vor einem reboot gescheut, da ich mit diesem schon Probleme hatte. und da ich nicht so leicht an den Server rankomme, um ihn zu warten, habe ich kaum ein reboot gemacht. Danke trotzdem an alle!
-
2
-
-
7 minutes ago, ich777 said:
Darf ich mal fragen was du geändert hast oder wie es überhaupt zu dem problem kam?
Ich weiß es selber nicht, ich habe gestern noch ohne Zwischenfälle Dateien verschoben. aber heute war der Share dann plötzlich schreibgeschützt
-
Ich habe mal "new Permissions" für meinen eigene Share ausgeführt, kann aber immer noch nicht drauf schreiben
-
2 minutes ago, ich777 said:
wo hast du probleme?
Ich glaube beide sind betroffen, da mir ein Dockercontainer sagt "/config/www/storage/logs/laravel-2021-02-03.log" sei Read-only file System
Komische BTRFS Fehler
in Deutsch
Posted · Edited by tenksomm
Danke an alle, es sieht so aus als wäre der Fehler behoben. Mir ist auch eingefallen, dass wir mal einen Stromausfall hatten und da ich keine USV habe, könnte dass das Problem gewesen sein.
Noch ne Frage, wie kann ich hier im Forum auf [SOLVED] schalten, also den Titel bearbeiten?