Idea: Obvious - build a NAS for centralized sync and backup.
Easier said than done.
Hardware, very nonpro, as I didn't want to spend hugely for SOHO solution...
MB: H110I-plus D3
CPU: Pentium
Memory: 16GB non-ecc,
OS: on 16GB USB stick,
HDD: WD red NASware, 4x2TB,
Ethernet: onboard realtek 8111H (and additional Intel NIC for some lagging),
Case: Bitfenix' Phenom (real nice, heavy metal, no bending, easy hdd-selves, good layout).
Build went quite smoothly - with one hickup: (small) cpu-cooler I bought was still a bit wide for cramped ITX. Intel stock cooler it was, then.
OP-system
Note: I am total noob in both NAS and BSD - the following AAR is therefore kinda simplistic, erratic and occasionally silly.
There were some reasons for not picking Linux - like I wanted to try BSD, and I didn't find satisfactory Linux-solution (whatever that means).
I started with current Nas4free. It installed nicely from usb to usb, booted (not very fast) ... and didn't have usable network driver. And I am talking - maybe - about a month of waiting, as freebsd 10.3 (with proper driver) is already released, but nas4free base is still 10.2 ... But I didn't feel like waiting and/or compiling patched driver in jail etc:
Freenas 9.10 (freebsd kernel 10.3) got downloaded, dd-d, installed, and it booted (a bit faster) with realtek support.
Install was uneventful - and went very much according to manual.
Then I shut down, connected HDDs to motherboard and rebooted.
And discovered the one problem with this install - new intel H110 chipset doesn't want to boot USB-system. Fortunately, the motherboards' bios has 'force boot from usb' option. So, F2 every time, and monitor+keyboard have to be close... Irritating, but survivable. Solution would be to use small SSD for system - but then we loose one SATA port (and PCIe sdd-s are sillily expencive).
When adding such a - well, revolutionary - part to old, self-accumulated home network, it's also good time to check the old shit over. My oldest is an AMD X3 from 8 years past. And not to forget switches... I did check - and replaced one 10/100 switch and added one 1000 NIC to old AMD-box. No need to leave bottlenecks in new shiny installation.
As hardware building was easy and installing a tiny bit less so, then the following was quite frustrating and enormously time-google-wasting.
Configuration
# System
Now - it's possible to do quite a lot from webGUI, remotely. Still, there are some things which are better by console. So, one has to know at least some bsd commands and syntax (default csh is not unavoidable - bash is also installed).
WebGUI is big - so I am not going to blab of it. Read the same aforementioned manual. It's comprehensive. Not reciting manual goes also for text below.
I confed System first, then Storage (created volume and datasets), then user accounts. I planned to use both NFS and CIFS/Samba (afterthought - in mixed systems, maybe it's easier to stick with one - Samba). NFS - seems - wants your owner-user to have the same ID and GID as in client machine, which can be quite tiresome to achieve. If you have several differently dedicated datasets, then you probably also have to play around with groups - to give your users access to different places.
Also, NFS and some Windowses have relation-problems (win7pro doesn't recognize NFS natively, for example).
Next, Network, then Services (in my case: cifs, nfs, rsync and smart for starters) and then Sharing. The last one is absolutely essential - sharing opens datasets up for remote access. Among other conf options - here it's possible to close sharing(s) down for only LAN access, and/or for specific IPs.
This made me reorganize some of my boxes' IPs from dynamic to static - additional small hassle.
# CIFS/Samba
1. Additionally to (relatively simple) setting up CIFS service and share in NAS, samba(clients) need to be set up in client-machines. In Win7 it's as simple as connecting to server via explorers' network mapping. In Slackware there has to be - additionally to default-installed samba - valid /etc/samba/samba.conf. Daemon - /etc/rc.d/rc.samba does not need to be started, though.
I used Spacefms' plugin to mount samba shares. Doing it manually looks like this:
sudo smbclient //192.168.1.x/foldername -U username The same can be achievad also with proper entry in /etc/fstab and then, if 'noauto' -
mount /mnt/sambamountpoint.
# NFS
The same here, of course - client-machines have to be able to communicate with nfs-server. As mentioned, there is no satisfactory free solution for Win7Pro. In Slackware (in Antix 15.1 - nothing needs to be done, it works), start rpc daemon:
sudo chmod 755 /etc/rc.d/rc.rpc && /etc/rc.d/rc.rpc start, then, terminal way:
sudo mount -t nfs 192.168.1.x:/mnt/volume/dataset /mnt/mountpointnamefstab way looks something like that:
192.168.1.x:/mnt/volume/dataset /media/mountpointname nfs rw,noauto,noatime,user 0 0 So, afterwards it's only
mount /media/mountpointname. Mount command for this can also be made in Spacefm as a, well, saved 'command'.About confing: As I have couple of users for NFS, then I had to use 'mapall' in NAS' NFS-sharing options. Took me some time to figure that out. Also - I use nfs as passwordless 'guest' domain.
With both - smb and nfs - it's quite a lot of playing with user permissions - especially after in comes 'syncthing'.
# SYNCTHING
... comes with Freenas as an installable plugin-script. Script downloads stuff and installs it to jail. That ends the easy part.
For me, syncthing was the biggest time-waster to configure. It's wiki is not by far as comprehensive as Freenas one; it has bugs, it has quirks.
Still, after I got it running, I quite like it. I stress, though - be very careful, have a backup before experimenting! Syncing means that fucked-up (you, bug, ...) folder can fuck up all other synced folders... For important folders, do check versioning - if worst happens, you can get your shit back from trashcan - .stversions folder will be created when deletion occurs.
Syncthing creates user 'syncthing' (983:983) in jail. This complicates things with perms - some manual chowning needs to be done, myuser (same id-s as in dataset) needs to be created in jail; and syncthing should be member of this user group... Supposedly, it's easier to change 'syncthing' to have the same id/gid as main owner of dataset. This requires changing of conf: /var/db/syncthing/config.xml, otherways - console-based changes will be overwritten by GUI.
When creating datasets and connecting them to syncthing (can be quite time-consuming anyway)- avoid mistakes and renaming datasets, changes afterwards seems to drive syncthing totally bonkers.
In GUI, everything is reasonably clear: pick your folders, apply various options, sync. Yeah, right - but it took me 4 evenings to get all perms between win/linux/nas/syncthing correct. Syncthing forum, though, gives some nice advice about various obstacles.
And last - which should be the first - thing: Make plan/schema what and how to sync. I mean, really plan - as some changes are shit to do and, can fuck up good part of your already confed syncing.
This means: organizing location and naming of folders; which of synced folders is the master, how many boxes are going to access this dataset, how data really flows (do you really need to install one more syncthing, or maybe flow is one-directional - and rsync is enough) and so on ...
Moral: Syncthing is nice thing - if and when you get it smoothly running. To get it there might be enormous wrangling, though. I presume that some sysadmin experience before is certainly helpful...
And general moral: NAS is nice thing to have, and Freenas as its' op-system looks perfect to me.
