FreeLink for the LinkStation PRO/LIVE

From NAS-Central Buffalo - The Linkstation Wiki
Revision as of 02:42, 29 October 2007 by Duncan h (Talk | contribs)

Jump to: navigation, search

The original (old hardware) model LinkStation PRO and LIVE appear to share the same hardware, but came with different firmware. Recently, a new model (new hardware) has appeared: again, the new versions of the PRO and LIVE appear identical, but differ from the older versions. The Freelink installation procedures for old and new hardware are different. There are now four variations: old/new and PRO/LIVE.

Nuvola apps important.png 

IMPORTANT! Identify your hardware version from the picture below! New PRO and LIVE LinkStations have a modified hardware (v2), and will be bricked if the U-Boot bootloader (BOOT) is replaced by using the procedure designed for the older (v1) hardware.


To determine whether you have the OLD (v1) or NEW (v2) hardware, compare the following rear-view images (of LS LIVE, but valid also for LS PRO) - note the position of the power cable socket (at top in new hardware, at side in old):

    Linkstation live1 rear.jpg Linkstation live2 rear.jpg



    Please read the README.1st file included with this Freelink release.

    How to use the Buffalo updater LSUpdater.exe

    You will have to use the Buffalo-supplied windows program LSUpdater.exe, running on Windows (or maybe WINE under Linux). This comes in separate versions for the LS PRO and LS LIVE. The Freelink package contains an older LS PRO version not suitable for new hardware. Unless you are installing Freelink on an old-hardware (v1) LS PRO, you will need to use LSUpdater.exe from a buffalo firmware package for your type of ARM-9-based Linkstation (PRO or LIVE). You will also need its files lsupdater.ini and linkstation_version.txt .(You may need to edit linkstation_version.txt to increase the version numbers of the various components listed, so they are higher than the actual Buffalo versions installed on the LinkStation; this is just to fool LSUpdater that the update really is an update, otherwise it won't get applied).

    To Access the Debug Menu

    Start lsupdater.exe, then

    1. Right-click the "Buffalo Updater Icon" on the Windows context-bar (the bar at the bottom of the screen that spans between the start menu and the clock).
    2. Select "Debug(D)..." and the Debug Mode menu will pop up.

    If you are using the lsupdater as supplied in Buffalo's own firmware packages (e.g., if you are installing FreeLink firmware on the LS LIVE, as described below), you will not see the Debug(D) option until you have modified the file lsupdater.ini (found in the same directory as lsupdater.exe): open lsupdater.ini with a text editor, and add the following lines:

    Debug = 1

    You should also change

    VersionCheck = 1


    VersionCheck = 0

    Normally lsupdater does not detect a LinkStation which already running the firmware revision that came with the updater (this is specified in the file linkstation_version.txt); setting the flag VersionCheck=0 disables this behavior.

    How to use the Firmware Updater with Wine

    Linux users can also use the lsupdater.exe with wine: just make sure you have the Graphics setting for the Wine windows manager to control the window unchecked "Allow the window manager to control the windows" so you will be able to enter debug mode.

    Wine Configuration

    Installation on V1 (OLD hardware) LS PRO using LSUpdater

    Initrd-Only Installation:

    (This step is NOT for NEW-version hardware, ONLY for OLD-version hardware.)

    Important: Users that have not installed a lb_worm's custom initrd or firmwares containing lb_worm's custom initrd must install the "initrd-only" package before installing FreeLink. Failure to do so may result in a failed install or a bricked old-hardware-version box. The initrd-only package is included in the FreeLink package. Use the updater found in the initrd-only folder to install the initrd-only package (for Live, use Live version of LSUpdater.exe and LSUpdater.ini, see below).

    Warning Notices: When installing the initrd-only package, there will be an error saying "hddrootfs.img not found", "uImage.buffalo not found". That is expected as we are only updating initrd. The errors can be overridden by using the "Debug Mode" for the Buffalo Updater.

    1. Right click on the Buffalo Updater icon in the Windows takbar. If lsupdater.ini has been edited as described above to allow Debug mode to be activated, you will see a choice Debug(D): select it.
    1. In the upper left-hand corner of the menu is an "Update" section. Deselect everything in that section except "Update initrd" and hit "ok".
    2. Then update as usual.

    FreeLink Installation

    Update BOOT skipped

    Users may install FreeLink by using the buffalo updater supplied with the FreeLink package. The FreeLink firmware will be installed in the same manner as the stock firmware except you will skip installing boot (u-boot bootloader) as there is different versions of u-boot.

    • Please use a wired-ethernet connection to install FreeLink. Wireless-ethernet connections are known to cause problems.
    • Follow instructions above to use Debug mode. In Debug mode, uncheck Update BOOT as one of the Update options.
    • Ignore the "Waited for 240[s] seconds but couldn't confirm..." message at the end of the update and click "No" when the updater asks whether it should wait again for a response.
    • Also ignore any error messages afterwards. The error messages are cause by the fact that FreeLink does not contain the Buffalo Updater Daemon.

    ACP_STATE_FAILURE error??:

    If you receive the ACP_STATE_FAILURE error message, that means that the /boot partition of the hard drive is filled to capacity. The easiest way to resolve this is with Georg's ACP Commander:

    Enter the following (Replacing <IP ADDRESS> with the IP Address of your Linkstation)

     java -jar acp_commander.jar -t <IP ADDRESS> -cb

    This will clear the boot partition, and now you can retry the firmware update, hopefully with success.

    Installation on V1 (OLD hardware) LS LIVE using LSUpdater

    (old v1 hardware) LS Live (HS-DHGL): Please follow the same procedure as for old hardware LS PRO, except that you must first replace the LS PRO version of the LSUpdater that is supplied with the FreeLink distribution with the LS LIVE version of LSUpdater.exe and LSUpdater.ini, These are in the firmware for the LS LIVE which can be downloaded from Buffalo site (it's inside 1.03 or 2.03 firmware for LinkStation Live).

    You will have to modify the LSUpdater.ini file as described above to allow Debug mode to be activated, and to suppress firmware version checking.

    Installation on V2 (NEW hardware) LS PRO using LSUpdater

    Only the 1.10 and 1.11 firmware is available for the (new hardware) LS PRO at or

    (There is no "1.06" firmware for the PRO that resembles the 2.06 firmware for the LS LIVE).

    According to a procedure reported in the forum by LS Pro user ado, for 1.10 or 1.11 LSPRO firmware on new hardware, (and confirmed to work by others) what you must do is:

     1.  Download FreeLink_arm9-1.0rev2
     2.  Use LSUpdater.exe (any version, within stock firmware 1.10 or 1.11, 
         or within FreeLink_arm9-1.0rev2) (in Debug mode) 
         Flash the Linkstation with FreeLink firmware as follows:    
                Start LSUpdater, and enter Debug mode, as described above:
                On the left Debug panel of the Debug mode window, select the boxes for 
                 KERNEL,initrd and rootfs             
               (all of these will be taken from FreeLink_arm9-1.0rev2) ,
                but DO NOT SELECT BOOT . 
                On the right panel, check "Do not check version", and "force update".
        Important: make sure the checkbox for BOOT is NOT checked: 
        leaving "update BOOT" checked when flashing  WILL brick your new-hardware LinkStation 
       (by replacing the u-boot bootloader with an older one incompatible with new hardware))
        Suggestion: As an extra precaution against mistakes, delete the FreeLink file 
        u-boot.buffalo.updated which contains the incompatible bootloader (or replace it 
        with u-boot.buffalo.updated from the stock firmware package(1.10 or 1.11) corresponding
        to the firmware version you are running.

    UNCHECK "Update BOOT" on Debug window

     3. The initial reboot of the Linkstation will fail.  To fix this, you now need to get 
        into EM mode, which will happen after three failed attempts to boot.  
        Each time the LinkStation boots, it will check 3 things to decide whether to boot 
        into EM mode:
          (i)  Does a file /etc/hddrootmode  exist?
         (ii)  Does a file /etc/rootfs_ok  exist?
        (iii)  Is the version information in the file /boot/linkstation_release  too old?
        After you have installed FreeLink and the LinkStation has failed to boot 3 times, 
        since the LinkStation has not found  a file /etc/rootfs_ok, 
        and three failed boot attempts are recorded in /etc/rootfs_booting, the next 
        boot will boot the LinkStation into EM mode.
        When your LinkStation is running in EM mode, you can use acp_commander  
        ("java -jar acp_commander.jar -t <IP ADDRESS> -cb") to remove the root password and 
        start the telnet service.  Then telnet to the LinkStation and login as root 
        (no password).   
       Once you are logged in as root in EM mode, modify the script in /etc/init.d/miconapl from
     ## Use same files as linuxrc
     ## Update the filesystem okay flag
     date > $ROOTFS_OK
     ## delete booting file
     rm -f $ROOTFS_BOOTING
     rm -f $INITRDMODE
     ## Use same files as linuxrc
     ## Update the filesystem okay flag
     date > $ROOTFS_OK
     ## delete booting file
     rm -f $ROOTFS_BOOTING
     rm -f $INITRDMODE
     ##modified to resolve initial freelink boot into EM mode (v2 hardware)
     date > $ETC_ROOTFS_OK
     rm -f  $ETC_ROOTFS_BOOTING  
     rm -f  $ETC_INITRDMODE 
     (The modifications above are shown in red).  
     Now reboot again, the modifications you made will get you out of EM mode.
     After this final boot, you should have a working LinkStation PRO running FreeLink.

    This procedure is reported to work starting with both 1.10 and 1.11 LSPRO firmware on the new hardware LS PRO.

    DO NOT TRY TO FLASH BACK TO 1.03 FIRMWARE, this will brick the (new hardware) LS PRO because the 1.03 bootloader does not support new hardware.

    Check the discussion in the forum about LS PRO new hardware. Successful FreeLink installations of new hardware LS PRO have been reported.

    Installation on V2 (NEW hardware) LS LIVE (running 2.06 Buffalo firmware) using LSUpdater

    If you have already updated the LS LIVE Buffalo firmware to v2.10 firmware (uses 2.6.16 Linux kernel) I suggest you first flash back to 2.06 (which the new hardware initially came with). This is still available on the Buffalo UK site . The file is called You will have to edit the file linkstation_version.txt to increase all the listed file dates and versions to be more recent than the dates of the 2.10 firmware your are downgrading, to trick LSUpdater.exe intp replacing newer firmware with older firmware. You may also need to activate Debug mode and uncheck "Version Check"

      0.  Start with a LinkStation LIVE running Buffalo 2.06 firmware. (the procedure here
          will probably also work on 2.10 firmware, which has a newer u-boot bootloader; 
          if you have had success, please edit this page to tell us.) 
          (there appear to be success reports in the forum postings).
      1.  Download the FreeLink rev2 distribution.
          Unzip it. Go to the directory FreeLink_arm9-1.0rev2-Live, and 
          immediately delete the file u-boot.buffalo.updated. 
          (This file is POISON to any new-hardware LinkStation,and you do not want 
          any  possibility of accidently flashing it to your nice new LinkStation!).
      2.  (Download the Buffalo 2.06 firmware if you have not already done so.)
           The file is called   Unzip the file, and go to
           the directory with the firmware (it is called HS-DHGL_206_013_us)
      3.  Edit lsupdater.ini (as described above) to allow activation of Debug  mode.   
      4.  Edit linkstation_version.txt as follows:
             VERSION=2.06-0.13              increase version (?)
             BOOT=1.09                      DONT CHANGE
             KERNEL=2007/03/07 11:16:12     make date newer     e.g. KERNEL=2007/10/07 11:16:12
             INITRD=2007/06/12 17:37:02     make date newer     e.g. INITRD=2007/10/12 17:37:02
             ROOTFS=2007/06/12 17:54:57     make date newer     e.g. ROOTFS=2007/10/12 17:54:57
          You are only doing this to trick LSUpdater when it checks that the update is newer
          than the firmware installed on the LinkStation.(It will only install newer firmware)    
         (Perhaps checking the box "force UPDATE" will make this unnecessary?  Maybe only the   
          three dates must be changed?)
          (These dates are only used as a check by LSUpdater to compare with dates encoded
          in the firmware on the LinkStation.  It only matters that they are more recent than
          the firmware that is running at the time you flash, and what you choose for them
          will not be recorded on the LinkStation.)
          You DO NOT WANT TO make it think that there is an updated BootLoader available,
          so leave the BOOT=1.09 field alone.    (If you are running 1.06 FW, the
          BootLoader in  Flash memory should be the 1.09 version anyway, so this 
          should not in principle be dangerous, but .... just leave it alone!)
       5. Delete the three Buffalo files uImage.buffalo, initrd.img and hddrootfs.img
       6. Replace them with the corresponding three FreeLink files uImage.buffalo, 
          initrd.img and hddrootfs.img  from the FreeLink distribution directory            
          FreeLink_arm9-1.0rev2.    Make sure that you have replaced all three files.
       7. Disable all Windows firewalls.  To be safest, you should also disconnect your windows
          computer from the network and connect it directly to the LinkStation with a crossover 
          ethernet cable  (However, I successfully flashed though a router without problems)
          The one important rule is:
           Never use a wireless connection for flashing. 
          Now start LSUpdater, which should find your LinkStation on the network.  
      8.  Once your LSUpdater has found the LinkStation, right click on the Buffalo Update icon
          in the Windows taskbar (usually at the bottom of the screen) and activate Debug(D) mode.  
          In the left panel of the Debug menu, uncheck  the first three items 
          ("update BOOT", "update KERNEL" and "update initrd"), and check the box for 
           "update rootfs".  Then click on "OK" to exit the Debug menu.
             It is apparently very important that "update BOOT" is NOT CHECKED (to avoid 
              bricking your new-hardware version LinkStation), though since the version             
            of the bootloader in u-boot.buffalo.updated is presumably the same as the one in 
             your LinkStation right now, it is probably not dangerous.  
             What is dangerous is leaving "update boot" checked if the u-boot.buffalo.updated 
             in the working directory is an older version that does not support new hardware....  
           (I do not know why one should also uncheck "update KERNEL" and "update initrd",
           as in this flash we will in fact update KERNEL and initrd.    The procedure works 
           with these boxes unchecked. I don't understood why. It has been suggested that
           it only makes a difference if something goes wrong during the update, and you go 
           into EM mode) 
               O update BOOT        <----NOT CHECKED
               O update KERNEL      <----NOT CHECKED
               O update initrd      <----NOT CHECKED
               X update rootfs      <----CHECKED

    Debug window

       9.The "moment of truth" has arrived!! To continue, click on "Update" in the LSUpdater menu.
    Whatever else you do, NEVER  do anything that could flash the Bootloader
    of a new-hardware Linkstation with an older version  of u-boot.buffalo.updated 
    (like the   one that came with FreeLink )unless Debug mode with "update BOOT" 
    NOT CHECKED is used:
    (You WILL brick a new-hardware LinkStation if you replace its U-boot bootloader 
    using an incompatible u-boot..buffalo.updated designed for the old hardware.)

    When the LinkStation reboots, it will be running Freelink, and the LSUpdater will no longer find it.

      Do not be alarmed when the Linkstation eventually reboots (and makes the rebooting 
      chime noises), but LSUpdater reports that it is still waiting for the LinkStation to  
      respond.(You can ping your Linkstation at the IP address shown in the LSUpdater panel 
      to verify that it is alive, and booted).  Ignore the "Waited for 240[s] seconds but 
      couldn't confirm..." message at the end of the update and click "No" 
      when the updater asks whether it should wait again for a response. 

    What to do after FreeLink is installed

    Now that your LinkStation has successfully rebooted, there are some further tasks to do.


    Find your LinkStation on the network and open up an SSH session to it. In windows PuTTY is a good client

    • login:root
    • password: lspro


    • login:admin
    • password: admin
      Please NOTE that if the linkstation re-starts itself 3 times then it goes into EM mode 

    and therefore you will need to re-start it again before you can proceed. otherwise you may think that the process hasnt worked.

    You should then see the following welcome screen:

             _sudZUZ#Z#XZo=_         DDDD   EEEEEE BBBB   IIIIII  AAAA   NN   NN
          _jmZZ2!!~---~!!X##wa       DD DD  EE     BB BB    II   AA  AA  NNN  NN
       .<wdP~~            -!YZL,     DD  DD EEEEE  BBBBB    II   AAAAAA  NNNN NN
      .mX2'       _%aaa__     XZ[.   DD DD  EE     BB  BB   II   AA  AA  NN NNNN
      oZ[      _jdXY!~?S#wa   ]Xb;   DDDD   EEEEEE BBBBB  IIIIII AA  AA  NN   NN
     _#e'     .]X2(     ~Xw|  )XXc 
    .2Z`      ]X[.       xY|  ]oZ(   Linux Version
    .2#;      )3k;     _s!~   jXf`   Compiled #2 Thu Feb 8 15:00:20 JST 2007
     1Z>      -]Xb/    ~    __#2(    One ARM ARM926EJ-Sid(wb) rev 0 (v5l) Processor, 128M RAM
     -Zo;       +!4ZwaaaauZZXY'      266.24 Bogomips Total
      *#[,        ~-?!!!!!!-~        LS-GL7D6
    BUFFALO INC. LinkStation series LS-GL(IESADA)

    Cleanup / Fixes

    Unfortunately there are some small issues with the ARM9-1.0rev2 release, but these are easy to fix. Some of the following changes are mandatory and are marked accordingly.

    Don't forget to check out the Debian articles.

    Emergency backdoor

    For safety and also to provide a 'back-door' entry in the event of a problem, edit the file /usr/local/bin/ and add the following lines to the file:

    rm -f /etc/hddrootmode
    rm -f /boot/hddrootmode

    Fix hostname and /etc/hosts (mandatory)

    Edit /etc/hostname to set your LinkStation Hostname, and make sure /etc/hosts is correct. The default Buffalo hostnames are LS-GLXXX (Pro) or HS-DHGLXXX (Live) where XXX are the last three characters of the MAC address (LS-GL7D6 is the default hostname of the system the FreeLink distribution was developed on). You will find the MAC address on a label on the bottom of the LinkStation.

    You must also make sure that /etc/hosts contains the alias "localhost" for, i.e., a line:  localhost.localdomain localhost

    or  localhost.localdomain localhost $HOSTNAME

    where $HOSTNAME is what you put in /etc/hostname (if the alias localhost is missing, the scripts /etc/init.d/kernel-server-nfs and /etc/init.d/openbsd-inetd will not work properly, because they call rpcinfo -u localhost .... . A consequence is that nfs v3 gets disabled, and you unexpectedly only get nfs v2 which has limits on file sizes when files are transferred.)

    See the Debian Manual for more details about /etc/hostname (e.g. domain is set via /etc/resolv.conf).

    Activating your changed hostname without rebooting:

    hostname --file /etc/hostname

    Allow root login on serial console (if you use it)

    root login on console is blocked if /etc/securetty is world-writable

    chmod 0744 /etc/securetty

    Fix kernelmon script (mandatory check)

    There can be an issue with the kernelmon script, that may cause a significant amount of system resources being used and/or having a non-working shutdown button.
    This issue mostly occurs when using a newer Linux kernel from Buffalo (e.g from 2.10 Stock FW).

    To find out if the kernelmon script is eating up your NAS performance, call "top" and check if the kernelmon script is always at the top of the list with a high CPU load. Normally the script has a CPU usage of 0%.

    To determine whether you can fix it, compare the output of "ls /proc/buffalo" and "ls /proc/driver".
    If the subdirectory kernevnt is in /proc/buffalo, make this change; if it is in /proc/driver, do not. (Without it, things like the shutdown button might not work.)
    This is to ensure that the micon interrupt device is pointing to the correct location in the /proc virtual filesystem that is created by the kernel when it is running.

    To fix the script do the following:

    • look in the file /usr/local/sbin/kernelmon script: find a line containing "cat /proc/driver/kernevnt", and change it to "cat /proc/buffalo/kernevnt".

    The buffalo kernel (the 2.06 LSLIVE firmware and the Freelink-supplied kernel) uses /proc/driver/kernevent while the kernel (the 2.10 LSLIVE firmware) uses /proc/buffalo/kernevent

    • if you needed to make this change, reboot your NAS for the change to take effect

    Setting timezone (mandatory check)

    To get the correct times for your files and schedules you have to set the correct timezone for the system and the users.

    a) for the system in general

    dpkg-reconfigure tzdata  # otherwise use tzconfig, which is deprecated

    b) for the user (e.g. root, admin, etc.)

    # then copy/add the given line to the user's .profile in his home directory (e.g. TZ='Europe/Berlin'; export TZ)
    # if .profile is not available for the user, then just create it (check permissions afterwards)

    c) UTC check

    grep -e 'UTC' /etc/default/rcS

    It should say "UTC=yes" which is the default for Linux/Unix.

    Only reason to set it to "UTC=no" is if your machine is running Linux/Unix and a non-UTC-based system (non-UTC-based = local time based). For instance Windows defaults to local time rather than UTC. So if you either use these systems separately side-by-side or via a virtual machine (e.g. Debian on Windows), then "UTC=no" will help having the correct time in both systems.

    Update of the Debian repository and packages

    You can update your system with APT.

    It is recommended, even by the Debian maintainers, to use APTITUDE instead of APT-GET, as it keeps track of automatically installed packages and does smarter and safer decisions when upgrading to a new release. Keep in mind that whenever you are told to use apt-get for maintaining packages, that you replace it with aptitude.

    Note as the current UDEV package requires a higher kernel than the kernel of Freelink ARM9 1.0rev2, the UDEV package should not be updated. Therefore hold the current UDEV package back, to avoid upgrades of it.

    Holding back for aptitude:

    aptitude hold udev

    Another way is dselect of the dpkg-package

    echo -e "udev hold" | dpkg --set-selections
    # When updating you HAVE to use
    # apt-get dselect-upgrade
    # aptitude dselect-upgrade

    A third way would be to pin it via apt.

    To get the latest versions of your installed software, first update the package list and then upgrade the packages.

    As there are some scripts as left overs from the hotplug package inside the Freelink image, just purge the hotplug package before upgrading. (Maybe when the Freelink image was build the hotplug package was only removed and not purged.)

    aptitude update
    aptitude purge hotplug
    aptitude upgrade (or aptitude dselect-upgrade if you choosed dselect)

    If the internet connection does not work, please check your /etc/resolv.conf and your network settings in /etc/network

    If the debian server hangs, you may need to edit /etc/apt/sources.list to change the server, for example from "" to ""

    If you did a fresh install of Freelink ARM9-1.0rev2 you will get the following error message when updating via apt:

    W: There is no public key available for the following key IDs: B5D0C804ADB11277
    W: You may want to run apt-get update to correct these problems

    Then you have to retrieve the public key from the pgp server with this command

    gpg --keyserver --recv-keys B5D0C804ADB11277

    If your behind a firewall, but can access the internet via port 80

    gpg --fetch-keys ""

    Next add it permanently to your root keyring with

    apt-key add /root/.gnupg/pubring.gpg

    You should get an OK message, next retry to update.

    To speed up the process of checking for updated packages, you can easily update apt's repository list with a cron job, which is already prepared by Debian. Just add the following lines to /etc/apt/apt.conf, then your NAS will update the list every morning and you can directly use the upgrade command.

      // Options for /etc/cron.daily/apt
        // same as defining APT::Periodic::xyz
        Update-Package-Lists 1 ;
        Download-Upgradeable-Packages 1 ;
        Autoclean 1 ;

    If the file /etc/apt/apt.conf does not exist, then just create it via the following command and add the lines from above.

    touch /etc/apt/apt.conf

    To undo the holding of UDEV use

    aptitude unhold udev

    or for dpkg's dselect

    echo -e "udev install" | dpkg --set-selections

    Set your Locale

    You may notice when installing from apt or in other situations that there are some errors about not having the correct locale.

    You can fix this with

    aptitude install locales

    This will give you a few choices on what to set for your default locale.

    Static IP address

    You can set up a static IP address instead of DHCP. This is done by editing /etc/network/interfaces.

    If you also want to state your local DNS server (e.g. your router) and local domain, then you can not directly modify /etc/resolv.conf, as Freelink 1.0rev2 comes with the resolvconf package installed. Instead you have to define all DNS data in /etc/network/interfaces for each interface.


    auto lo
    iface lo inet loopback
    auto eth0
    #iface eth0 inet dhcp
    iface eth0 inet static
      dns-domain lan

    NOTE: Do not blindly copy these lines into your file, rather choose the correct IP address and additional information based on your local network settings. If you don't know what these are, then don't modify this file.

    To activate your changes without rebooting:

    invoke-rc.d networking restart

    To see that the change of the domain has occured:

    hostname -f

    For more information about DNS settings via resolvconf see the README file:

    zcat /usr/share/doc/resolvconf/README.gz

    Customized Partitions

    You may not have enough space to install all the Applications you want to. If you have customised partitions, you will have enough space to install other applications (like webmin) Here you can see, how to do this:


    Webmin (webbased administration)

    Look here for instructions on how to install webmin:

    You can reach Webmin via:


    Updating your kernel (not always necessary)

    For users who want to prepare the Linkstation for an updated kernel:

    Securing Your Linkstation

    Limit and/or remove the "guest" account

    Note that the Guest account is a common attack point. This account can be used for system testing, but can be compromised due to default password in a Debian install. Further the Guest account by default in Debian 2.6 is capable of executing BASH scripts allowing system reconfiguration.

    You can simply lock the Guest account ...

    passwd guest -l 

    Change and protect your passwords

    Anyone who can see your NAS on the network can of-course log into it as the root user (=full control!) with the default password, and make it their own.

    Therefore change the passwords for the users root and admin using (as root):

    passwd admin

    Please do not use the same password for both accounts.

    As /etc/passwd and /etc/group must be world-readable the passwords in them can be read and cracked. Therefore it is recommended to turn on shadow passwords, so only user root can see the encrypted passwords.

    pwconv (for user passwords)
    grpconv (for group passwords)

    You should avoid group passwords, as those shared passwords are a typical security breach.

    It is just as important to change the ssh server keys (see section below).

    Limit which users and IPs can have access to SSH and su/sudo

    If you don't want the trouble of using a ssh key pair (see below) then limit the range of IP and users that can have ssh access vis the sshd configuration file /etc/ssh/sshd_config.

    Before your box has an active ssh port open to the internet, initially it is recommended that you basically shut off root access and only allow access via su or sudo for given users. This makes access to the box narrow and root execution via two passwords, via ssh and then su/sudo.

    You can add the following line to /etc/ssh/sshd_config to disable root ssh access.

    PermitRootLogin no 

    ... and then restrict access to su via execution access of /bin/su.

    For sudo - you can restrict user execution access via the sudo configuration file /etc/sudoers.

    Create Unique SSH server keys for your machine

    Due to the way that Freelink is currently installed, you will be using the ssh server keys that are distributed with the freelink archive. As these are publicly available, unless you change these, then your Linkstation will be vulnerable to both "Man-In-The-Middle" attacks - whereby someone impersonates your machine, and passes data along to the real machine (recording, and potentially altering data as they do so), and eaves-dropping (whereby they can decode the encrypted ssh data, as long as they can read the data that is being exchanged between the linkstation, and the machine which they are logging in from).

    rm /etc/ssh/*host*key*
    dpkg-reconfigure openssh-server

    Whereupon you should see:

    Creating SSH2 RSA key; this may take some time ...
    Creating SSH2 DSA key; this may take some time ...
    Restarting OpenBSD Secure Shell server: sshd.

    After this is finished, you can log out, and log back in again. When you try to, you will see a message like:

    $ ssh root@linkstation
    Someone could be eavesdropping on you right now (man-in-the-middle attack)!
    It is also possible that the RSA host key has just been changed.
    The fingerprint for the RSA key sent by the remote host is
    Please contact your system administrator.
    Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
    Offending key in /home/user/.ssh/known_hosts:56
    RSA host key for linkstation has changed and you have requested strict checking.
    Host key verification failed.

    You are seeing this message because you have changed the host key (if someone really was doing a man-in-the-middle attack with the old key, you wouldn't see this message, as they would have the correct key to not-trigger the error report). Remove the old key from your ssh known_hosts file (in this case line 56 of /home/user/.ssh/known_hosts), and log in again... This time it should proceed as normal.

    Your Linkstation is now secure - ideally, you should not have placed the Linkstation on an untrusted network before you reach this stage.

    Link.png This article is currently a stub. You can help this Wiki by expanding it

    . This template will categorize articles that include it into Category:Stubs.