Discussion:
kann leeres Verzeichnis nicht entfernen
(zu alt für eine Antwort)
Wolfgang Klein
2012-10-27 14:23:29 UTC
Permalink
Hallo!

Eine Freigabe auf einer NAS ist als CIFS (Samba) eingehangen. Ein
Verzeichnis darauf lässt sich nicht löschen, auch nicht als root:


# du -sh delete-me/
0 delete-me/

# ls -ralF delete-me/
total 0
drwxr-xr-x 1 root root 0 2012-10-27 15:56 ../
drwxr-xr-x 1 root root 0 2012-07-01 00:35 ./

# rm delete-me/*
rm: cannot remove `delete-me/*': No such file or directory

# rm -rf delete-me/
rm: cannot remove directory `delete-me': Directory not empty


Wie kann das Verzeichnis zugleich keine Dateien enthalten und nicht leer
sein?

Die Log-Dateien zeigen keine Auffälligkeiten, weder SMART noch das
RAID-Log auf der NAS selber.

Wie kriege ich das Verzeichnis gelöscht?

Da die NAS in produktiver Umgebung benutzt wird, und außerdem zu weit
entfernt steht, um "mal eben" hinzufahren, fallen Lösungen wie das
Anklemmen an einen anderen Rechner aus!
--
Wolfgang Klein
Tim Ritberg
2012-10-27 14:57:43 UTC
Permalink
Post by Wolfgang Klein
Hallo!
Eine Freigabe auf einer NAS ist als CIFS (Samba) eingehangen. Ein
# du -sh delete-me/
0 delete-me/
# ls -ralF delete-me/
total 0
drwxr-xr-x 1 root root 0 2012-10-27 15:56 ../
drwxr-xr-x 1 root root 0 2012-07-01 00:35 ./
# rm delete-me/*
rm: cannot remove `delete-me/*': No such file or directory
# rm -rf delete-me/
rm: cannot remove directory `delete-me': Directory not empty
Wie kann das Verzeichnis zugleich keine Dateien enthalten und nicht leer
sein?
Die Log-Dateien zeigen keine Auffälligkeiten, weder SMART noch das
RAID-Log auf der NAS selber.
Wie kriege ich das Verzeichnis gelöscht?
Da die NAS in produktiver Umgebung benutzt wird, und außerdem zu weit
entfernt steht, um "mal eben" hinzufahren, fallen Lösungen wie das
Anklemmen an einen anderen Rechner aus!
man lsof

Normalerweise kann man unter Linux den Prozessen die Ressourcen unterm
Arsch wegziehen, anders als bei Windows.
Trotzdem scheint ihr noch was zu blockieren.
Wolfgang Klein
2012-10-27 15:38:09 UTC
Permalink
Post by Tim Ritberg
man lsof
Normalerweise kann man unter Linux den Prozessen die Ressourcen unterm
Arsch wegziehen, anders als bei Windows.
Trotzdem scheint ihr noch was zu blockieren.
Ich sollte noch dazu sagen, daß das betreffende Verzeichnis schon Monate
alt ist und sowohl der Rechner als auch die NAS inzwischen einige male
neu gestartet wurden. Auf dem Rechner läuft also kein Prozess mehr, der
auf das Verzeichnis zugreift.

Es könnte sich also um einen Fehler im Dateisystem auf der NAS handeln.
Allerdings hätte ich erwartet, daß auf einem RAID 6 und einem
Dateisystem mit Journal eine solche Datenkorruption eben nicht passiert.
--
Wolfgang Klein
Tim Ritberg
2012-10-27 15:57:52 UTC
Permalink
Post by Wolfgang Klein
Ich sollte noch dazu sagen, daß das betreffende Verzeichnis schon Monate
alt ist und sowohl der Rechner als auch die NAS inzwischen einige male
neu gestartet wurden. Auf dem Rechner läuft also kein Prozess mehr, der
auf das Verzeichnis zugreift.
Es könnte sich also um einen Fehler im Dateisystem auf der NAS handeln.
Allerdings hätte ich erwartet, daß auf einem RAID 6 und einem
Dateisystem mit Journal eine solche Datenkorruption eben nicht passiert.
dann mach fsck.
Thomas 'PointedEars' Lahn
2012-10-27 16:31:20 UTC
Permalink
Post by Wolfgang Klein
Ich sollte noch dazu sagen, daß das betreffende Verzeichnis schon Monate
alt ist und sowohl der Rechner als auch die NAS inzwischen einige male
neu gestartet wurden. Auf dem Rechner läuft also kein Prozess mehr, der
auf das Verzeichnis zugreift.
Es könnte sich also um einen Fehler im Dateisystem auf der NAS handeln.
Allerdings hätte ich erwartet, daß auf einem RAID 6 und einem
Dateisystem mit Journal eine solche Datenkorruption eben nicht passiert.
Es wäre hilfreich, wenn Du keine Pseudodaten posten würdest.
--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Wolfgang Klein
2012-10-27 17:17:59 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Es wäre hilfreich, wenn Du keine Pseudodaten posten würdest.
Das Verzeichnis, um das es geht, heißt wirklich "delete-me", denn ich
habe es so umbenannt. Das Verzeichnis kann beliebig umbenannt, aber
nicht gelöscht werden.
--
Wolfgang Klein
Tim Ritberg
2012-10-27 17:29:28 UTC
Permalink
Post by Wolfgang Klein
Post by Thomas 'PointedEars' Lahn
Es wäre hilfreich, wenn Du keine Pseudodaten posten würdest.
Das Verzeichnis, um das es geht, heißt wirklich "delete-me", denn ich
habe es so umbenannt. Das Verzeichnis kann beliebig umbenannt, aber
nicht gelöscht werden.
dann mv delete-me /dev/null
Wolfgang Klein
2012-10-27 17:40:03 UTC
Permalink
Post by Tim Ritberg
dann mv delete-me /dev/null
Keine schlechte Idee, aber:

# mv delete-me /dev/null
mv: cannot overwrite non-directory `/dev/null' with directory `delete-me'
--
Wolfgang Klein
Tim Ritberg
2012-10-27 18:07:33 UTC
Permalink
Post by Wolfgang Klein
Post by Tim Ritberg
dann mv delete-me /dev/null
# mv delete-me /dev/null
mv: cannot overwrite non-directory `/dev/null' with directory `delete-me'
mv delete-me /dev/null/bla
Ulf Volmer
2012-10-27 18:18:04 UTC
Permalink
Post by Tim Ritberg
Post by Wolfgang Klein
Post by Tim Ritberg
dann mv delete-me /dev/null
# mv delete-me /dev/null
mv: cannot overwrite non-directory `/dev/null' with directory `delete-me'
mv delete-me /dev/null/bla
Würdest Du Deine Tipps bitte in Zukunft vorher bitte auf Funktion prüfen?
Danke.

Davon abgesehen verhält sich mv unterschiedlich jenachdem ob es innerhalb
eines Filesystems oder außerhalb aufgerufen wird. Im letzteren Fall macht
es intern ein cp gefolgt von einem unlink, womit dem OP vermutlich nicht
geholfen ist.

Gruß,
Ulf.
Tim Ritberg
2012-10-27 18:35:35 UTC
Permalink
Post by Ulf Volmer
Würdest Du Deine Tipps bitte in Zukunft vorher bitte auf Funktion prüfen?
Danke.
Vielleicht sollte man dich besser nach /dev/null verschieben...
Ulf Volmer
2012-10-27 18:41:45 UTC
Permalink
Post by Tim Ritberg
Post by Ulf Volmer
Würdest Du Deine Tipps bitte in Zukunft vorher bitte auf Funktion prüfen?
Danke.
Vielleicht sollte man dich besser nach /dev/null verschieben...
Wenn Du das beherschen würdest...
Josef Moellers
2012-10-28 08:39:54 UTC
Permalink
Post by Ulf Volmer
Post by Tim Ritberg
Post by Ulf Volmer
Würdest Du Deine Tipps bitte in Zukunft vorher bitte auf Funktion prüfen?
Danke.
Vielleicht sollte man dich besser nach /dev/null verschieben...
Wenn Du das beherschen würdest...
??? Hast Du das denn tatsächlich mal probiert?

Ich hab das getan:

***@firebook:~$ mv delete-me/ /dev/null/bla
mv: accessing `/dev/null/bla': Not a directory

Ergo: Dein "Tip" ist keiner, weil er nicht funktioniert.
Ulf Volmer
2012-10-28 10:53:08 UTC
Permalink
Post by Josef Moellers
Post by Ulf Volmer
Post by Tim Ritberg
Post by Ulf Volmer
Würdest Du Deine Tipps bitte in Zukunft vorher bitte auf Funktion prüfen?
Danke.
Vielleicht sollte man dich besser nach /dev/null verschieben...
Wenn Du das beherschen würdest...
??? Hast Du das denn tatsächlich mal probiert?
mv: accessing `/dev/null/bla': Not a directory
Ergo: Dein "Tip" ist keiner, weil er nicht funktioniert.
Wolltest Du das nicht eher Tim schreiben?

Gruß,
Ulf.
Josef Moellers
2012-10-28 19:07:27 UTC
Permalink
Post by Ulf Volmer
Post by Josef Moellers
Post by Ulf Volmer
Post by Tim Ritberg
Post by Ulf Volmer
Würdest Du Deine Tipps bitte in Zukunft vorher bitte auf Funktion prüfen?
Danke.
Vielleicht sollte man dich besser nach /dev/null verschieben...
Wenn Du das beherschen würdest...
??? Hast Du das denn tatsächlich mal probiert?
mv: accessing `/dev/null/bla': Not a directory
Ergo: Dein "Tip" ist keiner, weil er nicht funktioniert.
Wolltest Du das nicht eher Tim schreiben?
Ja, ich hab' mich da wohl verclickt.

Entschuldigung.

Josef
Florian Diesch
2012-10-27 17:55:05 UTC
Permalink
Am Sat, 27 Oct 2012 19:29:28 +0200
Post by Tim Ritberg
Post by Wolfgang Klein
Post by Thomas 'PointedEars' Lahn
Es wäre hilfreich, wenn Du keine Pseudodaten posten würdest.
Das Verzeichnis, um das es geht, heißt wirklich "delete-me", denn
ich habe es so umbenannt. Das Verzeichnis kann beliebig umbenannt,
aber nicht gelöscht werden.
dann mv delete-me /dev/null
Nein, du willst /dev/null nicht wirklich durch ein Verzeichnis
ersetzen.
--
Plugin for Nautilus to create and modify application
starters (.desktop files):
<http://www.florian-diesch.de/software/arronax/>
Thomas 'PointedEars' Lahn
2012-10-28 12:05:15 UTC
Permalink
^^^^^^^^
Post by Tim Ritberg
Post by Wolfgang Klein
Post by Thomas 'PointedEars' Lahn
Es wäre hilfreich, wenn Du keine Pseudodaten posten würdest.
Das Verzeichnis, um das es geht, heißt wirklich "delete-me", denn ich
habe es so umbenannt. Das Verzeichnis kann beliebig umbenannt, aber
nicht gelöscht werden.
dann mv delete-me /dev/null
Der Vorschlag ist doch Unfug. Warum schreibst du etwas, was ueberhaupt
nicht funktionieren kann?
Ich hab' den wesentlichen Teil mal für Dich untergestrichelt.

HTH
--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Oliver Sch@d
2012-10-28 12:33:30 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
^^^^^^^^
Post by Tim Ritberg
Post by Wolfgang Klein
Post by Thomas 'PointedEars' Lahn
Es wäre hilfreich, wenn Du keine Pseudodaten posten würdest.
Das Verzeichnis, um das es geht, heißt wirklich "delete-me", denn
ich habe es so umbenannt. Das Verzeichnis kann beliebig umbenannt,
aber nicht gelöscht werden.
dann mv delete-me /dev/null
Der Vorschlag ist doch Unfug. Warum schreibst du etwas, was
ueberhaupt nicht funktionieren kann?
Ich hab' den wesentlichen Teil mal für Dich untergestrichelt.
Unterstellst du Böswilligkeit?

mfg
Oli
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
Thomas 'PointedEars' Lahn
2012-10-28 16:41:49 UTC
Permalink
Oliver ***@d wrote:
^^^^^
Bitte reparieren.
Post by Oliver ***@d
Post by Thomas 'PointedEars' Lahn
Post by Tim Ritberg
Post by Wolfgang Klein
Post by Thomas 'PointedEars' Lahn
Es wäre hilfreich, wenn Du keine Pseudodaten posten würdest.
Das Verzeichnis, um das es geht, heißt wirklich "delete-me", denn
ich habe es so umbenannt. Das Verzeichnis kann beliebig umbenannt,
aber nicht gelöscht werden.
dann mv delete-me /dev/null
Der Vorschlag ist doch Unfug. Warum schreibst du etwas, was
ueberhaupt nicht funktionieren kann?
Ich hab' den wesentlichen Teil mal für Dich untergestrichelt.
Unterstellst du Böswilligkeit?
Nun, die Reaktionen dieses Posters – soweit ich sie in Zitaten lesen kann –
lassen diese Annahme zu.

Unabhängig davon aber wird meiner Erfahrung nach von Adressverweigerern
(ebenso wie von Realnamenverweigerern, wobei es da Überschneidungen gibt)
grösstenteils Unfug gepostet – sei es nun aus Unwissenheit oder anderen
Gründen –, daher habe ich diese seit geraumer Zeit im Score- bzw. Killfile.

F'up2 de.soc.usenet
--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Helmut Hullen
2012-10-29 08:45:00 UTC
Permalink
Hallo, Thomas,
Post by Thomas 'PointedEars' Lahn
^^^^^
Bitte reparieren.
Suchst Du eine neue Nebenbeschäftigung?

http://de.wikipedia.org/wiki/Horst-Werner_Nilges

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Oliver Sch@d
2012-10-29 12:33:47 UTC
Permalink
Fup ignoriert, da mir das Gruppenklima wichtig ist.
Post by Thomas 'PointedEars' Lahn
^^^^^
Bitte reparieren.
Post by Oliver ***@d
Post by Thomas 'PointedEars' Lahn
Post by Tim Ritberg
Post by Wolfgang Klein
Post by Thomas 'PointedEars' Lahn
Es wäre hilfreich, wenn Du keine Pseudodaten posten würdest.
Das Verzeichnis, um das es geht, heißt wirklich "delete-me", denn
ich habe es so umbenannt. Das Verzeichnis kann beliebig
umbenannt, aber nicht gelöscht werden.
dann mv delete-me /dev/null
Der Vorschlag ist doch Unfug. Warum schreibst du etwas, was
ueberhaupt nicht funktionieren kann?
Ich hab' den wesentlichen Teil mal für Dich untergestrichelt.
Unterstellst du Böswilligkeit?
Nun, die Reaktionen dieses Posters – soweit ich sie in Zitaten lesen
kann – lassen diese Annahme zu.
Kann ich nicht bestätigen, Tim ist schon länger dabei und scheint mir
hilfsbereit zu sein und auch nicht zu trollen. Ich wäre eigentlich
dankbar, wenn man sich erst die Mühe machen würde etwas über gewisse
Teilnehmer in Erfahrung zu bringen, bevor man Böswilligkeit unterstellt.

Das ist für das Gruppenklima nicht unbedingt zuträglich.
Post by Thomas 'PointedEars' Lahn
Unabhängig davon aber wird meiner Erfahrung nach von
Adressverweigerern (ebenso wie von Realnamenverweigerern, wobei es da
Überschneidungen gibt) grösstenteils Unfug gepostet – sei es nun aus
Unwissenheit oder anderen Gründen –, daher habe ich diese seit
geraumer Zeit im Score- bzw. Killfile.
Das stimmt im deutschen Usenet schon, aber auch da gilt, dass
Vorverurteilungen nicht angebracht sind.

Ich z.B. möchte nicht, dass jeder Depp meine Postings schon in der
Standard-Google-Suche finden kann. Nicht, weil ich mich für meine
Postings schäme, ganz im Gegenteil - ich schäme mich auch nicht für Sex
mit meiner Frau, wohl aber mache ich nicht Sex an der Supermarktkasse -
die Nachbarn hören es vermutlich aber trotzdem. Nein, ich will diese
nicht fragen.

Und da ich auch schon rund 10 Jahre mitschreibe, kann man denke ich
recht gut sehen, was ich verbrochen habe oder nicht. Jeder möge sich da
seine eigene Meinung bilden.

Aus meiner Sicht sind die Zeiten vorbei, wo Usenet eine gewisse
Privatheit hatte, sprich Arbeitskollegen, Personaler, Chefs, Abmahner
und Co wg. Nicht-Wissens nicht mitlasen. Es ist halt alles voll
indiziert heute und per Web zugreifbar und das auch noch in 100 Jahren
vermutlich. Die sozialen Zusammenhänge - wer redet mit wem, wer schreibt
wann usw. lassen sich sehr gut erkennen. Im Prinzip hat Usenet heute
Facebook-Charakter. Deine Usenet-Freunde erkennt man an den References,
die du verschickst.

Ich halte deine Sicht auf die Dinge für zu verengt, weil sie diese von
mir genannten Aspekte nicht berücksichtigen. Vor 10 Jahren habe ich das
selbst auch noch anders gesehen.

Datenschutz ist ein hohes Gut und ich finde es schon etwas stark von
Leuten zu verlangen auf Datenschutz zu verzichten, weil sie
mitdiskutieren wollen. Übrigens gab es auch schon solange ich im dt.
Usenet dabei bin die Sicht, dass Privatheit wichtig ist. So wurde immer
wieder angebracht von zahlreichen Postern, dass im Falle eines Schadens
für den Poster, ein anonymes Posting vollkommen in Ordnung ist.

Heute muss ich leider attestieren, dass praktisch jede Form von
Öffentlichkeit, auch immer einen schädlichen Aspekt hat, da die Technik
zu weit fortgeschritten ist. Data-Mining ist kein Hobby mehr
irgendwelcher Nerds zuhause im Keller.

Fup ignoriert, da mir das Gruppenklima wichtig ist.

mfg
Oli
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
Oliver Sch@d
2012-10-29 12:35:27 UTC
Permalink
Fup ignoriert, da mir das Gruppenklima wichtig ist.
Post by Thomas 'PointedEars' Lahn
^^^^^
Bitte reparieren.
Post by Oliver ***@d
Post by Thomas 'PointedEars' Lahn
Post by Tim Ritberg
Post by Wolfgang Klein
Post by Thomas 'PointedEars' Lahn
Es wäre hilfreich, wenn Du keine Pseudodaten posten würdest.
Das Verzeichnis, um das es geht, heißt wirklich "delete-me", denn
ich habe es so umbenannt. Das Verzeichnis kann beliebig
umbenannt, aber nicht gelöscht werden.
dann mv delete-me /dev/null
Der Vorschlag ist doch Unfug. Warum schreibst du etwas, was
ueberhaupt nicht funktionieren kann?
Ich hab' den wesentlichen Teil mal für Dich untergestrichelt.
Unterstellst du Böswilligkeit?
Nun, die Reaktionen dieses Posters – soweit ich sie in Zitaten lesen
kann – lassen diese Annahme zu.
Kann ich nicht bestätigen, Tim ist schon länger dabei und scheint mir
hilfsbereit zu sein und auch nicht zu trollen. Ich wäre eigentlich
dankbar, wenn man sich erst die Mühe machen würde etwas über gewisse
Teilnehmer in Erfahrung zu bringen, bevor man Böswilligkeit unterstellt.

Das ist für das Gruppenklima nicht unbedingt zuträglich.
Post by Thomas 'PointedEars' Lahn
Unabhängig davon aber wird meiner Erfahrung nach von
Adressverweigerern (ebenso wie von Realnamenverweigerern, wobei es da
Überschneidungen gibt) grösstenteils Unfug gepostet – sei es nun aus
Unwissenheit oder anderen Gründen –, daher habe ich diese seit
geraumer Zeit im Score- bzw. Killfile.
Das stimmt im deutschen Usenet schon, aber auch da gilt, dass
Vorverurteilungen nicht angebracht sind.

Ich z.B. möchte nicht, dass jeder Depp meine Postings schon in der
Standard-Google-Suche finden kann. Nicht, weil ich mich für meine
Postings schäme, ganz im Gegenteil - ich schäme mich auch nicht für Sex
mit meiner Frau, wohl aber mache ich nicht Sex an der Supermarktkasse -
die Nachbarn hören es vermutlich aber trotzdem. Nein, ich will diese
nicht fragen.

Und da ich auch schon rund 10 Jahre mitschreibe, kann man denke ich
recht gut sehen, was ich verbrochen habe oder nicht. Jeder möge sich da
seine eigene Meinung bilden.

Aus meiner Sicht sind die Zeiten vorbei, wo Usenet eine gewisse
Privatheit hatte, sprich Arbeitskollegen, Personaler, Chefs, Abmahner
und Co wg. Nicht-Wissens nicht mitlasen. Es ist halt alles voll
indiziert heute und per Web zugreifbar und das auch noch in 100 Jahren
vermutlich. Die sozialen Zusammenhänge - wer redet mit wem, wer schreibt
wann usw. lassen sich sehr gut erkennen. Im Prinzip hat Usenet heute
Facebook-Charakter. Deine Usenet-Freunde erkennt man an den References,
die du verschickst.

Ich halte deine Sicht auf die Dinge für zu verengt, weil sie diese von
mir genannten Aspekte nicht berücksichtigen. Vor 10 Jahren habe ich das
selbst auch noch anders gesehen.

Datenschutz ist ein hohes Gut und ich finde es schon etwas stark von
Leuten zu verlangen auf Datenschutz zu verzichten, weil sie
mitdiskutieren wollen. Übrigens gab es auch schon solange ich im dt.
Usenet die Sicht, dass Privatheit wichtig ist. So wurde immer
wieder angebracht von zahlreichen Postern, dass im Falle eines Schadens
für den Poster, ein anonymes Posting vollkommen in Ordnung ist.

Heute muss ich leider attestieren, dass praktisch jede Form von
Öffentlichkeit, auch immer einen schädlichen Aspekt hat, da die Technik
zu weit fortgeschritten ist. Data-Mining ist kein Hobby mehr
irgendwelcher Nerds zuhause im Keller.

Fup ignoriert, da mir das Gruppenklima wichtig ist.

mfg
Oli
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
Thomas 'PointedEars' Lahn
2012-10-27 18:07:25 UTC
Permalink
Post by Wolfgang Klein
Post by Thomas 'PointedEars' Lahn
Es wäre hilfreich, wenn Du keine Pseudodaten posten würdest.
Das Verzeichnis, um das es geht, heißt wirklich "delete-me", denn ich
habe es so umbenannt. Das Verzeichnis kann beliebig umbenannt, aber
nicht gelöscht werden.
OK. Aber dass Du root auf *Deiner* Kiste bist heisst eben nicht
automatisch, dass Du auch über CIFS alles auf dem *fremden* NAS machen
darfst. Zum Beispiel könnte dort ein Dateisystem mit ACL oder Ähnlichem
laufen und der Benutzer, mit dem Du Dich mit dem NAS verbindest (der
ausserdem nicht root zu sein braucht), darf nicht alle Dateien dort sehen.
--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Christoph Schmees
2012-10-27 18:34:41 UTC
Permalink
Post by Wolfgang Klein
...
Es könnte sich also um einen Fehler im Dateisystem auf der NAS handeln.
Allerdings hätte ich erwartet, daß auf einem RAID 6 und einem
Dateisystem mit Journal eine solche Datenkorruption eben nicht passiert.
seit wann schützt ein RAID Level vor logischer Korruption des
Dateisystems? Die Korruption wird dann halt sicher verteilt, aber
es bleibt Korruption.

Im Übrigen würde ich mal dem Hinweis von Thomas nachgehen:
Vielleicht sieht der Benutzer, mit dem du auf die NAS zugreifst,
nicht alle Dateien. Schau mal nach den Rechten.

Christoph
--
email:
nurfuerspam -> gmx
de -> net
Helmut Hullen
2012-10-27 18:47:00 UTC
Permalink
Hallo, Christoph,

Du meintest am 27.10.12:

[...]
Post by Christoph Schmees
seit wann schützt ein RAID Level vor logischer Korruption des
Dateisystems? Die Korruption wird dann halt sicher verteilt, aber
es bleibt Korruption.
Ist das Dateisystem bestechlich, ist es bestochen oder ist es
bestechend?


"dict.tu-chemnitz.de" erklärt zu "corrupt" auch noch

to corrupt sth.; to distort sth. etw. verballhornen {vt} [ling.]
corrupting; distorting verballhornend
corrupted; distorted [anhören] [anhören] verballhornt
to corrupt a phrase eine Phrase verballhornen
to distort a text einen Text verballhornen

Ist das Dateisystem vielleicht gar verballhornt?

Oder bist Du nur ein Anhänger von Denglish?

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Christoph Schmees
2012-10-27 18:52:21 UTC
Permalink
Post by Helmut Hullen
Hallo, Christoph,
[...]
Post by Christoph Schmees
seit wann schützt ein RAID Level vor logischer Korruption des
Dateisystems? Die Korruption wird dann halt sicher verteilt, aber
es bleibt Korruption.
Ist das Dateisystem bestechlich, ist es bestochen oder ist es
bestechend?
"dict.tu-chemnitz.de" erklärt zu "corrupt" auch noch
to corrupt sth.; to distort sth. etw. verballhornen {vt} [ling.]
corrupting; distorting verballhornend
corrupted; distorted [anhören] [anhören] verballhornt
to corrupt a phrase eine Phrase verballhornen
to distort a text einen Text verballhornen
Ist das Dateisystem vielleicht gar verballhornt?
Oder bist Du nur ein Anhänger von Denglish?
jedenfalls :-)

außerdem habe ich schlicht das Wording (sic!) des Vorposters
(jaha) übernommen.

Christoph
--
email:
nurfuerspam -> gmx
de -> net
Michael Baeuerle
2012-10-28 15:48:41 UTC
Permalink
Post by Wolfgang Klein
Es könnte sich also um einen Fehler im Dateisystem auf der NAS handeln.
Allerdings hätte ich erwartet, daß auf einem RAID 6 und einem
Dateisystem mit Journal eine solche Datenkorruption eben nicht passiert.
RAID6 hilft dir dabei nichts, die Fehler werden dann halt redundant
gespeichert. Auch das Journal kann Datenkorruption (am Inhalt von
Dateien) nicht verhindern wenn man da wie ueblich wegen der Performance
nur die Metadaten durchschiebt. Es haelt dann allerdings das Dateisystem
selbst konsistent wenn auf den unteren Layern alles richtig
funktioniert. Sollte in deinem Fall der fsck ergeben, dass das
Dateisystem trotz Journal inkonsistent geworden ist, solltest du da mal
einen Blick drauf werfen (speziell auf die write barriers).

In deinem Fall muss man dazu IMHO auf die lokale Maschine, also das NAS.
Ich glaube nicht, dass du da via CIFS weit kommen wirst.


Micha
--
Ja - heutzutage schiesst man auch mit Kanonen auf Spatzen. Oder
steuert mit einem Pentium seine WC-Spuelung.
Wolfgang Gerber in dafc
Helmut Hullen
2012-10-28 16:07:00 UTC
Permalink
Hallo, Michael,

Du meintest am 28.10.12:

[...]
Post by Michael Baeuerle
Auch das Journal kann Datenkorruption (am Inhalt von
Dateien) nicht verhindern
Sind die Daten bestochen oder bestechlich oder bestechend?

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Sieghard Schicktanz
2012-10-28 18:02:12 UTC
Permalink
Hallo Helmut,
Post by Helmut Hullen
Post by Michael Baeuerle
Auch das Journal kann Datenkorruption (am Inhalt von
...
Post by Helmut Hullen
Sind die Daten bestochen oder bestechlich oder bestechend?
Sicher nicht _bestechend_.
Manche Leute meinen halt, sie gälten schon als gebildet, wenn sie es
fertigbringen, mit halbzerkauten Fremdwörtern um sich zu spucken. ;->
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Sieghard Schicktanz
2012-10-27 18:20:31 UTC
Permalink
Hallo Wolfgang,
Post by Wolfgang Klein
# rm -rf delete-me/
rm: cannot remove directory `delete-me': Directory not empty
Und mit rmdir?
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
Thomas 'PointedEars' Lahn
2012-10-27 21:15:34 UTC
Permalink
Post by Sieghard Schicktanz
Hallo Wolfgang,
Wir lesen hier alle mit.
Eine sinnvolle Einleitungszeile sieht anders aus. Deine Signatur ist auch
zu lang.

<http://lernst.de/zitieren/kriegst.de/antworten>
<http://kirchwitz.de/~amk/dni/netiquette>
Post by Sieghard Schicktanz
Post by Wolfgang Klein
# rm -rf delete-me/
rm: cannot remove directory `delete-me': Directory not empty
Und mit rmdir?
Weshalb sollte das erfolgreich sein, wenn `rm -rf' ausführbar ist,
aber nicht erfolgreich ist? `rm -rf' macht *mehr* als rmdir(1).
--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Oliver Sch@d
2012-10-27 23:54:34 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Post by Sieghard Schicktanz
Und mit rmdir?
Weshalb sollte das erfolgreich sein, wenn `rm -rf' ausführbar ist,
aber nicht erfolgreich ist? `rm -rf' macht *mehr* als rmdir(1).
In der Tat: rm -rf traversiert einen Verzeichnisbaum, weil man
Verzeichnisse mit Inhalt gar nicht löschen *kann*. Mal ein "strace rm -
rf" machen auf ein Verzeichnis.

mfg
Oli
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
Stefan Enzinger
2012-11-02 20:10:36 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Post by Sieghard Schicktanz
Post by Wolfgang Klein
# rm -rf delete-me/
rm: cannot remove directory `delete-me': Directory not empty
Und mit rmdir?
Weshalb sollte das erfolgreich sein, wenn `rm -rf' ausführbar ist,
aber nicht erfolgreich ist? `rm -rf' macht *mehr* als rmdir(1).
Ich habe das Heute auf der Uni erlebt. rmdir schaffte, was rm -rf nicht
konnte. Der gemeldete Fehler ist aber ein andere.
Auch über non-root ssh, allerdings auf einem ncpfs mount.

$ mkdir foo
$ touch foo/bar
$ rm -rf foo
rm: cannot remove `foo': Device or resource busy
$ ls -l foo
total 0
$ rm -rf foo
rm: cannot remove `foo': Device or resource busy
$ rmdir foo
$ ls -l foo
ls: cannot access foo: No such file or directory
Thomas 'PointedEars' Lahn
2012-11-02 20:22:56 UTC
Permalink
Post by Stefan Enzinger
Post by Thomas 'PointedEars' Lahn
Post by Sieghard Schicktanz
Post by Wolfgang Klein
# rm -rf delete-me/
rm: cannot remove directory `delete-me': Directory not empty
Und mit rmdir?
Weshalb sollte das erfolgreich sein, wenn `rm -rf' ausführbar ist,
aber nicht erfolgreich ist? `rm -rf' macht *mehr* als rmdir(1).
Ich habe das Heute auf der Uni erlebt. rmdir schaffte, was rm -rf nicht
konnte. Der gemeldete Fehler ist aber ein andere.
Auch über non-root ssh, allerdings auf einem ncpfs mount.
$ mkdir foo
$ touch foo/bar
$ rm -rf foo
rm: cannot remove `foo': Device or resource busy
$ ls -l foo
total 0
$ rm -rf foo
rm: cannot remove `foo': Device or resource busy
$ rmdir foo
$ ls -l foo
ls: cannot access foo: No such file or directory
uname -s | grep Linux? rmdir --help | grep GNU?

Falls nein: Das sieht für mich wie ein Bug oder das Ergebnis eines
konkurrenzierenden Zugriffs (Letzteres ist in einem Uni-RZ zu erwarten) aus.
`foo' darf/sollte nicht unlink(2)'d werden, wenn foo/bar existiert.
Entweder hat jemand anders inzwischen foo/bar verlassen und gelöscht
(autofs?) oder es ist ein Bug in diesem rmdir(1).
--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Stefan Enzinger
2012-11-02 20:40:46 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Post by Stefan Enzinger
Ich habe das Heute auf der Uni erlebt. rmdir schaffte, was rm -rf nicht
konnte. Der gemeldete Fehler ist aber ein andere.
Auch über non-root ssh, allerdings auf einem ncpfs mount.
$ mkdir foo
$ touch foo/bar
$ rm -rf foo
rm: cannot remove `foo': Device or resource busy
$ ls -l foo
total 0
$ rm -rf foo
rm: cannot remove `foo': Device or resource busy
$ rmdir foo
$ ls -l foo
ls: cannot access foo: No such file or directory
uname -s | grep Linux? rmdir --help | grep GNU?
es ist GNU rmdir auf Linux
Post by Thomas 'PointedEars' Lahn
Falls nein: Das sieht für mich wie ein Bug oder das Ergebnis eines
konkurrenzierenden Zugriffs (Letzteres ist in einem Uni-RZ zu erwarten) aus.
`foo' darf/sollte nicht unlink(2)'d werden, wenn foo/bar existiert.
Entweder hat jemand anders inzwischen foo/bar verlassen und gelöscht
(autofs?) oder es ist ein Bug in diesem rmdir(1).
Nein, rm -rf hat ja schon rekursiv gelöscht, foo/ ist damit leer. Ich
dachte das wäre aus der History klar. Nur ist foo selbst nicht entfernt
worden.

Auch wein wiederholtes
$ rm -rf foo/

bringt nichts. Erst ein
$ rmdir foo/
konnte das inzwischen leere Verzeichnis löschen.
Thomas 'PointedEars' Lahn
2012-11-02 21:37:42 UTC
Permalink
Post by Stefan Enzinger
Post by Thomas 'PointedEars' Lahn
Post by Stefan Enzinger
Ich habe das Heute auf der Uni erlebt. rmdir schaffte, was rm -rf nicht
konnte. Der gemeldete Fehler ist aber ein andere.
Auch über non-root ssh, allerdings auf einem ncpfs mount.
$ mkdir foo
$ touch foo/bar
$ rm -rf foo
rm: cannot remove `foo': Device or resource busy
$ ls -l foo
total 0
$ rm -rf foo
rm: cannot remove `foo': Device or resource busy
$ rmdir foo
$ ls -l foo
ls: cannot access foo: No such file or directory
uname -s | grep Linux? rmdir --help | grep GNU?
es ist GNU rmdir auf Linux
Märgwyhrdich. [psf 4.15]
Post by Stefan Enzinger
Post by Thomas 'PointedEars' Lahn
Falls nein: Das sieht für mich wie ein Bug oder das Ergebnis eines
konkurrenzierenden Zugriffs (Letzteres ist in einem Uni-RZ zu erwarten)
aus. `foo' darf/sollte nicht unlink(2)'d werden, wenn foo/bar existiert.
Entweder hat jemand anders inzwischen foo/bar verlassen und gelöscht
(autofs?) oder es ist ein Bug in diesem rmdir(1).
Nein, rm -rf hat ja schon rekursiv gelöscht, foo/ ist damit leer. Ich
dachte das wäre aus der History klar. Nur ist foo selbst nicht entfernt
worden.
Auch wein wiederholtes
$ rm -rf foo/
bringt nichts. Erst ein
$ rmdir foo/
konnte das inzwischen leere Verzeichnis löschen.
Muss am FS oder den Umständen liegen. Mit einem normalen, sauberen root-
ext3 passiert das als User hier (`Linux 3.3.1-pe #1 SMP … i686 GNU/Linux',
GNU rm/rmdir 8.5) nicht.

Genauer: rm -rf löscht einem anderen User auf demselbem System (auch root)
ohne Probleme das pwd(1) `foo' mit geöffnetem `foo/bar' "unterm Hintern weg"
(wie unlink(2) es auch dokumentiert), und rmdir(1) weigert sich wie
erwartet:

$ rmdir foo
rmdir: failed to remove `foo': Directory not empty
--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Stefan Reuther
2012-11-02 20:44:12 UTC
Permalink
Post by Stefan Enzinger
Ich habe das Heute auf der Uni erlebt. rmdir schaffte, was rm -rf nicht
konnte. Der gemeldete Fehler ist aber ein andere.
Auch über non-root ssh, allerdings auf einem ncpfs mount.
$ mkdir foo
$ touch foo/bar
$ rm -rf foo
rm: cannot remove `foo': Device or resource busy
$ ls -l foo
total 0
$ rm -rf foo
rm: cannot remove `foo': Device or resource busy
$ rmdir foo
$ ls -l foo
ls: cannot access foo: No such file or directory
Ich kenne von NFS das Verhalten, dass eine Datei, die man löscht,
während noch jemand anders die Finger drauf hat, in ".nfsXXXXX"
umbenannt und vom Server dann später, wenn der andere die Finger davon
gelassen hat, gelöscht wird. Möglicherweise ist das bei dir etwas
ähnliches und das Verzeichnis ist zufälligerweise beim 'rmdir' leer.
Oder der Server hat eine Sonderbehandlung für 'rmdir' für Verzeichnisse
voller gelöschter Dateien.

Der andere darauf zugreifende kann z.B. ein Virenscanner sein.

Unter Windows tritt das besonders gerne auf, weil man da standardmäßig
Dateien, die jemand geöffnet hat, gar nicht löschen kann.


Stefan
Oliver Sch@d
2012-10-27 23:28:38 UTC
Permalink
Post by Wolfgang Klein
Eine Freigabe auf einer NAS ist als CIFS (Samba) eingehangen. Ein
# du -sh delete-me/
0 delete-me/
# ls -ralF delete-me/
total 0
drwxr-xr-x 1 root root 0 2012-10-27 15:56 ../
drwxr-xr-x 1 root root 0 2012-07-01 00:35 ./
# rm delete-me/*
rm: cannot remove `delete-me/*': No such file or directory
# rm -rf delete-me/
rm: cannot remove directory `delete-me': Directory not empty
Wie kann das Verzeichnis zugleich keine Dateien enthalten und nicht
leer sein?
Dateisystem kapott oder Root-Kit installiert. Live-CD reinstecken,
mounten, nachgucken ob immer noch leer, danach fsck losjagen, nochmal
nachgucken.

mfg
Oli
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
Gernot Fink
2012-10-28 06:05:53 UTC
Permalink
Post by Oliver ***@d
Post by Wolfgang Klein
Eine Freigabe auf einer NAS ist als CIFS (Samba) eingehangen. Ein
Dateisystem kapott oder Root-Kit installiert. Live-CD reinstecken,
mounten, nachgucken ob immer noch leer, danach fsck losjagen, nochmal
nachgucken.
in diesem fall eher die Konfiguration des NAS anschauen.
Im Zweifelsfall die Platte in einen PC bauen und schauen was wirklich los ist.
Du greifst mit MS-Methoden darauf zu und musst auch die entsprechenden
Userrechte und User verwenden.

Schau dir mal die Tools setfacl und getfacl an.
--
MFG Gernot
Thomas 'PointedEars' Lahn
2012-10-28 10:41:01 UTC
Permalink
Post by Gernot Fink
Post by Oliver ***@d
Post by Wolfgang Klein
Eine Freigabe auf einer NAS ist als CIFS (Samba) eingehangen. Ein
Dateisystem kapott oder Root-Kit installiert. Live-CD reinstecken,
mounten, nachgucken ob immer noch leer, danach fsck losjagen, nochmal
nachgucken.
in diesem fall eher die Konfiguration des NAS anschauen.
Im Zweifelsfall die Platte in einen PC bauen und schauen was wirklich los
ist. Du greifst mit MS-Methoden darauf zu und musst auch die
entsprechenden Userrechte und User verwenden.
Schau dir mal die Tools setfacl und getfacl an.
Das sind sicher gute Tipps, aber anscheinend habt ihr Folgendes im OP
übersehen:

| Da die NAS in produktiver Umgebung benutzt wird, und außerdem zu weit
| entfernt steht, um "mal eben" hinzufahren, fallen Lösungen wie das
| Anklemmen an einen anderen Rechner aus!
--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Oliver Sch@d
2012-10-28 12:30:25 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
| Da die NAS in produktiver Umgebung benutzt wird, und außerdem zu
| weit entfernt steht, um "mal eben" hinzufahren, fallen Lösungen wie
| das Anklemmen an einen anderen Rechner aus!
Das mit dem NAS hab ich sowieso komplett überlesen. Da wäre sicher
nochmal ein guter Hinweis, dass der Datei-Dienst des NAS eine Datei auch
verbergen könnte.

mfg
Oli
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
Wolfgang Klein
2012-10-29 09:14:51 UTC
Permalink
Ich hatte mit einem NAS mal ein solches Problem, bei dem es half, mit
dem Admin-Account per FTP auf das NAS zu gehen und das Verzeichnis auf
diesem Wege zu loeschen. Vermutlich waere ein Zugriff auber Web-Interface
ebenfalls erfolgreich gewesen ...
Verrätst Du mir, welche Marke / welcher Typ von NAS das war?

Falls das Veröffentlichen solcher Infos gegen Firmenpolitik verstößt:
gerne per PN.
--
Wolfgang Klein
Oliver Sch@d
2012-10-28 12:29:26 UTC
Permalink
Post by Gernot Fink
Schau dir mal die Tools setfacl und getfacl an.
Wieso soll das einen Einfluss haben auf die Sichtbarkeit von Dateien? Da
würde ich bei einem NAS dann noch eher erwarten, dass bestimmte Dateien
nicht angezeigt werden.

mfg
Oli
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
Gernot Fink
2012-10-28 16:20:01 UTC
Permalink
Post by Oliver ***@d
Post by Gernot Fink
Schau dir mal die Tools setfacl und getfacl an.
Wieso soll das einen Einfluss haben auf die Sichtbarkeit von Dateien? Da
würde ich bei einem NAS dann noch eher erwarten, dass bestimmte Dateien
nicht angezeigt werden.
Ich würde auch erwarten dass es dieses ganze Problem nicht gibt.
Hattest du unter W... noch nie das Pronlem Dateien oder Verzeichnisse nicht
zu sehen?
Vieleicht benutzt OP einfach den falschen User.
Da liegt das Problem und nicht auf der Linuxseite.
--
MFG Gernot
Jan Heitkötter
2012-10-28 20:04:50 UTC
Permalink
Post by Wolfgang Klein
Wie kriege ich das Verzeichnis gelöscht?
Login auf dem NAS via ssh und als dortiger root das Verzeichnis löschen?
Wie Thomas in <***@PointedEars.de> schrieb, bist du nur
auf deiner lokalen Maschine root.

HTH

Jan
Thomas 'PointedEars' Lahn
2012-10-29 03:56:37 UTC
Permalink
Post by Jan Heitkötter
Post by Wolfgang Klein
Wie kriege ich das Verzeichnis gelöscht?
Login auf dem NAS via ssh und als dortiger root das Verzeichnis löschen?
Vor dem Löschen sollte man erstmal überprüfen, welche Dateien das Löschen
des Verzeichnisses verhindern und ob diese nicht vielleicht dort bleiben
sollten. Sonst löscht man vielleicht unabsichtlich wichtige Systemdateien.
Das kann bei einem Produktivsystem wie diesem teuer werden.

Ich mag jedoch bedreifeln, dass Wolfgang (einen brauchbaren) ssh-Login auf
der Maschine hat, welche das Share bereitstellt (denn dann würde er das
sicherere FISH¹ statt CIFS verwenden). Noch viel weniger wahrscheinlich ist
IMHO, dass er da root-Zugang hat. Dafür sprechen seine (relativ geringen)
*x-Kenntnisse und die Tatsache, dass er CIFS verwendet. Dagegen spricht
jedoch die Tatsache, dass er anscheinend System-Logs des NAS einsehen kann
(das sollte nur Administratoren möglich sein). CIFS (neuer Name für SMB,
früher per NetBIOS/NetBEUI) nutzt man jedenfalls üblicherweise mit Windows-
Freigaben bzw. Samba; zumindest Erstere verwenden ACLs.


¹ Files transferred over Shell protocol
--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Oliver Sch@d
2012-10-29 09:08:57 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Ich mag jedoch bedreifeln, dass Wolfgang (einen brauchbaren) ssh-Login
auf der Maschine hat, welche das Share bereitstellt (denn dann würde
er das
sicherere FISH¹ statt CIFS verwenden).
CIFS ist nicht unsicher in den neueren Varianten und FISH ist
vergleichsweise lahm - davon ab, dass das nicht besonders viel
implementiert ist.

mfg
Oli
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
Wolfgang Klein
2012-10-29 09:11:46 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Vor dem Löschen sollte man erstmal überprüfen, welche Dateien das Löschen
des Verzeichnisses verhindern und ob diese nicht vielleicht dort bleiben
sollten. Sonst löscht man vielleicht unabsichtlich wichtige Systemdateien.
Das kann bei einem Produktivsystem wie diesem teuer werden.
Nein, das ist auf keinen Fall so. Das zu löschende Verzeichnis ist vor 6
Monaten bei einer Datensicherung entstanden, und sollte turnusmäßig
gelöscht werden. Dabei trat das Problem auf, daß die NAS sich als 95%
belegt meldete und daher keine neue DaSi durchgeführt werden konnte. Im
Log der DaSi erschien die Fehlermeldung, daß das Verzeichnis der
ältesten Sicherung nicht gelöscht werden konnte. Manuell konnte ich dann
die Dateien in dem Verzeichnis löschen, aber seltsamerweise eben nicht
das Verzeichnis selber.

Seit dem wird das VZ als leer ausgewiesen, kann beliebig umbenannt
werden und hat mehrere Neustarts der NAS überlebt. Da das OS der NAS
beim Start einen Plattencheck durchführt, sollten Fehler im Dateisystem
(XFS) behoben sein. Weder das RAID-Log noch das SMART-Log der einzelnen
Platten zeigen Fehler an.
Post by Thomas 'PointedEars' Lahn
Ich mag jedoch bedreifeln, dass Wolfgang (einen brauchbaren) ssh-Login auf
der Maschine hat, welche das Share bereitstellt
Doch, hat er. ;-) Aaaaaber...
Post by Thomas 'PointedEars' Lahn
(denn dann würde er das sicherere FISH¹ statt CIFS verwenden).
Erstens obliegt ihm nicht die Entscheidung, welches Protokoll zu
verwenden ist. Er darf zwar Empfehlungen aussprechen, aber das war's. ;-)

Zweitens beschränkt sich der Zugang auf dem Server, der die NAS
einbindet, die NAS selber bietet keinen SSH-Zugang an.

Drittens bietet die NAS als Protokolle lediglich CIFS und NFS an. Und
NFS kam nicht in Frage, weil ab und zu von einem Windows-Rechner (nur
lesend!) auf die NAS zugegriffen werden muss.

UND, bevor jetzt jemand was entsprechendes denkt: bei den letzten
Versuchen, das VZ zu löschen, hat dieser Windows-Rechner NICHT auf die
NAS zugegriffen. Die NAS wurde dort abgemeldet, der Rechner sauber
heruntergefahren, also kein Tiefschlaf verwendet. Danach wurde die NAS
auf dem Linux-Server abgemeldet, aus dem Dateibaum ausgehangen und
ebenfalls neu gestartet.

Nach dem erneuten Einhängen der NAS-Freigabe auf dem Linux-Rechner war
das VZ immer noch vorhanden, immer noch leer, ließ sich immer noch
beliebig umbenennen, aber immer noch nicht löschen.
Post by Thomas 'PointedEars' Lahn
Noch viel weniger wahrscheinlich ist IMHO, dass er da root-Zugang hat.
Doch, hat er auch: über "sudo -s -H".
Post by Thomas 'PointedEars' Lahn
Dafür sprechen seine (relativ geringen)
*x-Kenntnisse und die Tatsache, dass er CIFS verwendet.
Liebes Spitzohr, wie Du Dich selber nennst, diesen Zusammenhang musst Du
mir jetzt aber mal erklären: was haben die durch Firmenpolitik
vorgegebene Benutzung von CIFS als Protokoll und meine Linux-Kenntnisse
miteinander zu tun? Wie schließt Du von dem einen auf das andere?

Das Problem wurde übrigens inzwischen durch eine laaaaaaaange und sehr
geduldige telefonische Einweisung eines Mitarbeiters vor Ort gelöst:
über die Web-Oberfläche der NAS konnte das VZ einfach gelöscht werden.
Thomas 'PointedEars' Lahn
2012-10-29 10:41:18 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Vor dem Löschen sollte man erstmal überprüfen, welche Dateien das Löschen
des Verzeichnisses verhindern und ob diese nicht vielleicht dort bleiben
sollten. Sonst löscht man vielleicht unabsichtlich wichtige
Systemdateien. Das kann bei einem Produktivsystem wie diesem teuer
werden.
Nein, das ist auf keinen Fall so. […]
ACK.
Post by Thomas 'PointedEars' Lahn
Ich mag jedoch bedreifeln, dass Wolfgang (einen brauchbaren) ssh-Login
auf der Maschine hat, welche das Share bereitstellt
Doch, hat er. ;-) Aaaaaber...
Post by Thomas 'PointedEars' Lahn
(denn dann würde er das sicherere FISH¹ statt CIFS verwenden).
Erstens obliegt ihm nicht die Entscheidung, welches Protokoll zu
verwenden ist. Er darf zwar Empfehlungen aussprechen, aber das war's. ;-)
Zweitens beschränkt sich der Zugang auf dem Server, der die NAS
einbindet, die NAS selber bietet keinen SSH-Zugang an.
Das habe ich erwartet, daher meine Vermutung.
Drittens bietet die NAS als Protokolle lediglich CIFS und NFS an.
Auch das habe ich erwartet.
Und NFS kam nicht in Frage, weil ab und zu von einem Windows-Rechner (nur
lesend!) auf die NAS zugegriffen werden muss.
Dito.
[…]
Post by Thomas 'PointedEars' Lahn
Noch viel weniger wahrscheinlich ist IMHO, dass er da root-Zugang hat.
Doch, hat er auch: über "sudo -s -H".
sudo ist kein root-Zugang. Über die sudoers(5) kann definiert werden, wer
was ausführen darf.

root-Zugang ist, wenn `su -' funktioniert.
Post by Thomas 'PointedEars' Lahn
Dafür sprechen seine (relativ geringen)
*x-Kenntnisse und die Tatsache, dass er CIFS verwendet.
Liebes Spitzohr, wie Du Dich selber nennst, diesen Zusammenhang musst Du
mir jetzt aber mal erklären: was haben die durch Firmenpolitik
vorgegebene Benutzung von CIFS als Protokoll und meine Linux-Kenntnisse
miteinander zu tun? Wie schließt Du von dem einen auf das andere?
Das habe ich im nachfolgenden, von Dir nicht zitierten Teil ausgeführt.
Das Problem wurde übrigens inzwischen durch eine laaaaaaaange und sehr
über die Web-Oberfläche der NAS konnte das VZ einfach gelöscht werden.
ACK.
--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Ulf Volmer
2012-10-29 10:53:05 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Post by Wolfgang Klein
Post by Thomas 'PointedEars' Lahn
Noch viel weniger wahrscheinlich ist IMHO, dass er da root-Zugang hat.
Doch, hat er auch: über "sudo -s -H".
sudo ist kein root-Zugang. Über die sudoers(5) kann definiert werden, wer
was ausführen darf.
'sudo -s' _ist_ root- Zugang.

Gruß,
Ulf.
Wolfgang Klein
2012-10-29 12:02:04 UTC
Permalink
Post by Ulf Volmer
'sudo -s' _ist_ root- Zugang.
Und funktioniert bei mir wohl nur deshalb, weil ich doch angeblich
"relativ geringe *x-Kenntnisse" habe.

Muss derselbe Effekt wie bei einer Hummel sein: die kann doch auch nur
fliegen, weil sie von Aerodynamik keine Ahnung hat! :-D


Wolfgang
Oliver Sch@d
2012-10-29 12:16:54 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Post by Wolfgang Klein
Post by Thomas 'PointedEars' Lahn
Noch viel weniger wahrscheinlich ist IMHO, dass er da root-Zugang hat.
Doch, hat er auch: über "sudo -s -H".
sudo ist kein root-Zugang. Über die sudoers(5) kann definiert werden,
wer was ausführen darf.
root-Zugang ist, wenn `su -' funktioniert.
"sudo -s" macht ganz tollen Root-Zugang, siehe man-Page.

mfg
Oli
--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
Thomas 'PointedEars' Lahn
2012-11-02 01:47:48 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Post by Wolfgang Klein
Doch, hat er auch: über "sudo -s -H".
sudo ist kein root-Zugang.
Wenn "sudo -s" oder "sudo -i" fuer den User existiert: doch.
Post by Thomas 'PointedEars' Lahn
Über die sudoers(5) kann definiert werden, wer was ausführen darf.
Wenn "sudo -s" oder "sudo -i" fuer den User erlaubt ist, kann man mit sudo
eine shell als root erlangen, und mehr bekommt man mit "su" auch nicht ...
Post by Thomas 'PointedEars' Lahn
root-Zugang ist, wenn `su -' funktioniert.
... oder "sudo -i", was auf anderem Wege zum selben Ergebnis fuehrt ...
Das kann ich aus der manpage nicht herauslesen. Ich verstehe sie
stattdessen so, dass sowohl die per $SHELL oder Default angegebene Shell wie
auch die Befehle, die mit -s ausgeführt werden können, den Beschränkungen
der sudoers(5) unterliegen. Hab' das aber nicht ausprobiert.
--
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Wolfgang Klein
2012-10-29 11:59:32 UTC
Permalink
Hattest du keinen ssh-Zugriff auf einen Server, von dem aus du an das
Webinterface des NAS herangekommen waerst? Wenn doch, haettest du dir
doch mit Portforwarding ueber ssh behelfen koennen, um selbst an das
Webinterface vom NAS heranzukommen. Oder war in der sshd-Konfiguration
Port-forwarding explizit disabled?
Hätte ich alles machen können, aber das hätte Ärger gegeben. Du weißt
ja: Firmenpolitik und so. Was der Chef nicht versteht, darf nicht
funktionieren....

Wolfgang
Loading...