Hi,

manchmal merkst du erst, wie gut ein Cloud-Dienst war, wenn er auf einmal nicht mehr so funktioniert wie früher. Genau das ist mir bei IDrive e2 passiert – dem günstigen, S3-kompatiblen Objektspeicher von IDrive. Lange Zeit war das Ding genau das, was viele Nerds suchen: günstig, einfach, ohne Egress-Theater und mit einer Bucket-Verwaltung, die sich anfühlt wie bei jedem anderen S3-Anbieter.

Bucket anlegen. Öffentlich oder privat. Fertig. Kein Ticket, kein Verhör, kein 100-TB-Abo. Und genau diese Selbstverständlichkeit ist weg.

Was IDrive e2 eigentlich sein wollte

IDrive e2 ist Objektspeicher im Amazon-S3-Stil. Du bekommst Buckets, Access Keys, Regionen, Object Locking, Versioning – und kannst den Speicher in Tools wie Rclone, Duplicati, Nextcloud, PeerTube oder eigene Apps hängen. Der Clou war lange der Preis: deutlich günstiger als AWS S3, oft ohne klassische Download-Gebühren, und mit einer Web-Konsole, die auch ohne Enterprise-Zertifikat verständlich war.

Für viele Use-Cases ist genau ein Feature entscheidend: Public Buckets. Statische Dateien, öffentliche Downloads, Bilder für eine Website, Medien für eine App, ein paar ISOs, ein öffentliches Asset-Repo. Bei Backblaze B2, Cloudflare R2, Wasabi, Hetzner Object Storage oder Contabo klickst du das in der Regel selbst. Genau so war es bei e2 früher auch.

Früher: öffentlich oder privat – ein Klick

In der alten Oberfläche sah das so aus, wie man es von einem normalen S3-Anbieter erwartet:

Du konntest festlegen, ob die Dateien im Bucket privat oder öffentlich sind. Und darunter die Zugriffsrechte: Nur lesen, Nur schreiben, Lesen und Schreiben oder Benutzerdefiniert. Genau so, wie man Object Storage benutzt, wenn man nicht gerade ein Konzern-Compliance-Team im Nebenraum sitzen hat.

Bei neueren Buckets fehlt diese Option einfach. Weg. Kein Radio-Button, kein Schalter, kein „Public“. Du sitzt vor der Konsole und denkst dir: Habe ich die falsche Seite auf? Nein. Die Funktion ist bewusst rausgenommen worden.

Was IDrive selbst dazu sagt

Das ist kein Halluzinations-Bug in der UI. IDrive hat die Default-Policy offiziell umgestellt. In den e2-FAQs steht sinngemäß:

Effective from 11-01-2024, IDrive e2 has updated its default policy regarding bucket access. For all accounts created after this date, the ability to set a bucket as public is disabled by default. To enable this feature you will need to send a request to IDrive e2 support.

IDrive e2 FAQ zu Buckets

Heißt: Nach dem 1. November 2024 ist Public Access bei neuen Accounts standardmäßig tot. Du darfst ein Ticket aufmachen, IDrive „prüft den Use Case“ und schaltet die Funktion nur frei, wenn sie zu den internen Guidelines passt. Copyright, Malware, Spam-Seiten – alles verboten. Fair enough, das verbietet fast jeder Anbieter. Der Unterschied ist: Andere lassen dich den Schalter trotzdem selbst umlegen und räumen hinterher auf, wenn jemand Mist baut. IDrive macht vorher eine Einlasskontrolle.

In der Cloudflare-Doku zu e2 steht sogar noch härter: Neue Public Buckets werden gar nicht mehr angelegt, nur noch bestehende öffentliche Buckets von vor dem 21. Juli 2026 seien verfügbar. Marketing-Seite und Support-Realität tanzen hier ohnehin nicht mehr im Takt. Auf der öffentlichen Feature-Seite liest sich Public Access nämlich weiter wie ein normaler, dokumentierter Klick mit E-Mail- und Telefon-Verifizierung.

Dann kam das Support-Schreiben

Also habe ich – wie angewiesen – den Support angeschrieben. Kein wildes Special-Request, sondern genau das, was IDrive selbst als Weg zurück zur Public-Option verkauft. Zurück kam kein „Klar, Bucket-Name bitte“, sondern ein Fragebogen, bei dem ich dachte: WTF. Die wollen halb ein Konzern-Audit, halb einen Personalausweis plus Kreditkarte, nur damit ein Bucket öffentlich lesbar wird.

Der Support wollte unter anderem:

• Legal business name, Website und verifizierte Domain
• Den exakten Grund, warum Public Access nötig ist
• Die genauen Bucket-Namen
• Ob der Inhalt firmeneigen oder nutzergeneriert ist
• Ob anonyme User Inhalte hochladen dürfen
• Wie jedes Objekt dem User-Account, der IP-Adresse und dem Upload-Zeitstempel zugeordnet wird
• Details zu Malware-Scanning, CSAM-/Hash-Scanning und Content-Moderation
• Wie User missbräuchliche Inhalte melden können
• Wie schnell gemeldete Inhalte gesperrt und geprüft werden
• Wie Uploadende identifiziert und gesperrt werden
• Wie lange Upload-, Zugriffs- und Moderations-Logs aufgehoben werden
• Ob der gesamte öffentliche Traffic über ein CDN oder eine kontrollierte Custom Domain läuft
• Ob einzelne URLs oder Uploader sofort deaktiviert werden können
• Einen namentlich benannten Security- und Abuse-Kontakt

Und als wäre das nicht schon übertrieben, kam danach noch die „Verifizierung“ der Zahlungsmittel:

• Die letzten 4 Ziffern der hinterlegten Karte
• Das Ablaufdatum der Karte
• Die vollständige Rechnungsadresse der Karte
• Haupt-Accountname und registrierte E-Mail
• Optional Betrag und Datum der letzten Transaktion
• Optional die hinterlegte Telefonnummer

Ich will einen Bucket öffentlich machen. Nicht das Internet übernehmen. Nicht User-Uploads von Millionen Fremden hosten. Nicht eine Darknet-Plattform bauen. Einen Bucket. Öffentlich. Wie 2018 bei jedem S3-Klon.

Der Punchline-Satz: erst ab 100 TB

Ganz am Ende des Schreibens steht dann der Satz, der die Sache von „lästig“ auf „Verarsche am Kunden“ hebt:

Please also note that public bucket access is only available for IDrive e2 accounts with 100 TB or higher storage plans. Accounts below this threshold are not eligible for enabling public bucket access.

IDrive e2 Support

100 Terabyte. Als Eintrittskarte für eine Funktion, die bei der Konkurrenz zur Grundausstattung gehört. Auf der IDrive-Preisseite reden wir bei 100 TB von einem Tarif, der für normale Homelab-, Blog- oder App-Projekte komplett irre ist. Du zahlst also erstmal brav für Speicher – und darfst eine Kernfunktion von Object Storage trotzdem nicht nutzen, solange du nicht Enterprise-Mengen buchst und dem Support dein halbes Compliance-Handbuch hinterherträgst.

Ja, ich verstehe den Hintergrund. Öffentliche Buckets werden missbraucht: Warez, Phishing, Malware, CSAM, SEO-Spam. Anbieter bekommen Abuse-Mails, Provider-Sperren, rechtlichen Ärger. Deshalb schrauben viele Clouds an Defaults. AWS hat „Block Public Access“. Cloudflare R2 ist da vorsichtiger. Das Problem ist nicht, dass IDrive vorsichtig sein will. Das Problem ist das Missverhältnis.

Warum das dreist ist

Ein S3-kompatibler Speicher ohne halbwegs nutzbaren Public Access ist für ganz viele Setups einfach unbrauchbar. Nicht jeder braucht anonymes Upload für die ganze Welt. Ganz oft reicht public-read: Die App oder die Website schreibt mit Access Key, die Dateien selbst sollen per URL erreichbar sein. Bilder, Videos, Updates, statische Seiten, öffentliche Dumps.

Genau dafür gab es den Schalter. Und genau dafür will IDrive jetzt:

1. Ein Support-Ticket statt eines UI-Klicks
2. Firmen- und Domain-Nachweis, als wärst du ein Konzern
3. ein komplettes Moderations- und Logging-Konzept
4. Zahlungsdaten nochmal extra durchreichen
5. und als Drop: mindestens 100 TB Plan

Das fühlt sich nicht nach Sicherheit an. Das fühlt sich an wie ein Feature, das man in der Werbung stehen lässt und in der Praxis so tief vergräbt, dass es nur noch Großkunden erreichen. Wer 1 TB, 5 TB oder 10 TB braucht, ist raus. Wer ein Hobby-Projekt, einen Blog, ein Homelab oder eine kleine App betreibt, ist raus. Wer nicht „legal business name + CSAM-Pipeline + named abuse contact“ vorweisen kann, ist raus.

Und ganz ehrlich: Kreditkarten-Ablaufdatum und Billing-Adresse per Ticket-Reply zu verlangen, nur um eine ACL zu ändern, ist auch kein schöner Move. Account-Verifizierung geht über Login, bestätigte Mail und notfalls eine Zahlung im Kundenbereich. Ein Freitext-Ticket mit Kartendaten ist das Gegenteil von dem, was man Leuten sonst beim Phishing-Thema predigt.

Was andere Anbieter daraus machen

Zum Vergleich, ohne dass das jetzt eine Riesen-Kaufberatung werden soll:

• Backblaze B2 – Buckets kannst du selbst auf öffentlich stellen, plus freundliche Download-Preise.
• Cloudflare R2 – öffentliche Zugriffe über Custom Domains und Zero-Egress-Modell, ohne 100-TB-Türsteher.
• Wasabi – klassisches S3, Policies selbst setzen.
• Hetzner Object Storage – in Europa, S3-kompatibel, ACLs und Policies ohne Verhör.
• Contabo / andere Hoster – oft ebenfalls direkt in der Konsole.

Keiner dieser Anbieter ist perfekt. Aber sie behandeln Public Access als Speicher-Feature, nicht als Enterprise-Add-on hinter einem Compliance-Formular. Wenn IDrive Missbrauch fürchtet, bitte: Default privat, Phone/Mail-Verify, Rate Limits, Abuse-Kontakt, schnelles Takedown. Alles okay. Aber nicht „erst 100 TB, dann Lebenslauf, dann vielleicht“.

Fazit

IDrive e2 hat bei mir als günstiger S3-Ersatz angefangen und als Lehrstück darüber geendet, wie man ein gutes Produkt unbenutzbar macht. Die alte Oberfläche war ehrlich: privat oder öffentlich, Rechte zuweisen, weiterarbeiten. Die neue Realität ist: Feature weg, Ticket auf, Fragebogen aus der Compliance-Hölle, und selbst dann nur, wenn du 100 TB oder mehr buchst.

Das war mir zu viel. Ich habe dort alles gekündigt und werde den Dienst nicht wieder nutzen. Wer Object Storage braucht, das sich wie Object Storage verhält, sollte sich e2 in der aktuellen Form sehr genau anschauen – und im Zweifel lieber zu einem Anbieter gehen, bei dem „Bucket public“ kein Bewerbungsgespräch ist.

Falls du ähnliche Erfahrungen mit e2 oder einem anderen S3-Klon gemacht hast: Schreib’s in die Kommentare. Mich würde echt interessieren, ob das nur einzelne Accounts erwischt – oder ob IDrive das Feature inzwischen praktisch beerdigt hat.

Liebe Grüße
Manu