
中古の Synology NAS DS213j を初期化して、Aliexpressで購入したKingFast激安SATA SSD を搭載、LANポートには以前WDS機能を設定したトラベルルータVIXMINIを繋いでNASのWiFi対応を実現。最新の DSM 7へ手動で アップグレード しました。
1TB SATA SSDを搭載
会社から払い下げを受けたSynology NAS DS213j、HDDは既に取り外されて廃棄処分済なので、以前Aliexpressで購入したKingFast激安SATA 1TB SSDを2基搭載します。
ちなみに、SSDにはTBW(最大総書き込み量)があることから、同じモデルによるRAID構成には不向き(どちらもほぼ同じ時期に寿命に達する恐れ)とも言われますが、用途が家庭レベルのファイル共有であまり気にせずに。
元々3.5″HDDを収めるためのベイなので、2.5″SSDとはネジ穴が合うはずもありません。しかしながら軽量で回転物なども内包していないことから、アセテートテープとクッションフォームで固定すれば十分。
筐体を閉じ、以前セットアップした、有線LANしかないデバイスをWiFi対応させるGL-iNet VIXMINIを繋いで(給電もDS213jのUSBポートから)、NASのWiFi対応は完成です。
設定の初期化
Synology NASの初期化方法はKBが用意されており、今回はその中の「モード2」に沿って進めます。
本体背面のリセットホールボタンを4秒押して、ビープが鳴ったら離し再び長押しするも、記載されているようにビープ音が3回鳴ることはありませんでした。
何度試しても状況は変わらないのでそのまま放置していた折、ふとVIXMINIの OpenWRT管理ページを開くと初期状態で起動したのか、NASがDHCPからIPを貰えているのを確認。

図03.VIXMINI管理画面でIPアドレス発見
Web Assistantで初期設定
ブラウザで判明したIPアドレスの5000番ポート開くと、Web Assitatntが待っていました。
1 |
http://IP_ADDRESS:5000/ |
DSMのインストール方法は、最新のDSMをダウンロードしてインストールを選択。
DiskStationの管理パスワードを設定し、RAIDボリュームの作成にもチェックを入れます。
15分程度でDSMのインストールが終わり、システムが再起動を終えるまで10分待機。
10分後、ページがリフレッシュされると、接続不能と言われてびっくり。
古いNASなので結局、30分以上経った頃にアクセスし直すと、無事にDSMのログイン画面が開きました。
DSM7へのアップグレード
Synologyの10年サポートルールに基づき、2013年発売のDS213jにもぎりぎり、最新のDSM7が利用可能なはずなのですが、この時点ではまだDSM6.2.3でした。
Synologyダウンロードセンタによると、DSMのアップグレードのステップはいきなり最新(執筆時最新はv7.1.1U5)ではなく、まずv7.0.1を入れる必要があるとのこと。
サイトよりこの7.0.1-42218をダウンロードして、DSMコントロールパネルのDSM更新から、手動で更新します。
1 |
DSM_DS213j_42218.pat 323,543,040 byte |
今回は10分以内でアップグレードは終わったようで、DSM7の新しい画面になりました。
ここからはいつものDSM更新で最新のv7.1.1U5まで更新することができます。
不要なパッケージの削除
デフォルトで入っているパッケージのうち、次の2つをアンインストールしました。
- DHCP Server
- OAuth Service
他にもいくつか不要なのがあるものの、アンインストール出来ずに断念。
SSDではHDDハイバネーションを無効に
デフォルトでは有効になっているHDDハイバネーションは、SSDでは必ず「なし」にしておかないと、
スリープからの復帰時にモタモタすることがあり、即警告扱いになってしまい、警告解除に苦労することになります。
こちらのフォーラムを参考に、ログを収めたDBを直接触ってクリアしました。
1 2 |
$ sudo sqlite3 /var/log/synolog/.SYNODISKDB $ DELETE FROM logs WHERE serial ='[drive S/N]'; # replace the fields without the square brackets |
SMB共有の基本設定
ネットワーク上のWindows PC向けに、小規模のSMBファイル共有を作成します。
管理アカウントとは別にこのファイル共有専用の別ユーザを作成して、SMBファイル共有への読み書き権限を付与しました。
別のNASからrsyncで所有権を換えながらデータ移行
最後に、ファイル共有に入れるファイルを別のNASから rsync を使ってデータ移行してみたところ、当たり前ですが rsync を admin で実行したので、コピー先のファイル所有者は admin になります。
1 2 3 4 5 6 |
admin@NAS08:~$ rsync -avz --delete admin@######:/volume1/Share/ /volume1/Share/ admin@NAS08:~$ ls -l /volume1/Share/ drwxrwxrwx+ 2 admin users 4096 May 19 11:57 アルバム drwxrwxrwx+ 2 admin users 4096 May 19 11:57 マニュアル drwxrwxrwx+ 2 admin users 4096 May 19 11:57 マイナンバー drwxrwxrwx+ 2 admin users 4096 May 19 11:57 スキャントレイ |
せっかくファイル共有用のユーザを作ったので、ここは rsync の --chown オプションを使い、所有者を fileuser に換えながらコピーしてみました。
1 2 3 4 5 6 |
root@NAS08:~# rsync -avz --delete --chown fileuser:users admin@######:/volume1/Share/ /volume1/Share/ admin@NAS08:~$ ls - /volume1/Share/ drwxrwxrwx+ 2 fileuser users 4096 May 19 21:19 アルバム drwxrwxrwx+ 2 fileuser users 4096 May 19 21:19 マニュアル drwxrwxrwx+ 2 fileuser users 4096 May 19 21:19 マイナンバー drwxrwxrwx+ 2 fileuser users 4096 May 19 21:19 スキャントレイ |
このオプションはよく -og --chown とセットになっている使用例を見掛けますが、既に -a ( --archive )が使われていれば -og なくとも --chown オプションは機能するそうです。
なお、 chown は本来 root ユーザでしか許されないため、 rsync の --chown オプションも admin では機能しないことに注意。
1 |
chown: changing ownership of '/volume1/Share/アルバム': Operation not permitted |
タスクスケジューラに登録して繰り返し実行する場合は、タスクの実行ユーザを root にする他、 admin ではなく root のssh鍵を相手へ登録しておく必要があります。