2008-01-20

I got a QNAP

Filed under: Geekiness — iain @ 13:12:44

I bought a QNAP TS-209 Pro NAS in the hope of reducing the load on my fileserver a little bit. The TS-209 comes with a bunch of features (though I won’t use many of these) including, notably, NFS and CIFS support. Sadly, the latter was the one thing which didn’t work perfectly first time, as everything else on this very nice little unit did. I was given the option of participating in a Windows Workgroup or joining an Active Directory domain but there was no option to do an RPC join. This is a problem as my domain controller is the aforementioned fileserver.

Not to worry, though. One of my reasons for buying this particular unit was that it is an embedded Linux system with SSH access. Let’s have a look inside.

    [~] # find /etc -name smb.conf
    /etc/smb.conf
    /etc/default_config/smb.conf

So if I edit the smb.conf and configure the domain I should be able to join it.

    [~] # net join
    -sh: net: command not found

Ah. Where’s Samba?

    [~] # ps waux | grep smbd
     1020 admin      2920 S   /usr/local/samba/sbin/smbd -D

Let’s try this then.

    [~] # /usr/local/samba/bin/net join
    Joined domain CAMBRIDGE.

Great! But there’s one problem. Without knowledge of my LDAP accounts the QNAP won’t be able to assign consistent UIDs to Samba connections and there’s no nss_ldap installed. Let’s poke some more.

Although the guts of the TS-209 comprise an embedded distribution, the device ships with a basic install of Debian Etch on /share/MD0_DATA/etch. If we chroot into it we should be able to install the LDAP libraries.

    [~] # chroot /share/MD0_DATA/etch
    [~] # apt-get update
    ...
    [~] # apt-get install libnss-ldap

Unfortunately the C libraries used by the Etch install and the embedded OS outside the chroot don’t match so I couldn’t just use the new libnss_ldap.so.2. So how about I disable Samba from the QNAP web interface and apt-get Samba inside the chroot?

There’s one more hurdle. The QNAP puts shares you create under /share/MD0_DATA which is outside the chroot. A bind mount fixes this.

    [~] # mkdir -p /share/MD0_DATA/export/home
    [~] # mount -o bind /share/MD0_DATA/home /share/MD0_DATA/export/home

Samba inside the chroot can be configured to share out /export/home.

This is all very well except Samba won’t start on reboot because the Etch init scripts won’t be run. Some investigation revealed that the QNAP runs two sets of startup scripts stored inside the chroot.

  1. Scripts in /share/MD0_DATA/etch/ext/extchroot-bin are run outside the chroot.

  2. Scripts in /share/MD0_DATA/etch/ext/bin are then run inside the chroot.

So the solution is very simple.

/share/MD0_DATA/etch/ext/extchroot-bin/S00-export.sh:

    #!/bin/sh
    DATA=/share/MD0_DATA
    EXPORT=$DATA/etch/export
    
    for share in home files smb; do
      mkdir -p $EXPORT/$share
      mount -o bind $DATA/$share $EXPORT/$share
    done

/share/MD0_DATA/etch/ext/bin/020-services.sh:

    #!/bin/sh
    /etc/init.d/samba start

7 Comments »

  1. Impressive! I’ve got a TS-209 Pro of my own and inspired by your text I tried the chroot and apt-get part for installing cfv. As a Linux newbie I got confused by the second half of your post however. I would like to use cfv to work on my files in /share/MD0_DATA/Qmultimedia, which is outside the chroot. And cfv doesn’t seem to work from the real root. Could you please help me out on this one? And why would they create a “double” system like this (real root vs. chroot systems)?

    Comment by jofafrazze — 2008-02-26 @ 23:57:01

  2. You would need to add it to the export script:

        for share in Qmultimedia home files smb; do
        ...

    The key line is the bind mount:

        mount -o bind <oldpath> <newpath>

    This is mounting the same thing in two places. Since the script runs outside the chroot it would end up mounting Qmultimedia inside it where you can access it.

    The reason cfv won’t work (and the reason why I had to install my own Samba) is also the reason why they have the double system. The core NAS stuff (kernel, NFS service, limited CIFS service) are built to be as small and fast as possible while maintaining a whole Linux distribution on the much larger storage where you can install pretty much everything you want. And you can break it, too, without affecting the running of the system.

    Comment by iain — 2008-02-27 @ 15:14:30

  3. Hi there Iain,

    I am interested in one of QNAP Products. The qnap 409 ts pro for my company. However we are concerned about the fact that probably it wouldn’t satisfy one of our needs. We need a NAS-Server fully compatible with our Domain (Samba3 running in one of our Linux servers with a LDAP backend for storing users and its attributes) to act as a client and therefore allowing users to access shares on the NAS server.
    We do not have Active Directory (Windows Server Domain).

    Best Regards,

    Comment by inspire — 2008-02-28 @ 16:52:32

  4. I had the Samba setup that I installed in the chroot working as you describe. Eventually I decided it would be easier just to make it a domain controller but still pulling the LDAP data from a separate machine.

    If you don’t care about UID mapping the QNAP will work out of the box[1] as the Samba outside the chroot has LDAP support compiled in. I wanted UID mapping to work consistently with NFS, however, so I was forced to install Samba in the chroot as in my post.

    [1] Well maybe not really out of the box. The QNAP web interface won’t allow you to set this up but if you know your way around smb.conf you can do it yourself.

    Comment by iain — 2008-02-28 @ 17:03:59

  5. We basically need that QNAP NAS could “recognize” the domain accounts (users, groups, etc.) of our PDC (SAMBA+LDAP running on a Fedora Box) with windows/linux/mac clients. I am a little confused right now on what I’ve to do after we bought the QNAP TS 409.

    Comment by inspire — 2008-02-28 @ 18:15:59

  6. Thanks for the reply Iain,

    now it makes sense with the double system. It turned out that someone/something had mounted the Qmultimedia inside th chroot’s /ext already (The SlimServer installation I suppose).

    Comment by jofafrazze — 2008-03-03 @ 19:23:23

  7. For the Samba thing, as I mentioned before the QNAP will live in the domain quite happily if you don’t care about preserving UIDs (which you would if you were also mounting the shares over NFS). You would edit /etc/smb.conf (outside the chroot) in the same way as any other Linux machine on the network and use /usr/local/samba/bin/net join to join the domain.

    If you do care about UIDs (as I did) you would need to follow the rest of the steps I did above, remembering to disable Samba from the QNAP web interface so the "wrong" smbd isn’t restarted. And in this case too you configure smb.conf (inside the chroot) in the same way you usually would for another Linux machine.

    Comment by iain — 2008-03-04 @ 20:38:01

RSS feed for comments on this post.

Leave a comment

You must be logged in to post a comment.

Powered by WordPress