K
kolvar
Mitglied
[gelöst] iscsi auf read only gesprungen
Und noch ein thread von mir, der ich offensichtlich keine Ahnung von irgendwelchen Serverdingen habe, sie aber trotzdem erledigen muß (jammer)
Problem ist wie folgt: Wir haben einen Server laufen, auf dem ein Verzeichnis für eine iscsi-Verbindung freigegeben ist. läuft sauber, ist auf zwei Servern gemountet, funktioniert 1a mit lesen, schreiben, verändern mounten etc.
Den usern ist es über samba weitergegeben.
plötzlich (sprich heute morgen irgendwann in den frühen Stunden vor Sonnenaufgang) verloren plötzlich alle das Schreibrecht auf diese Verzeichnisse. Sogar auf der Shell kann ich mit root-rechten keine Datei mehr anlegen. Das iscsi läuft, Verzeichnisse sind zu sehen. Server wurde (zum wiederholten Male, d.h. am neustart kann es nicht liegen) daraufhin neu gestartet, schreibrechte sind aber immer noch nicht da.
config dazu sieht wie folgt aus:
auf dem anderen Server, auf dem das ganze ebenfalls eingebunden ist (in einem anderen Netzwerk, über andere Netzwerkkarte mit anderer IP (ok, letzteres war unnötig)) sehen folgende Zeilen anders aus:
(und es gibt einen Benutzernamen und ein Passwort, die aber nicht nötig sind für das System, die ich bei der Testkonfiguration aber aus unkenntnis mit angegeben hatte).
die Frage nun: warum schaltet sich das ab. Wieso gibt es keine Schreibrechte mehr von einem Server aus (vor allem, wenn es einmal unter den gleichen Voraussetzungen) ging.
Das einzige, was ich geändert habe seitdem sind:
zusätzliches Verzeichnis angelegt (und in Samba freigegeben)
webmin von 1.36 auf 1.37 geupdatet
postfix neu gestartet
Danke im Voraus
Noch was aus den Logfiles:
daemon.log
------------------------------------------
wow, ist mir schlecht: dmesg angesehen und mitteilung bekommen, dass EXT3 auf dem Device mal einen filesystem check bräuchte, der leider gescheitert ist.
Nachdem ich den node jedoch gelöscht hatte, neu erstellt und wieder eingebunden ist alles da und in ordnung, bleibt trotzdem die Frage, warum er der Meinung war, sich abhängen zu müssen.
---------------------------
hat sich gerade wieder abgehängt:
dmesg
das lustige ist, dass das ganze, das der andere Server, auf dem das läuft, diesen fehler nicht hat und ganz normal weiterläuft.
-------------------
für alle, die sich nicht die ganze Zeit über meine Dummheit totgelacht haben:
Wenn man ein iscsi-device normal einbindet, führt eine doppeleinbindung auf zwei Systemen unweigerlich zu Datenkorruption, weil zwei Controller versuchen, das System zu kontrollieren.
Und noch ein thread von mir, der ich offensichtlich keine Ahnung von irgendwelchen Serverdingen habe, sie aber trotzdem erledigen muß (jammer)
Problem ist wie folgt: Wir haben einen Server laufen, auf dem ein Verzeichnis für eine iscsi-Verbindung freigegeben ist. läuft sauber, ist auf zwei Servern gemountet, funktioniert 1a mit lesen, schreiben, verändern mounten etc.
Den usern ist es über samba weitergegeben.
plötzlich (sprich heute morgen irgendwann in den frühen Stunden vor Sonnenaufgang) verloren plötzlich alle das Schreibrecht auf diese Verzeichnisse. Sogar auf der Shell kann ich mit root-rechten keine Datei mehr anlegen. Das iscsi läuft, Verzeichnisse sind zu sehen. Server wurde (zum wiederholten Male, d.h. am neustart kann es nicht liegen) daraufhin neu gestartet, schreibrechte sind aber immer noch nicht da.
config dazu sieht wie folgt aus:
Code:
node.name = iqn.2007-09:nrstorage.target1
node.transport_name = tcp
node.tpgt = -1
node.active_conn = 1
node.startup = manual
node.session.initial_cmdsn = 0
node.session.auth.authmethod = None
node.session.timeo.replacement_timeout = 120
node.session.err_timeo.abort_timeout = 10
node.session.err_timeo.reset_timeout = 30
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.session.iscsi.DefaultTime2Retain = 0
node.session.iscsi.DefaultTime2Wait = 0
node.session.iscsi.MaxConnections = 1
node.session.iscsi.MaxOutstandingR2T = 1
node.session.iscsi.ERL = 0
node.conn[0].address = 192.168.5.2
node.conn[0].port = 3260
node.conn[0].startup = automatic
node.conn[0].tcp.window_size = 524288
node.conn[0].tcp.type_of_service = 0
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.auth_timeout = 45
node.conn[0].timeo.active_timeout = 5
node.conn[0].timeo.idle_timeout = 60
node.conn[0].timeo.ping_timeout = 5
node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0
node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072
node.conn[0].iscsi.HeaderDigest = None,CRC32C
node.conn[0].iscsi.DataDigest = None
node.conn[0].iscsi.IFMarker = No
node.conn[0].iscsi.OFMarker = Noauf dem anderen Server, auf dem das ganze ebenfalls eingebunden ist (in einem anderen Netzwerk, über andere Netzwerkkarte mit anderer IP (ok, letzteres war unnötig)) sehen folgende Zeilen anders aus:
Code:
...
node.tpgt = 1
...
node.conn[0].address = 192.168.2.5
...
node.conn[0].iscsi.MaxRecvDataSegmentLength = 65536
node.conn[0].iscsi.HeaderDigest = Nonedie Frage nun: warum schaltet sich das ab. Wieso gibt es keine Schreibrechte mehr von einem Server aus (vor allem, wenn es einmal unter den gleichen Voraussetzungen) ging.
Das einzige, was ich geändert habe seitdem sind:
zusätzliches Verzeichnis angelegt (und in Samba freigegeben)
webmin von 1.36 auf 1.37 geupdatet
postfix neu gestartet
Danke im Voraus
Noch was aus den Logfiles:
daemon.log
Code:
Sep 26 09:44:48 server iscsid: iSCSI logger with pid=2302 started!
Sep 26 09:44:48 server /etc/mysql/debian-start[2310]: Checking for crashed MySQL tables.
Sep 26 09:44:49 server iscsid: transport class version 1.1-646. iscsid version 2.0-730
Sep 26 09:44:49 server iscsid: an InitiatorAlias= is required, but was not found in /etc/initiatorname.iscsi
Sep 26 09:44:49 server iscsid: iSCSI sync pid=2304 started
Sep 26 09:44:49 server iscsid: iSCSI daemon with pid=2303 started!
Sep 26 09:44:49 server iscsid: connection0:0 is operational now------------------------------------------
wow, ist mir schlecht: dmesg angesehen und mitteilung bekommen, dass EXT3 auf dem Device mal einen filesystem check bräuchte, der leider gescheitert ist.
Nachdem ich den node jedoch gelöscht hatte, neu erstellt und wieder eingebunden ist alles da und in ordnung, bleibt trotzdem die Frage, warum er der Meinung war, sich abhängen zu müssen.
---------------------------
hat sich gerade wieder abgehängt:
dmesg
Code:
EXT3-fs: mounted filesystem with ordered data mode.
eth1: no IPv6 routers present
EXT3-fs error (device sdb1): htree_dirblock_to_tree: bad entry in directory #42074113: directory entry across blocks - offset=0, inode=168647977, rec_len=10300, name_len=52
Aborting journal on device sdb1.
ext3_abort called.
EXT3-fs error (device sdb1): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-onlydas lustige ist, dass das ganze, das der andere Server, auf dem das läuft, diesen fehler nicht hat und ganz normal weiterläuft.
-------------------
für alle, die sich nicht die ganze Zeit über meine Dummheit totgelacht haben:
Wenn man ein iscsi-device normal einbindet, führt eine doppeleinbindung auf zwei Systemen unweigerlich zu Datenkorruption, weil zwei Controller versuchen, das System zu kontrollieren.
Zuletzt bearbeitet:
