Docker, NAS, Online-Business

Honeygain Lucky Pot automatisch claimen: Synology-NAS-Anleitung mit Docker

Posted by author-avatar
0
WarsoWerk Küchengerät auf Holztisch mit Pflanzen und Regal im Hintergrund.

TL;DR

  • Der Lucky Pot ist der tägliche Bonus von Honeygain. Du musst ihn im Dashboard öffnen. Wer ihn einen Tag nicht öffnet, verliert den Bonus für diesen Tag.
  • Ein Docker-Container (ghcr.io/xterna/honeygain-pot) loggt sich täglich ein und claimt den Pot automatisch. Ein Host-Cronjob ist nicht nötig.
  • Der Container läuft auf einer Synology mit DSM 7.2 oder neuer über den Container Manager oder per SSH mit Docker Compose. Unter DSM 6.2 bis 7.1 läuft er über das Docker-Paket.
  • Ports, Volumes und privilegierte Rechte sind nicht nötig. Laut Projekt braucht der Container im Leerlauf etwa 0,6 MB RAM.
  • Der Pot-Container erzeugt keinen Traffic und ersetzt nicht den Honeygain-Client. Der Client muss weiterlaufen, damit der Pot gefüllt wird.
  • Die Nutzung erfolgt auf eigenes Risiko. Die Automatisierung kann gegen die Honeygain-Nutzungsbedingungen verstoßen.

Der Honeygain Lucky Pot bringt täglich einen kleinen Bonus, aber nur, wenn du ihn auch öffnest. Im Alltag geht das schnell unter, und ein vergessener Tag kostet den Bonus. In dieser Anleitung zeige ich dir, wie du den Lucky Pot auf deiner Synology NAS automatisch claimen lässt: mit einem leichtgewichtigen Docker-Container, ohne Cronjob und ohne Skript-Installation.

Die Anleitung baut auf der Grundlagen-Anleitung „Honeygain Docker-Container auf Synology NAS einrichten” auf. Falls dein Honeygain-Client noch nicht läuft, richte zuerst den Client ein und ergänze danach den Pot-Container.

Was ist der Honeygain Lucky Pot?

Der Lucky Pot (auf Deutsch „Glückspot”) ist der tägliche Bonus von Honeygain. Du musst ihn im Honeygain-Dashboard öffnen, also claimen. Wer ihn einen Tag nicht öffnet, verliert den Bonus für diesen Tag.

Die Automatisierung übernimmt genau das: Ein Container loggt sich täglich mit deinen Honeygain-Zugangsdaten ein, claimt den Pot und wartet anschließend auf den nächsten Claim-Zeitpunkt.

Der Pot-Container erzeugt keinen Traffic und ersetzt nicht den Honeygain-Client. Er claimt nur den täglichen Bonus. Der Bandbreiten-Sharing-Client, der die Bandbreite teilt und Einnahmen erzeugt, muss weiterlaufen. Nur so wird der Pot überhaupt gefüllt.

Warum den Lucky Pot automatisch claimen?

Ein manueller Claim hängt an einem einzigen Klick, und ein vergessener Klick kostet den Bonus. Ein Container erledigt das dauerhaft, ohne dass du mitdenken musst:

  • Er läuft 24/7 im Hintergrund auf dem NAS, ohne laufenden Desktop-PC.
  • Er claimt täglich automatisch und wartet selbstständig auf den nächsten Claim-Zeitpunkt.
  • Nach einem NAS-Neustart startet er über die Docker-Restart-Policy wieder.
  • Er ist vom restlichen NAS-System isoliert und braucht keine Ports, keine Volumes und keine privilegierten Rechte.

Was macht der Pot-Container und was nicht?

Zwei Bausteine übernehmen unterschiedliche Aufgaben:

BausteinAufgabeErzeugt Traffic?
Honeygain-Client (honeygain/honeygain)teilt ungenutzte Bandbreite und erzeugt EinnahmenJa
Pot-Container (ghcr.io/xterna/honeygain-pot)claimt den täglichen Lucky PotNein

Der Pot-Container ist also eine reine Bequemlichkeits-Automatisierung für den täglichen Bonus. Ohne laufenden Honeygain-Client fehlt die Einnahmequelle, und der Pot wird nicht gefüllt.

Docker-Container oder eigener Cronjob?

Für die Automatisierung gibt es zwei Wege:

  1. Cronjob und eigenes Skript auf dem NAS: flexibel, aber wartungsintensiv. Login, Session-Handling, Fehlerbehandlung, Wartezeiten und API-Änderungen musst du selbst abdecken.
  2. Fertiger Docker-Container: bringt den kompletten Ablauf mit, also Login, Claim, Caching, Warten auf den nächsten Claim und Retry bei Fehlern. Auf einem NAS ist das der sauberste Weg.

Der hier beschriebene Container nutzt das Image ghcr.io/xterna/honeygain-pot aus dem GitHub-Projekt XternA/honeygain-reward. Laut Projekt ist es ein sehr leichter Bot auf Basis der Bun-JavaScript-Runtime, der den täglichen Lucky Pot automatisch claimt.

Vorteile des Containers:

  • Kein Host-Cronjob und keine Skript-Installation auf dem NAS nötig.
  • Automatischer Neustart über die Docker-Restart-Policy, auch nach einem NAS-Neustart.
  • Geringer Ressourcenverbrauch: laut Projekt etwa 0,6 MB RAM im Leerlauf und 0 % CPU im Idle.
  • Keine Ports, keine Volumes und keine privilegierten Rechte erforderlich.
  • Vom restlichen NAS-System isoliert.
  • Logs sind über Docker bzw. Container Manager einsehbar.

Der Container eignet sich damit auch für Einsteiger, die Docker bzw. Container Manager auf ihrer Synology bereits nutzen.

Voraussetzungen

Synology und Docker

Als Hardware genügt ein NAS mit Docker-Unterstützung. Viele aktuelle Synology DiskStation-Modelle mit DSM 7.2+ bringen den Container Manager direkt mit.

  • DSM 7.2 oder neuer: Paket Container Manager aus dem Paket-Zentrum installieren. Container Manager unterstützt Docker-Compose-Projekte direkt über die GUI.
  • DSM 6.2 bis 7.1: Paket Docker installieren. Die ältere Docker-GUI unterstützt keine Compose-Projekte. Hier ist die Einrichtung per SSH mit docker-compose oder docker run sinnvoll.
  • Administrator-Rechte auf dem NAS zum Installieren von Paketen und zum Ausführen von Docker-Befehlen.

Honeygain-Konto

  • Bestehendes Honeygain-Konto mit E-Mail-Adresse und Passwort.
  • Der Honeygain-Client läuft bereits, auf dem NAS, einem PC, einem Raspberry Pi oder einem anderen Gerät. Für die Pot-Automatisierung ist das nicht zwingend erforderlich, für die Einnahmen und das Füllen des Pots aber notwendig.
  • 2-Faktor-Authentifizierung: Falls dein Honeygain-Konto 2FA nutzt oder Honeygain eine zusätzliche Bestätigung verlangt, kann der Bot unter Umständen nicht automatisch einloggen. Das vorher prüfen. Gegebenenfalls 2FA deaktivieren (Sicherheitsabwägung) oder einen anderen Ansatz wählen.

Noch kein Honeygain-Konto? Hier registrieren. Die aktuellen Konditionen für Neukunden findest du auf der Anbieterseite.

Netzwerk und Architektur

  • Der Container benötigt ausgehende HTTPS-Verbindungen zu Honeygain. Eingehende Ports müssen nicht geöffnet werden.
  • Optional kannst du im Compose feste DNS-Server setzen, zum Beispiel 1.1.1.1 und 8.8.8.8, falls es im Container DNS-Probleme gibt.
  • Architektur prüfen: Das Standard-Image unterstützt linux/amd64 und linux/arm64. Für 32-Bit-ARM (armv7l) gibt es den separaten Tag :arm32v7.
  • x86_64 → Standard-Image
  • aarch64 → Standard-Image (arm64)
  • armv7l → Image-Tag :arm32v7
  • Andere Architekturen werden nicht unterstützt.
  • Auf der Synology per SSH prüfen: uname -m.

Rechtliches und Risiko

  • Die Automatisierung kann gegen die Honeygain-Nutzungsbedingungen verstoßen. Das Image ist ein Drittanbieter-Projekt und weder mit Honeygain verbunden noch von Honeygain offiziell unterstützt.
  • Nutzung auf eigenes Risiko. Unter anderem kann das Honeygain-Konto wegen automatisierter Zugriffe oder auffälliger Login-Muster gesperrt oder eingeschränkt werden.
  • Das Image wird laut Projekt ohne Gewährleistung bereitgestellt. Vor der Nutzung Lizenz und Bedingungen prüfen.

Die Container-Konfiguration

Image und Umgebungsvariablen

  • Image: ghcr.io/xterna/honeygain-pot
  • Benötigte Umgebungsvariablen:
  • EMAIL: Honeygain-E-Mail-Adresse
  • PASSWORD: Honeygain-Passwort
  • Alternativ kann ein Dotenv-File (.env) verwendet werden. Docker Compose liest eine Datei namens .env automatisch aus dem Projektordner und ersetzt ${...}-Platzhalter in der Compose-Datei.
  • Ports, Volumes und privilegierte Rechte sind nicht notwendig. Der Container ist zustandslos genug, dass er ohne Volume betrieben werden kann; die Session wird im Container zwischengespeichert.

Compose-Datei: nur der Pot-Container

Diese Variante ist für bestehende Honeygain-Nutzer die einfachste, wenn der Honeygain-Client bereits läuft und nicht angefasst werden soll.

services:
  honeygain-pot:
    container_name: honeygain-pot
    image: ghcr.io/xterna/honeygain-pot
    restart: unless-stopped
    environment:
      EMAIL: ${HONEYGAIN_EMAIL}
      PASSWORD: ${HONEYGAIN_PASSWORD}
    dns:
      - 1.1.1.1
      - 8.8.8.8

Hinweise:

  • container_name: honeygain-pot muss eindeutig sein. Falls der Name bereits vergeben ist, passe ihn an oder entferne den alten Container.
  • restart: unless-stopped startet den Container nach einem Neustart des NAS bzw. des Docker-Dienstes automatisch, außer er wurde manuell gestoppt. Für den Dauerbetrieb ist das die passende Einstellung.
  • depends_on fehlt hier bewusst. Es funktioniert nur innerhalb desselben Compose-Projekts. Wenn der Honeygain-Client in einem anderen Projekt oder als einzelner Container läuft, würde ein depends_on auf einen nicht vorhandenen Service zu einem Fehler führen.
  • In Docker Compose v2 ist die frühere version-Zeile optional und wird ignoriert. Für ältere docker-compose-Versionen kannst du version: "3.8" ergänzen; schädlich ist sie nicht.

Compose-Datei: Pot und Honeygain-Client in einem Projekt

Wenn der Honeygain-Client noch nicht läuft oder bewusst mit dem Pot-Container zusammen verwaltet werden soll, können beide Services in einer Compose-Datei stehen.

services:
  honeygain:
    container_name: honeygain
    image: honeygain/honeygain
    restart: unless-stopped
    command:
      - -tou-accept
      - -email
      - ${HONEYGAIN_EMAIL}
      - -pass
      - ${HONEYGAIN_PASSWORD}
      - -device
      - Synology
    dns:
      - 1.1.1.1
      - 8.8.8.8

  honeygain-pot:
    container_name: honeygain-pot
    image: ghcr.io/xterna/honeygain-pot
    restart: unless-stopped
    environment:
      EMAIL: ${HONEYGAIN_EMAIL}
      PASSWORD: ${HONEYGAIN_PASSWORD}
    dns:
      - 1.1.1.1
      - 8.8.8.8
    depends_on:
      - honeygain

Hinweise:

  • Nicht duplizieren: Wenn der Honeygain-Client bereits als Container läuft, lege nicht einfach einen zweiten Client mit demselben Gerätenamen an. Entweder ergänzt du nur den Pot-Service oder überführst den bestehenden Client in dasselbe Projekt.
  • -device Synology ist ein frei wählbarer Gerätename. Bei mehreren Clients verwende einen eindeutigen Namen.
  • -tou-accept akzeptiert die Honeygain-Nutzungsbedingungen. Mit dem Start des Clients werden diese akzeptiert; prüfe das vorher.
  • depends_on startet den Pot-Service nach dem Client. Es ist nur innerhalb desselben Projekts gültig. Technisch notwendig ist die Reihenfolge nicht, sauber ist sie trotzdem.
  • Der Pot-Container zählt nicht als zusätzliches Honeygain-Gerät; er loggt sich nur ins Web-Dashboard ein. Das Geräte-Limit des Clients wird dadurch nicht belastet.

Die .env-Datei

Die Zugangsdaten sollten nicht direkt in der Compose-Datei stehen. Besser ist eine .env-Datei im selben Ordner wie die Compose-Datei.

[email protected]
HONEYGAIN_PASSWORD=deinPasswort

Wichtige Punkte:

  • Keine Leerzeichen um das Gleichheitszeichen.
  • Die Variablennamen müssen zu den Platzhaltern in der Compose-Datei passen. Im Beispiel oben heißen sie HONEYGAIN_EMAIL und HONEYGAIN_PASSWORD.
  • Alternativ kannst du im .env direkt EMAIL und PASSWORD verwenden und im Compose entsprechend ${EMAIL} und ${PASSWORD} schreiben. Beides funktioniert, solange die Namen zusammenpassen.
  • Sonderzeichen im Passwort: Bei $, #, Leerzeichen oder anderen Sonderzeichen kann die Verarbeitung je nach Compose-Version unterschiedlich sein. Setze das Passwort dann in einfache Anführungszeichen oder verwende docker run --env-file, das die Werte unverändert übergibt. Prüfe den Login anschließend in den Logs.
  • Dateirechte: Die .env sollte nur für den Eigentümer lesbar sein, zum Beispiel mit chmod 600.
  • Freigabeberechtigungen: Beschränke die Freigabe docker auf der Synology auf Administratoren. Sonst können andere NAS-Benutzer die Zugangsdaten lesen.
  • Nicht in Git committen. Die .env gehört in .gitignore, falls der Ordner versioniert wird.

Optionale Ergänzungen

Log-Rotation, damit die Docker-Logs nicht unbegrenzt wachsen:

    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Optionales Memory-Limit (der Container braucht sehr wenig RAM):

    mem_limit: 128m

Beides ist optional. Der Container funktioniert auch ohne diese Angaben.

Einrichtung auf Synology, Variante A: Container Manager (DSM 7.2+)

Das ist der empfohlene Weg für aktuelle Synology-NAS mit DSM 7.2 oder neuer. Container Manager verwaltet Compose-Projekte über die GUI.

Projektordner und .env vorbereiten

  1. In File Station in die Freigabe docker wechseln (typischerweise /volume1/docker).
  2. Einen Ordner für den Pot-Container anlegen, zum Beispiel honeygain-pot.
  3. In diesem Ordner die Datei .env mit den Zugangsdaten anlegen. Dafür in File Station die Einstellungen öffnen und „Versteckte Dateien anzeigen” aktivieren, damit die Datei mit dem führenden Punkt sichtbar ist.
  4. Die .env mit den oben genannten Variablen befüllen.

Alternativ kannst du die .env per SSH anlegen, siehe Variante B.

Projekt in Container Manager erstellen

  1. Container Manager öffnen.
  2. Links den Bereich Projekt wählen und auf Erstellen klicken.
  3. Einen Projektnamen vergeben, zum Beispiel honeygain-pot.
  4. Als Pfad den zuvor angelegten Ordner auswählen, zum Beispiel docker/honeygain-pot.
  5. Als Quelle die Option wählen, eine neue docker-compose.yml zu erstellen, und den Compose-Inhalt aus dem Abschnitt „Compose-Datei: nur der Pot-Container” oder „Compose-Datei: Pot und Honeygain-Client in einem Projekt” einfügen.
  6. Den Assistenten abschließen. Container Manager führt anschließend docker compose up -d im Projektordner aus und startet den Container.

Hinweise:

  • Container Manager verwendet für Projekte üblicherweise die Datei docker-compose.yml. Docker Compose v2 akzeptiert auch compose.yaml.
  • Docker Compose liest die .env automatisch aus dem Projektordner. Wenn die Datei fehlt oder falsch benannt ist, bleiben die Platzhalter leer und der Login schlägt fehl.
  • Falls der Container vor der .env startet und deshalb ständig neu startet: .env ergänzen und das Projekt neu starten.
  • In den Projekteinstellungen prüfen, ob „Autostart” aktiviert ist. Unabhängig davon sorgt restart: unless-stopped dafür, dass der Container nach einem Neustart wieder läuft.

Logs prüfen

  1. In Container Manager das Projekt honeygain-pot öffnen.
  2. Den Container auswählen und die Logs bzw. Details öffnen.
  3. Erwartete Ausgabe: Login, erfolgreicher Claim, Wartezeit bis zum nächsten Claim.

Projekt aktualisieren

Wenn eine neue Image-Version verfügbar ist, aktualisiere das Projekt (Image neu ziehen und Container neu erstellen). In Container Manager geht das über die Projektaktionen; per SSH mit docker compose pull und docker compose up -d.

Einrichtung auf Synology, Variante B: SSH + Docker Compose

Diese Variante ist für DSM 6.2 bis 7.1 mit dem älteren Docker-Paket sinnvoll oder wenn du die Kommandozeile bevorzugst.

SSH aktivieren und verbinden

  1. Systemsteuerung → Terminal & SNMP → SSH-Dienst aktivieren.
  2. Mit einem Administrator-Benutzer per SSH verbinden.
  3. Auf der Synology werden Docker-Befehle in der Regel mit sudo ausgeführt.

Ordner, Compose-Datei und .env anlegen

sudo mkdir -p /volume1/docker/honeygain-pot
cd /volume1/docker/honeygain-pot

sudo tee docker-compose.yml > /dev/null <<'EOF'
services:
  honeygain-pot:
    container_name: honeygain-pot
    image: ghcr.io/xterna/honeygain-pot
    restart: unless-stopped
    environment:
      EMAIL: ${HONEYGAIN_EMAIL}
      PASSWORD: ${HONEYGAIN_PASSWORD}
    dns:
      - 1.1.1.1
      - 8.8.8.8
EOF

sudo tee .env > /dev/null <<'EOF'
[email protected]
HONEYGAIN_PASSWORD=deinPasswort
EOF

sudo chmod 600 .env

Hinweise:

  • Das quoted Heredoc (<<'EOF') verhindert, dass die Shell ${HONEYGAIN_EMAIL} vorzeitig ersetzt. Die Platzhalter bleiben für Docker Compose erhalten.
  • Wer lieber einen Editor nutzt, kann die Dateien auch mit vi oder nano (falls installiert) anlegen.
  • Der Pfad /volume1/docker/... muss zum Volume passen, auf dem die Freigabe docker liegt. Bei mehreren Volumes passe ihn entsprechend an.

Container starten

Je nach DSM-Version und installiertem Compose-Plugin:

sudo docker compose up -d

oder, falls nur die ältere Version verfügbar ist:

sudo docker-compose up -d

Prüfen, welcher Befehl vorhanden ist:

docker compose version
docker-compose version

Falls sudo docker den Befehl nicht findet, verwende den vollständigen Pfad:

sudo /usr/local/bin/docker compose up -d

Fallback ohne Compose: docker run

Wenn weder docker compose noch docker-compose verfügbar ist, kannst du den Container direkt starten. Wichtig: Verwende --env-file, damit die Zugangsdaten nicht in der Shell-History oder in docker inspect als Klartext-Kommandozeile auftauchen.

sudo docker run -d \
  --name honeygain-pot \
  --restart unless-stopped \
  --env-file /volume1/docker/honeygain-pot/.env \
  --dns 1.1.1.1 \
  --dns 8.8.8.8 \
  ghcr.io/xterna/honeygain-pot

Hinweis: Die .env-Datei muss in diesem Fall die Variablennamen enthalten, die das Image erwartet. Wenn sie HONEYGAIN_EMAIL/HONEYGAIN_PASSWORD enthält, funktioniert --env-file nicht direkt, weil das Image EMAIL/PASSWORD erwartet. Lege entweder eine separate .env mit EMAIL/PASSWORD an oder mappe die Variablen im docker run-Befehl explizit. Für Compose ist die Mapping-Variante der sauberste Weg.

Logs und Status prüfen

sudo docker ps | grep honeygain-pot
sudo docker logs --tail 100 honeygain-pot

Mit -f folgt das Log live:

sudo docker logs -f honeygain-pot

Aktualisieren

cd /volume1/docker/honeygain-pot
sudo docker compose pull
sudo docker compose up -d

Bei docker run ziehst du das Image neu, entfernst den alten Container und startest neu.

Überprüfung: Läuft der automatische Claim?

Log-Ausgabe

Der Bot loggt den Ablauf. Die genaue Ausgabe kann je nach Image-Version variieren. Typisch ist:

------------ Honeygain Pot Auto Claim ------------
Logging in as [email protected]
Logged into Honeygain 🐝
--------------------------------------------------

Active Devices: ...

Claimed ... credits ✅
Won today ... credits 🤑
Gathered ... GB today 💻
Earned today ... credits 🍯

Waiting for next available pot to claim 🍯
Ready to claim in 7 hours 40 minutes ⏱️

Current logged time: ...
Next event trigger:  00:00:00

Ready to claim again ✅

Wichtig:

  • Wenn der Pot an diesem Tag bereits geclaimt wurde, zeigt der Bot eine Wartezeit bis zum nächsten Claim. Das ist kein Fehler.
  • Der Bot cached die Session, um unnötige Logins zu vermeiden. Nach einem Neustart des gleichen Containers bleibt der Cache erhalten; bei einer Neuerstellung loggt er sich neu ein.
  • Die genaue Claim-Zeit legt das Image intern fest. Eine Zeitzonen-Variable ist in der Projekt-Dokumentation nicht beschrieben. Häufig orientiert sich der nächste Trigger an 00:00 UTC; in Deutschland ist das je nach Sommerzeit 01:00 oder 02:00 Uhr. Die Logs zeigen die tatsächliche nächste Verfügbarkeit.

Dashboard prüfen

Im Honeygain-Dashboard prüfst du, ob der Pot für den Tag geclaimt wurde und wann der nächste Claim möglich ist. Das ist die zuverlässigste Bestätigung, dass die Automatisierung funktioniert.

Autostart nach Neustart testen

  1. Für den echten Test lässt du den Container laufen und startest das NAS neu.
  2. Nach dem Neustart prüfst du, ob der Container wieder läuft: Container Manager → Projekt/Container oder docker ps.
  3. Prüfe in den Logs, ob der Bot wieder aktiv ist.
  4. Wenn der Container nach dem Neustart nicht startet: Restart-Policy und Projekt-Autostart prüfen.

Compose-Konfiguration validieren

Im Projektordner:

sudo docker compose config

Damit wird die aufgelöste Compose-Datei angezeigt. Prüfe, ob EMAIL und PASSWORD korrekt eingesetzt wurden und nicht leer sind. Das ist der schnellste Test, wenn der Login fehlschlägt.

Troubleshooting

ProblemWahrscheinliche UrsacheLösung
Container startet ständig neuLogin schlägt fehlZugangsdaten prüfen; docker compose config auf leere Variablen prüfen; 2FA prüfen
„Login failed” in den LogsFalsches Passwort, Sonderzeichen, 2FAPasswort testen; Sonderzeichen quoting; 2FA deaktivieren oder anderen Ansatz wählen
.env wird nicht gelesenDatei fehlt, falscher Name, falscher Ordner.env exakt im Projektordner anlegen; Dateiname prüfen; versteckte Dateien anzeigen
depends_on-FehlerClient nicht im selben Compose-Projektdepends_on entfernen oder beide Services in ein Projekt legen
„exec format error” / „no matching manifest”Falsche Architekturuname -m prüfen; bei armv7l den Tag :arm32v7 verwenden
DNS-FehlerContainer erreicht Honeygain nichtDNS 1.1.1.1/8.8.8.8 setzen; NAS-Firewall für ausgehende Verbindungen prüfen
Container-Name bereits vergebenName honeygain-pot existiert schonAlten Container entfernen oder container_name anpassen
Pot bereits geclaimtHeute schon geclaimtKein Fehler; Bot wartet bis zum nächsten Claim
Konto-SicherheitswarnungLogin von ungewohnter IP / automatisierte ZugriffeBot stoppen; manuell einloggen und Warnung prüfen; möglichst dieselbe öffentliche IP wie der Client nutzen
API-Änderung bei HoneygainBot veraltetImage aktualisieren; Logs und Projektseite prüfen
sudo docker nicht gefundenDocker-Pfad nicht im sudo-PATHsudo /usr/local/bin/docker ... verwenden
docker compose nicht gefundenNur älteres Docker-Paketdocker-compose oder docker run verwenden

2FA und Login

Falls Honeygain eine Zwei-Faktor-Authentifizierung oder eine zusätzliche Bestätigung verlangt, kann der Bot scheitern. Dann hast du zwei Möglichkeiten:

  • 2FA deaktivieren (weniger sicher, aber der Bot kann sich anmelden).
  • Auf die Automatisierung verzichten und den Pot manuell claimen.

Dieselbe öffentliche IP wie der Client

Der Bot loggt sich in das Honeygain-Web-Dashboard ein. Am unauffälligsten ist es, ihn im selben Netzwerk bzw. hinter derselben öffentlichen IP wie den Honeygain-Client zu betreiben. Ein Login von einer völlig anderen IP kann Sicherheitsprüfungen oder Warnungen auslösen. Wenn der Client auf dem NAS läuft, ist der Pot-Container auf dem NAS daher die naheliegendste Wahl.

Sicherheit und Rechtliches

Zugangsdaten schützen

  • Zugangsdaten nicht direkt in der Compose-Datei hardcoden. Verwende .env.
  • Schütze die .env mit chmod 600 und beschränke die Freigabe docker auf Administratoren.
  • Versioniere die .env nicht in Git.
  • Benutzer mit Docker-Zugriff können Umgebungsvariablen über docker inspect einsehen. Auf einem NAS sind das in der Regel Administratoren. Der Docker-Zugriff sollte entsprechend beschränkt sein.
  • Für höhere Sicherheit wären Docker Secrets denkbar. Das Image erwartet jedoch Umgebungsvariablen; dafür wäre ein Wrapper nötig. Für die meisten Heim-NAS ist eine gut geschützte .env ausreichend.

2FA-Abwägung

2FA erhöht die Kontosicherheit, kann aber die Automatisierung verhindern. Wer 2FA aktiviert lässt, muss damit rechnen, dass der Bot nicht funktioniert. Das ist eine bewusste Abwägung zwischen Sicherheit und Komfort.

Nutzungsbedingungen und Haftung

  • Die Automatisierung kann gegen die Honeygain-Nutzungsbedingungen verstoßen. Prüfe das vor der Nutzung.
  • Es besteht das Risiko einer Kontosperrung oder Einschränkung.
  • Das Image ist ein Drittanbieter-Projekt, nicht mit Honeygain verbunden und wird ohne Gewährleistung bereitgestellt.
  • Die Nutzung erfolgt auf eigenes Risiko und in eigener Verantwortung.

Netzwerk und Rechte

  • Der Container benötigt nur ausgehende Verbindungen. Öffne keine Ports nach außen.
  • Privilegierte Rechte (privileged: true) sind nicht nötig.
  • Zugriff auf das Host-Dateisystem ist nicht nötig. Volumes sind nicht erforderlich.
  • Der Container läuft isoliert im Docker-Netzwerk.

Checkliste

  • ☐ Container Manager (DSM 7.2+) bzw. Docker-Paket installiert.
  • ☐ Honeygain-Client läuft (auf dem NAS oder einem anderen Gerät).
  • ☐ Projektordner auf der Synology angelegt, zum Beispiel docker/honeygain-pot.
  • ☐ .env mit HONEYGAIN_EMAIL und HONEYGAIN_PASSWORD angelegt und geschützt.
  • ☐ Compose-Datei mit dem honeygain-pot-Service erstellt.
  • ☐ Container gestartet und Status „läuft”.
  • ☐ Logs zeigen erfolgreichen Login und Claim.
  • ☐ Honeygain-Dashboard bestätigt den geclaimten Pot.
  • ☐ Autostart nach einem NAS-Neustart getestet.
  • ☐ .env-Rechte und Freigabeberechtigungen eingeschränkt.
  • ☐ Nutzungsbedingungen und Risiko verstanden.

FAQ: Honeygain Lucky Pot automatisch claimen

Was ist der Honeygain Lucky Pot?

Der Lucky Pot ist der tägliche Bonus von Honeygain. Du musst ihn im Honeygain-Dashboard öffnen, also claimen. Wer ihn einen Tag nicht öffnet, verliert den Bonus für diesen Tag.

Kann ich den Lucky Pot automatisch claimen lassen?

Ja. Ein Docker-Container (ghcr.io/xterna/honeygain-pot) loggt sich täglich mit deinen Zugangsdaten ein, claimt den Pot und wartet auf den nächsten Claim-Zeitpunkt. Das läuft auf dem NAS im Hintergrund, ohne Desktop-PC.

Erzeugt der Pot-Container eigenen Traffic oder Einnahmen?

Nein. Der Pot-Container erzeugt keinen Traffic und bringt keine Bandbreiten-Einnahmen. Er claimt nur den täglichen Bonus. Für Einnahmen muss zusätzlich der Honeygain-Client laufen, sonst wird der Pot nicht gefüllt.

Funktioniert das trotz 2-Faktor-Authentifizierung?

Nicht zuverlässig. Wenn dein Konto 2FA nutzt oder Honeygain eine zusätzliche Bestätigung verlangt, kann der Bot nicht automatisch einloggen. Entweder deaktivierst du 2FA (Sicherheitsabwägung) oder du claimst den Pot weiter manuell.

Welche Synology-Version brauche ich?

Ab DSM 7.2 nutzt du den Container Manager mit Compose-Projekten über die GUI. Unter DSM 6.2 bis 7.1 läuft die Einrichtung über das Docker-Paket per SSH mit docker-compose oder docker run.

Läuft der Container auch auf QNAP, Raspberry Pi oder Ubuntu?

Ja. Das Image unterstützt linux/amd64 und linux/arm64; für 32-Bit-ARM gibt es den Tag :arm32v7. Solange Docker bzw. Compose verfügbar ist, lässt sich der Container auch auf anderen Systemen betreiben.

Braucht der Container Ports oder ein Volume?

Nein. Ports und Volumes sind nicht nötig, privilegierte Rechte ebenso wenig. Die Session wird im Container zwischengespeichert; bei einer Neuerstellung loggt er sich einfach neu ein.

Wie prüfe ich, ob der automatische Claim funktioniert?

Über die Container-Logs (Login, erfolgreicher Claim, Wartezeit bis zum nächsten Claim) und das Honeygain-Dashboard, in dem du siehst, ob der Pot für den Tag geclaimt wurde. Das Dashboard ist die zuverlässigste Bestätigung.

Verstößt das gegen die Honeygain-Nutzungsbedingungen?

Das kann sein. Die Automatisierung ist kein offizieller Honeygain-Funktionsumfang, und das Image ist ein unabhängiges Drittanbieter-Projekt. Prüfe die Nutzungsbedingungen vorab und nutze das Setup auf eigenes Risiko.

Fazit

Für bestehende Honeygain-Nutzer ist der Pot-Container die einfachste Möglichkeit, den täglichen Lucky Pot automatisch zu claimen. Der Container läuft dauerhaft, loggt sich bei Bedarf ein, claimt den Bonus und wartet auf den nächsten Zeitpunkt. Auf einer Synology mit DSM 7.2+ genügt dafür ein Container-Manager-Projekt mit einer Compose-Datei und einer .env-Datei. Der Ressourcenverbrauch ist minimal, Ports und Volumes sind nicht nötig.

Der Pot-Container ersetzt nicht den Honeygain-Client, und die Automatisierung ist kein offizieller Honeygain-Funktionsumfang. Nutze sie auf eigenes Risiko, schütze die Zugangsdaten und beachte die Nutzungsbedingungen.

Noch kein Honeygain-Konto? Jetzt registrieren. Die aktuellen Konditionen findest du auf der Anbieterseite.

Quellen und weiterführende Links

  • GitHub-Projekt XternA/honeygain-reward (Image ghcr.io/xterna/honeygain-pot): https://github.com/XternA/honeygain-reward
  • Docker-Hub-Alternative: https://hub.docker.com/r/xterna/honeygain-pot
  • Synology Knowledge Center, Container Manager, Projekte: https://kb.synology.com/en-global/DSM/help/ContainerManager/docker_project
  • Docker Compose, Umgebungsvariablen und .env: https://docs.docker.com/compose/environment-variables/
  • Honeygain, Nutzungsbedingungen: https://www.honeygain.com/terms-of-use/

Hinweis: Dieser Artikel enthält Affiliate-Links (Honeygain, Amazon). Wenn du dich über diese Links registrierst oder einkaufst, erhalte ich eine kleine Provision, für dich entstehen keine Mehrkosten. Danke für deine Unterstützung!

Back to list
Older Honeygain Docker-Container auf Synology NAS einrichten – Anleitung für den 24/7-Betrieb

Related Posts

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert