Posts by Steini

    Ok but how can I limit the size of the backup? Time machine makes an incremental backup and as long as there is space the backup grows

    Found the solution here:…chine_backups_on_a_samba/

    To set quotas you need to put a file:

    cat <<< _EOF_ > /srv/backup/timemachine/$USERNAME/
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
    <plist version="1.0">

    Size is in Byte, so 300GB in this example

    When I read the topic with "RPi" and "Raid" it was clear I would need popcorn...
    Many people setting up raid do not know how to handle them in case of a problem (at least I didn't know that when I first used a raid). Therefore, the support forums are full of people crying for help because their data is lost. So again, most people talking about raid have heard somewhere, that it is cool/save/fast/etc.. but don't know it. I wanted to have a raid because of speed. However, nowadays it is bullshit, if you want speed, just use a big SSD, which can easily saturate Gbit ethernet and soon 10G ethernet.
    If you want to sleep better thinking at your NAS, do not forget about Self-Monitoring, Analysis and Reporting Technology (SMART).

    Thankfully, SMART capabilities have become so powerful that all my drives which have failed in the last years (decades) did not fail silently, but were getting more and more errors over time. You could literally watch them aging before dying. At least, it was enough time to update the backup and plan the swap the drive without any downtime. That only works, if there is no single event which kills your hard drive (like power outage, fire, water leak, theft ...). However, in such an event, chances are high that all drives in that device fail at once which would also kill every raid.

    Invest the money you would spent on a hardware raid into a "real" PC. USB-powered hard drives might not be the best solution. It can work, but the risk is high, that there will be voltage drops or spikes from the USB controller, which the drive does not like. You do not want your controller to be the cheapest part of your setup (if the data is important)

    1) Automatic backup solution (no one manages to make manual backups as regularly as needed)
    2) Regular backups (depends on your data, hourly/daily)
    2) Use good Hardware to prevent failures (UPS, proper power supply (also USB drives don't like fluctuating power), ensure temperature being in recommended range..)
    3) Monitor your system/hardware (SMART) to detect aging before the drive fails

    This problem has to be solved by the owners of You could leave them a message.

    You have two options:
    1) Workaround: apt-get -o Acquire::Check-Valid-Until=false update
    2) Switch to a different mirror
    Have a look at, choose one of the primary mirrors. You can ping them first and see which one is the closest to you. Anyway, every mirror from europe should be good for you. Probably you wont't experience a difference if you use a US one..

    The packages are the same, no matter in which country the mirror is, if that was the question

    Yes, but not via the web interface (there is no plugin). Note that OMV uses nginx, and most web interfaces require apache.
    I would suggest the installation of docker and then use the docker package of the software you like (SVN or GIT server).

    Die svdrphosts.conf habe ich bereits angepasst. (Falls das überhaupt notwendig ist)

    Das Anpassen sollte notwendig sein (wobei ich nicht weiß, was das OMV-Plugin evtl setzt).
    Da sollte also sowas wie "" entsprechend für dein subnetz stehen.

    Hast du den VDR nach der Änderung neu gestartet? Steht in den Logs was? Was sagt "vdr --version"

    Wenn ich dies eingebe kommt folgende Meldung:

    Last login: Sun Oct 15 20:31:11 on ttys000
    Didi-iMac-3:~ Didi$ ssh root@
    ssh: connect to host port 22: Connection refused
    Didi-iMac-3:~ Didi$

    Die Fehlermeldung bedeutet, dass auf deinem NAS kein SSH server auf Port 22 läuft, oder dass der root login nicht erlaubt ist. Das kann mehrere Ursachen haben. Bitte überprüfen:

    - Die IP stimmt
    - SSH ist aktiviert (im Webgui: Dienste -> SSH)
    - Root login ist aktiviert (gleiche Seite)

    Nach dem starten von SSh und/oder dem aktivieren des Root logins, müsstest du dich einloggen können. Das Passwort wäre halt noch wichtig, kennst du aber hoffentlich ;) (evtl mal mit dem gleichen wie fürs Webinterface probieren)

    Wie donh geschrieben hat: Tastatur und Monitor dran, und da einloggen (Benutzername "root" und dein Passwort. Achtung, bei Linux wird bei Eingabe des Passwortes nichts (keine Sternchen) angezeigt)

    Sorry, I had a typo in there. The apt-source file should have the extension .list
    you can correct this by

    mv /etc/apt/sources.list.d/tvheadend /etc/apt/sources.list.d/tvheadend.list

    However, you installed the Jessie version of tvheadend which is 4.0.9 If you are fine with that, leave it. The other repo should install you version 4.1.

    As I don't have nor use tvheadend I can't help you with your problem. Maybe ask directly the tvheadend guys?

    And (old) guide: Tvheadend Setup and Config

    In command line this would be:

    apt-key adv --keyserver hkp:// --recv-keys 379CE192D401AB61
    echo "deb jessie stable" >> /etc/apt/sources.list.d/tvheadend.list
    apt-get update
    apt-get install tvheadend

    But I'm sure this can be done in the webgui and this is probably the way you want to go, if you are looking for a "newbie guide".

    Why not only use VPN? After you VPN'ed, you can connect to any other port of your OMV via local network.
    It's anyway a bad idea to open your OMV-Web to the public.


    I have remote access to my router even without being connected to the VPN

    However, that idea is even worse.

    What you should do:
    1) Port forwarding from 443 of your router to your OMV-VPN port (probably 1194)
    2) Close all other ports.
    Then connect via VPN Port 443 to your local network. If necessary, do a local (LAN) connection to OMV and Router interface.

    Reinstall is the easiest and safest option. However, you can try:…ar-ownership-permissions/

    Slow way:
    Reinstall all Packages, will redo permissions:
    dpkg --get-selections \* | awk '{print $1}' | xargs -l1 aptitude reinstall

    Do the dpkg/apt way: Download all installed packages (you need space for that), read the permissions and apply that to your files. (called Method 2 in the link above)

    Having a backup is always the best way to restore from stupidity