Archiv verlassen und diese Seite im Standarddesign anzeigen : Verzeichnis- Sambashare Größen überwachen
Hallo zusammen,
ich habe hier ein kleine Problem. Unsere Nutzer hier im Netzwerk müllen systematisch unsere Samba Shares zu, ohne Sinn und verstand. Die hiesige Umgebung ist, wie man so schön sagt, historisch gewachsen, d.h. es herrscht ein relatives durcheinander.
Nachdem es heute irgendwer geschafft hat, gleich zwei Samba Shares nahezu an die Kapazitätsgrenze zu fahren, bin ich auf der Suche nach einer Möglichkeit einfach herauszufinden, welche Verzeichnisse welchen Datenzuwachs haben. Ein Script welches mir im Stundenrythmus einen "du -h --max-depth=n" oder so durchs Dateisystem jagt wollte ich eigentlich vermeiden.
Vielleicht kennt ja jemand von Euch ein entsprechendes Tool, dass sowas in der Art bietet.
Gruß Carsten
Schau dir mal Treesize an, läuft zwar unter Windows, kann man aber auf Shares loslassen. Damit bekommt man einen sehr netten Überblick. Zudem ist es kostenlos.
Wie wäre es wenn du mit quota jeden user im Speicherplatz beschränkst ;)
:D dann können sie nicht mehr alles so zu müllen
Quotas sind immer eine gute Idee. :)
Ja, Quotas - prinzipiell eine gute Idee. Aber wie das halt so ist, scheitert es schon am Versuch das durchzusetzen. Ausserdem geht es hier um die Abteilungslaufwerke, weniger um die Homelaufwerke der einzelnen Benutzer. Kennst Samba eine Quota Funktion bezogen auf Sharebasis. Hatte zwar gesucht, auf die Schnelle aber nix gefunden.
AFAIK gibt es nur Filesystem-Quotas, keine Share-Quotas.
AFAIK gibt es nur Filesystem-Quotas, keine Share-Quotas.
Hmmmm, wenn sich die User mit PW und Usernamen auf den shares einlocken , greifen die quotas normal, wenn aber ein Verzeichnis von jedem zugänglich ist dann wieder nicht (also ohne PW und Username zugänglich) ...
aber ich denke du wirst um ein script nicht herumkommen ...
hab hier was intressantes gefunden
[global] max log size = Zahl
Vorgabe: 5000
Erlaubte Werte: Größe in KB
Setzt die Größe (in Kilobytes), bei der Samba ein neue Logdatei beginnt. Die momentane Logdatei wird mit der Erweiterung .old umbenannt, wobei jede frühere Datei mit diesem Namen überschrieben wird.
[global] max mux = Zahl
Vorgabe: 50
Erlaubte Werte: Zahl
Setzt die Zahl der gleichzeitigen Operationen, die Sambaclients machen dürfen. Vermeide eine Änderung.
[global] max packet = Zahl
Vorgabe: N/A
Erlaubte Werte: Zahl
Synonym für packet size. Obsolet seit Samba 1.7. Verwende stattdessen max xmit.
[global] max open files = Zahl
Vorgabe: 10.000
Erlaubte Werte: Zahl
Begrenzt die Zahl der Dateien, die ein Sambaprozess versucht, zu einem bestimmten Zeitpunkt offen zu halten. Samba erlaubt dir, das auf weniger als das Unix-Maximum zu setzen. Diese Option ist eine Arbeitserprobung für ein einzelnes Problem. Vermeide eine Änderung. Diese Option wurde in Samba 2.0 eingeführt.
[global] max ttl = Sekunden
Vorgabe: 14400 (4 h)
Erlaubte Werte: Zeit in Sekunden
Setzt die Zeit, in der NetBIOS-Namen im nmbd-Cache aufbewahrt werden, während versucht wird, eine Abfrage nach ihnen durchzuführen. Vermeide eine Änderung.
[global] max wins ttl = Sekunden
Vorgabe: 259200 (3 Tage)
Erlaubte Werte: Zeit in Sekunden
Begrenzt die Lebenszeit eines NetBIOS-Namens im nmbd WINS-Cache in Sekunden. Vermeide eine Änderung.
[global] max xmit = Bytes
Vorgabe: 65535
Erlaubte Werte: Größe in Bytes
Setzt die maximale Paketgröße, die von Samba durchgelassen wird. Ein Tuning-Parameter für langsame Links und Bugs älterer Clients. Vor Werten unter 2048 wird abgeraten.
(das steht im link weiter unten ;) )
http://lug.krems.cc/docu/samba/appc_01.html
du könntest es ja so beschränken das User nur gewisse Paket größen drauf speichern können, Samba also erst gar nicht GB große Pakete durchlässt
du könntest es ja so beschränken das User nur gewisse Paket größen drauf speichern können, Samba also erst gar nicht GB große Pakete durchlässt
Ich kenne Jumbo-Frames, aber das die jetzt schon GB-groß werden können?
http://de.wikipedia.org/wiki/Maximum_Transmission_Unit
mamue
P.S.: Jumbo Frames: zu meiner Überaschung bis zu 9000 Oktets groß.
Ich kenne Jumbo-Frames, aber das die jetzt schon GB-groß werden können?
http://de.wikipedia.org/wiki/Maximum_Transmission_Unit
mamue
P.S.: Jumbo Frames: zu meiner Überaschung bis zu 9000 Oktets groß.
das mit den GB war ja auch nur als Beispiel gemeint ;)
Ich hatte vorsichtig anzudeuten versucht, dass das 100% in die falsche Richtung geht. Mit den Parametern, die den Transfer auf Protokollebene beeinflussen, kann man garantiert keine Beschränkungen auf Applikationsebene gewährleisten. Wie groß eine Datei wird oder wie große alle Dateien eines Users werden, hängt ganz sicher nicht von diesen Parametern ab.
Wenn man aber lange genug daran herumdreht, gehen die Anwender vielleicht genervt nach Hause und insofern hätte man das Problem tatsächlich gelöst ;-)
mamue
lol, naja es war zumindest ein gut gemeinter Vorschlag ;)
:D
Zumal man sich mit Jumbo Frames auch viele andere Probleme einhandeln kann.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.