QNAPすべて クチコミ掲示板

Adminユーザーでの不正ログイン試行？プロセスの一部が停止

[魔女宅LOVE♪]

情報共有のための投稿です

今朝、自宅のTS-253D（メモリを8GBに増設・認識、HDDはWD120EFBXを２本RAID1）から管理用メアドに
寝静まっていた午前６時ぴったりから、下記メールが２分間で１００件程度届いていました。
今のところ問題なさそうなので、様子見しています。でもちょっと気持ち悪いですね。

現象前から設定していた内容
・ルータのUPnP設定はオフ、ルータの管理用アカウントのパスワードは複雑化
・QNAPのadminアカウントはパスワードを複雑化した上で、無効化
・QNAPのファイヤーウォール設定は「Include subnets only」（いつの間にか日本語から英語になっていますね…）
・QNAPのcloudに関する設定はオフ

以下、確認した内容

１．Web管理画面に入ると、QNAPのプロセスがいくつか異常停止している兆候
　・セキュリティ設定やダッシュボードを開こうとしても反応なし
　・実行中のバックグラウンドタスクはなし
　・QNAPのウイルススキャンは９５％で停止状態（再開ボタンを押すも動かず）
　・ファームウェアは最新
　・コントロールパネルTOPページのファームウェアやメモリ容量の項目はあるが、内容は空欄
　・同パネルの一般設定→サーバ名が消えていた
　　システムポートも勝手にデフォルトになっていた（以前は任意の四桁の数字を入れていた）
　　タイムゾーンという項目もあるが、右側の設定項目が空白で設定自体できなくなり、「このタイムゾーンは無効です」みたいな表示
　　・NTPの設定も日本のNTPサーバアドレスを入れてテストボタンを押すが、通信できないという表示
　　・adminでのログイン試行は全部失敗に終わっていた（当たり前…）
　　・CPUやメモリの使用量に異常なし
　　・マルウェアチェックするも存在しない（ログにもマルウェア存在なし）

　Web画面からの再起動を試みるも５分程度経過してもアクセスできなくなるだけで、NASのHDDアクセスランプは激しく
　点滅するだけでシャットダウンできない。
　NASの電源ボタンを２秒ほど押すと反応し、数分後にシャットダウン

　念のため、モデムとルーターの双方を５分ほど電源オフ（WAN側のIPアドレスを変更したいため）

　通信機器の復帰後、NASの電源をオン。NAS起動後は上記の変な動作は改善

　今回の原因、QNAPのアンチウイルスソフトが途中でハングアップしたために起きた挙動なのか、不正アクセスの試みがあって
　アンチウイルスがハングアップしたのか、どちらが先かは不明
　ソースIPが「ソースIP：127.0.0.1」というのも、釈然としないです。実際、ファイヤーウォールはブロックしきれてませんし。

　原因がはっきりしないこともあり、NASを外部からアクセスして使うという使い方が、ますます怖くなりますね。

メールの内容
アプリ名: QuLog Center
カテゴリー: 接続状態
メッセージ: [QuLog Center] ログインに失敗しました。ユーザー：admin。ソースIP：127.0.0.1。接続タイプ：HTTP。権限と接続を確認してください。

書込番号：25105460

[ありりん00615]

ログからはアクセス元の判別は付かないようですよ。
https://www.qnap.com/ja-jp/how-to/faq/article/qufirewall-%E3%81%8C-127-0-0-1-localhost-%E3%81%8B%E3%82%89%E3%81%AE%E3%83%91%E3%82%B1%E3%83%83%E3%83%88%E3%82%92%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%81%A8%E3%81%AF%E3%81%A9%E3%81%86%E3%81%84%E3%81%86%E6%84%8F%E5%91%B3%E3%81%A7%E3%81%99%E3%81%8B

書込番号：25105541

[たく0220]

＞魔女宅LOVE♪さん

「127.0.0.1」はlocalhostなのでブロックするわけにはいきませんよね…

SecurityCounselorのセキュリティ診断
初期設定だとスキャンスケジュールが金曜日の朝6時… 今日の朝かな？

SSHからだと「crontab -l」でスケジュール確認できます。
海外のQNAPフォーラムでも同様な現象みかけたかもしれません。
魔女宅LOVE♪さんならご存知だと思いますが QNAPですから…

書込番号：25105639

[魔女宅LOVE♪]

＞ありりん00615さん
貴重な情報ありがとうございます。ログ見てもループバックかよ・・・と落胆していましたが、そんなカラクリがあるとは…。

あんまりログ詳しく見ている暇はないのですが、朝６時で４００件のブロック、午後もモデムやらPC再起動した後のタイミングで
４００件くらいのQファイヤーウォールによるパケットブロックの記録。PCのウイルスチェックするもクリア。
暇じゃないし、深追いするだけ無駄かも・・と放置しています。

書込番号：25105704

[魔女宅LOVE♪]

＞たく0220さん
コメントありがとうございます。
セキュリティスキャンはAM２時開始設定ですが、毎回１００時間ほどかかっており、その９５％の段階で停止しておりました。
なんで止まったのか意味不明ですが、とりあえず再起動してやり直しています。

SSHは２０年くらいやってないのと、もうそういう業界から１０年以上前に離れた人間なので、めんどくさいというのが正直なところです・・滝汗

書込番号：25105707

[たく0220]

＞魔女宅LOVE♪さん

＞セキュリティスキャンはAM２時開始設定ですが、毎回１００時間ほどかかっており、その９５％の段階で停止しておりました。

一応ですが「Malware Remover」などの事ではないです。
「Security Counselor」のセキュリティチェックは数分で終わると思いますが、長時間かかっていますか？
「[SecurityCounselor] Started running Security Checkup.」のようなログ残っていませんか？

参考: セキュリティカウンセラー | NASのセキュリティポータル | QNAP
https://www.qnap.com/solution/security-counselor/ja-jp/

書込番号：25106441

[高辻]

この掲示板にある問題と同じではありませんか？
https://www.reddit.com/r/qnap/comments/znenbm/security_checkup_triggered_failed_login_attempts/

このユーザーからの間接的な情報ですが、QNAPも認知している既知の不具合のようです。
「Update Dec 22:
QNAP support has advised me this is a known issue and they are working on a fix.
It "may require a future firmware release" to be resolved.」

書込番号：25106520

[たく0220]

＞魔女宅LOVE♪さん
＞高辻さん

＞この掲示板にある問題と同じではありませんか？

おそらく私が見かけたのも、そのredditの情報だと思います。
ただトリガーは「Security Counselor」ぽいですが、原因までは判ってなさそうです。

必ず発生するとも限らないみたいなので、とりあえずの処置としては
「Security Counselor」のセキュリティチェックを手動で行ってみて問題なさそうであれば
セキュリティ診断のスケジュールを無効にして、(手間ですが)定期的に手動チェックに切り替えて様子見する事です。

書込番号：25106616

[魔女宅LOVE♪]

クライアントアプリを表示させる画面

この問題、下記状況を確認して当てはまれば、QNAPサポートいわく、既知のバグとのことです。
ファームウェアアップデートでの対応を期待して待ちましょう。
回答していただいた皆様、ありがとうございました。

ログの確認方法
QNAPWebの設定画面からQuLog　Centerアプリを開く
ローカルデバイス→アクセスログ
リスト右端の「＋（アクション）」をクリック
クライアントアプリのチェックをオンに
ログ画面でローカルホストからのログが、SecurityCouncelerのものである場合、バグの可能性大

書込番号：25106617

[魔女宅LOVE♪]

＞たく0220さん
「セキュリティスキャン」は私の誤記です。申し訳ありません。
セキュリティスキャンは問題なしです。
時間がかかったのは、QNAPのウイルススキャン（マカフィじゃない方）です。

書込番号：25106619

[Gambit]

本日、スレ主さんと同様に、
朝6時にNSAから100件近い通知が届き起こされました。

「adminのログイン失敗！？不正アクセスか？」
と驚いて慌ててNASをチェックして色々調べ、このスレを見ました。

時刻が6時、アクセス失敗してたのがSecurityCounselorであることから、
報告にあるバグっぱいですね。

とりあえず寝て、起きてからちゃんと情報収集と対処を考えよう。

書込番号：25184035

[Gambit]

寝ぼけて書いたらNASがNSAになってる。（汗）

2月にファームウェアのアップデートされてるけど、
この問題は解消されなかったのかな？

とりあえず早朝に起こされるのは嫌なので、
手動にするかスキャン時間を変更するか。

書込番号：25184209

[魔女宅LOVE♪]

＞Gambitさん
私と同じようにNASに早朝起こされてナスすべがなくて、お困りになられたんですね・・

そういえば、この事象はうちでは一回きりでした。

しばらくしてファームウェアが出たタイミングで更新もしましたが、ずっと静かなままです。

書込番号：25184232

[Gambit]

私も購入して何年か経ちますが、初めての事態でした。
不正アクセスの可能性はほぼ無いはずなんですが、早朝の鬼通知は焦ります。
ひとまずスケジュールを日中に変更して、様子を見てみます。

書込番号：25184259

古いQNAP（QTS4.0以前）からの移行は要注意！

[X-PC]

旧NASがTS-469Proでその時に作成したバージョンによりますが、QTS4.0より前のものはレガシーボリュームというらしく、そのまま移行してもスナップショット等が使えません。ストレージプールから作り直しになります。

当方の環境
TS-469Pro 4スロット 3TB×4台 RAID5
上記を
TS-464 4スロットに移行後、3TB×4台を HDD交換にて6TB×4台に拡張（1台8時間×4台分 32時間）
スナップショットが利用できず、ストレージプールから作り直し必要と判明。
TS-469Pro 4スロット 3TB×4台 RAID5 をフォーマットし、構築しなおし。（12時間）
TS-464→TS-469Proへバックアップ実施（18時間）
TS-464のストレージプールを削除
TS-464のストレージプール新規作成（10時間） ← いまここ。
TS-469Proからバックアップを復元（予定）

このような感じです。
古いQNAPからHDDを直接移行を考えている方は注意してください。

参考にNAS互換性の注記を転記します。
https://www.qnap.com/ja-jp/nas-migration
−−−−−
QTS 4.3.4 またはそれ以降でもレガシーボリュームが存在している場合、レガシーボリューム上の全データをバックアップし、新しいボリュームをひとつあるいは複数作成してから、その新しいボリュームにデータを復元してください。これにより、ストレージおよびスナップショットの全機能を残らず利用できるようになります。
レガシーボリュームとは QTS 4.0 より前に作られたボリュームのことです。QTS を以前のバージョンから 4.0 またはそれ以降にアップグレードした後は、既にあったボリュームはレガシーボリュームになります。
レガシーボリュームは引き続きデータストレージとして使用できますが、その動作と状況は他のボリュームタイプとは一致しないものになります。また、そのボリュームはスナップショットなど最新の QTS がもつ機能の恩恵を受けることができません。
−−−−−

書込番号：24987617

Apple開発者向けのL2TP/IPSecしてRDP/VNC接続の方法

[おかめ@桓武平氏]

お世話になっています。

以下は、
Apple開発者関係者で、
NTT系回線でIPoEとPPPoE併用運用されている方、
向けの情報とします。

TS-231Kに搭載されているQVPN Service 2では、
QVPN ServiceのGUIの設定時に同一LANに設定出来ないよう、
「VPNクライアント IPプール」の設定にガードが掛かっています。

でも、自己責任での話になりますが、その逃げ道があります。

直接、/etc/config/vpn.confでIPアドレスの部分を編集すると、
デバッグ・テストなどで固定回線を使用しVPN接続し、
RDP接続及びVNC接続も可能になります。

例えば、
LANのIPアドレスを192.168.1にされる場合、
192.168.1.1はNASの共有フォルダーで使うので、
IPv4 PPPoEルーターのIPアドレスは、
192.168.1.254などに設定されると
いいかと思います。

IPv4 PPPoEルーター側のLANのIPアドレスが
例えば「192.168.1.254」の場合、
修正箇所は、以下の部分です。

・修正前
Client IP 1 = 10.2.0.2
Client IP 2 = 10.2.0.254
・修正前
Client IP 1 = 192.168.1.2
Client IP 2 = 192.168.1.254

こちらへの返信は、一切不要です。

書込番号：24588926

[おかめ@桓武平氏]

QVPN Service2のL2TP/IPSecサービスの再起動するコマンド

$ sudo /etc/init.d/vpn_l2tp.sh restart

コマンドを実行しましたら、
Shutting down L2TP services:
Starting L2TP services:
と実行されます。

書込番号：24599887

[おかめ@桓武平氏]

VPNクライアント IPプールが
Client IP 1 = 10.2.0.2
Client IP 2 = 10.2.0.254
の構成で運用する場合、
Macだけ逃げ道はある様です。

但し、モバイル回線と公衆用Wi-Fiでは、以下の設定は不要です。
※モバイル回線と公衆用Wi-Fiは、ドコモの回線を使っています。

VPN接続時に自動設定したい場合は、
VPNクライアントの/etc/pppフォルダ内に
「ip-up」と名前のファイル名で
スクリプトを配置することで使える様になります。

以下の例は、
VPNサーバー側のLANの端末が192.168.1.xxxにアクセスしたい場合です。

>>-- (ここから) --
#!/bin/sh

if [ "$1" = "ppp0" ]; then
/sbin/route route -net 192.168.1 -interface ppp0
fi
<<-- (ここまで) --

保存後、ファイルに実行権を付与させます。
$ sudo chmod +x ip-up

コマンド実行で追加する場合は、
$ sudo route -net 192.168.1 -interface ppp0

追加されているか、
ルーティングテーブルの確認は、

$ netstat -rn

で確認して下さい。

VPNサーバー側の必要なホストだけの設定でもイケるかと思います。

$ sudo route add -host アクセスしたいホストのipアドレス -interface ppp0

なお、「iPhone、iPod touch、iPad」のデバイスに関しては、
以上の内容では対応は
出来ない様です。

書込番号：24603032

[おかめ@桓武平氏]

書込番号：24603032に対して、訂正します。

�@ 訂正前
if [ "$1" = "ppp0" ]; then
/sbin/route route -net 192.168.1 -interface ppp0
fi

�@ 訂正後
if [ "$1" = "ppp0" ]; then
/sbin/route add -net 192.168.1 -interface ppp0
fi

�A 訂正前
コマンド実行で追加する場合は、
$ sudo route -net 192.168.1 -interface ppp0

�A 訂正後
コマンド実行で追加する場合は、
$ sudo route add -net 192.168.1 -interface ppp0

書込番号：24603043

WordPressとMySQLアプリが無い

[baku23]

TS-253Dです。
オペレーティングシステムQTS 5.0.0.1853 build 20211114ではWordPressとMySQLアプリがありません。
一つ前のQTS 4.5.4.1800 build 20210923ではWordPressはありますがMySQLはありません。
phpadminは存在するのでMySQLの代わりにMariaDB5.5.57を有効にしたらWordPressが稼働しました。
最新ファームウェアにWordPressアプリが無いのは残念です。

詳細はここに記述。
http://odwrsrv.mydns.jp/chi2npui2/qnap-nas-%e3%82%b5%e3%83%bc%e3%83%90%e3%83%bc%e3%82%92ts-253d%e3%81%ab%e6%9b%b4%e6%96%b0/

書込番号：24449136

[baku23]

詳細記事のURLがこちらに変わっています。
https://chi2npui2.mydns.jp/blog/2021/11/16/

書込番号：24510533

【自己責任】16GB増設はbootしませんでした。

[JGBY32]

ノーマルのメモリーは4GBなのですが、同規格のメモリーで8GB×2枚の16GBはbootしませんでした。
ノーマルメモリーはADATA製 DDR4 2666 PC4-21300の4GBですが、試したのはADATA製 DDR4 2666 PC4-21300の8GB×2枚です。
システムでチェックが入ってしまった？ようなので、4GBの2枚で我慢ですね。

書込番号：24351364　スマートフォンサイトからの書き込み

[パーシモン1ｗ]

CPUのメモリコントローラが、最大8GBですね。
https://ark.intel.com/content/www/jp/ja/ark/products/197307/intel-celeron-processor-j4025-4m-cache-up-to-2-90-ghz.html

書込番号：24351395

[JGBY32]

ありがとうございます。
CPUの制限でしたか…。
それは残念でした。
この場合は、8GBの一枚差しでも動かなかったんですが、一枚差しでもシングルだとダメなのでしょうか？
出荷時は4GBの一枚差しでした。

書込番号：24352116　スマートフォンサイトからの書き込み

[たく0220]

＞JGBY32さん

別機種のTS-453D(Celeron J4125)では、Dual Rank(2Rank)での動作報告はいくつかネットで見た気がします。
逆にSingle Rank(1Rank)のメモリーではダメだったという情報も見た気がします。

QNAPの仕様でも8GBまでですし、他社メモリーでの使用の場合はサポートしてくれない場合もありますので
元のメモリーは保証期間がすぎるまでは、手元に残されるのが無難かと思います。

書込番号：24352150

[JGBY32]

＞たく0220さん

ありがとうございます。そうなんですよね。チラホラ8GB二枚差しで動作したって見ますので出来るのかなと思ってしまいました。
とりあえず、ノーマルと同じと思われる4GBを一枚オーダーしましたので、4GB+4GBで使ってみます。

書込番号：24353135　スマートフォンサイトからの書き込み

/ ファイルシステムフルで管理画面反応しなくなって来ました

[KplusPlus]

2021年7月の最新ファーム(4.5.4.1741)の一つ前あたりのファームに更新したあたりから、管理画面にファイルシステムフル(/)の警告が出るようになり、いつの間にか管理画面にもアクセスできなくなりました。利用者側環境はいじっておらず変更点はなし。
ファームを疑い、サポートチケット発行して対応してもらいました。
切り分けで最新ファームファイルを改めて適用したが、ブートプロセスの表示がブート中のまま、でも実はNASとしては稼働している状態に陥りました。
フロントパネルから操作もできないので、強制的に電源OFF-ON。その後も/ファイルシステムフル発生。いずれは管理画面にもアクセスできなくなる予想。
サポートでは、ターミナルで状況を見させてくれというので、TeamViewerで画面共有して、ファイルシステム見てくれました。
以前、似たようなバグがあったそうですが、ファームが最新でなおっているはずなので技術者チームに連携して確認してくれるようです。
早く問題解決することを願うばかりです。メインで使っていなくてよかった。

ここからは単なる私見
仕事柄、台湾のソフトウェア開発チームとやりとりしますが、開発しているのは大陸。というパターンが多いです。QNAPはどうなんでしょう。
日本でも、大手SIerの先は中小、またその先は大陸。よくあります。コミュニケーションの問題も発生しやすい。
面倒なバグで長らく苦しんでいると、結局はOS(今回はLinux)のバグだったというあるある話もありますし、ちょっとしたところを手直しするサイレントチェンジしたところで躓くのはよくあることなので、気長に待つことにします。

書込番号：24282612

[ZUUL]

経過を読んでみると、ソフトウェア製品が未完成のまま
売られていて、なので、サポートが必要、という典型のようです。

RMAプロセスを訴求するのは、検査が半端なものを出荷しているからでしょう。

書込番号：24282727

[LsLover]

『いつの間にか管理画面にもアクセスできなくなりました。』

という状態ですと、

『管理画面にファイルシステムフル(/)の警告が出るようになり、』

エラーメッセージを画面キャプチャーでアップロードできませんか?

「ファイルシステムフル(/)」ということですと、内蔵HDDの空きエリアが無い状態のようですが...。

『フロントパネルから操作もできないので、強制的に電源OFF-ON。その後も/ファイルシステムフル発生。いずれは管理画面にもアクセスできなくなる予想。』

「強制的に電源OFF-ON」してしまうとファイルシステムの破壊などにより、起動不可となる可能性もあるかと思います。
「ファイルシステムをチェック」で自動修復できれば良いのですが、状況によっては自動修復できず、マウントもできない状態も予想されます。

『
NAS システムログに [File system is not clean ( ファイルシステムが乱れています)] と表示されるのはなぜですか？
「ファイルシステムに問題があります」というメッセージは、データを含んでいるボリュームが正しくアンマウントされなかった場合に表示されます。これは次のような状況で起こります。
』
https://www.qnap.com/ja-jp/how-to/faq/article/nas-%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%AD%E3%82%B0%E3%81%AB-file-system-is-not-clean-%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%8C%E4%B9%B1%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99-%E3%81%A8%E8%A1%A8%E7%A4%BA%E3%81%95%E3%82%8C%E3%82%8B%E3%81%AE%E3%81%AF%E3%81%AA%E3%81%9C%E3%81%A7%E3%81%99%E3%81%8B

書込番号：24283518

[KplusPlus]

管理画面では簡易にファイルシステムフルの旨が表示されるだけです

＞ZUULさん ＞LsLoverさん
私のためにお時間を割いていただきありがとうございます。感謝いたします。

＞ZUULさん
私見ですが、ファームウェアの更新回数がNETGEARのそれと比にならない位多いですね。
機能数が違いますので簡単に比較することはできませんが、ユーザからの故障申請に対応して品質を上げていく手法、"シフトライト"なのかも知れません。いや、リリース後ですから、シフトライトのさらに右ですね。　あっ、人柱かも(苦笑)。　にしては結構なお値段。
シフトレフトの方が、みんなが幸せになれるのですが、拙速を旨とする競争の世界では致し方のないことかも知れません。
あと、ひょっとするとエラー発生時のリカバリ実装がそれほどでも無いのかも知れません。

＞LsLoverさん
fsckのおすすめ、ありがとうございます。早速実行し、無事完了しました。
管理画面に出でくるファイルシステムフルの表示は簡易なもので起きたこと最小限のことを伝えています。
裏で、FULL.logとしてdf,duの出力結果が格納されていました。(最下部に貼ります。文字数の関係で抜粋です)
/var/log/qulog/mariadb.err のサイズが大きいです。
事象発生以前の何らかのオペレーションをきっかけに、リカバリ実装のないところで不具合が生じたのかも知れません。

qfullなるアプリを入れて、リモートセッション有効にして待ち状態です。

----ここからFULL.log抜粋-----
=== df output ===
Filesystem Size Used Available Use% Mounted on
none 400.0M 400.0M 0 100% /
devtmpfs 3.8G 12.0K 3.8G 0% /dev
tmpfs 64.0M 2.8M 61.2M 4% /tmp
tmpfs 3.8G 188.0K 3.8G 0% /dev/shm
tmpfs 16.0M 0 16.0M 0% /share
/dev/mmcblk1p5 7.7M 46.0K 7.7M 1% /mnt/boot_config
tmpfs 16.0M 0 16.0M 0% /mnt/snapshot/export
/dev/md9 493.5M 57.4M 436.1M 12% /mnt/HDA_ROOT
cgroup_root 3.8G 0 3.8G 0% /sys/fs/cgroup
/dev/mapper/cachedev1
14.1T 5.7T 8.5T 40% /share/CACHEDEV1_DATA
/dev/md13 417.0M 390.3M 26.7M 94% /mnt/ext
tmpfs 1.0M 0 1.0M 0% /share/external/.nd
tmpfs 1.0M 0 1.0M 0% /share/external/.cm
tmpfs 1.0M 0 1.0M 0% /mnt/hm/temp_mount
tmpfs 48.0M 88.0K 47.9M 0% /share/CACHEDEV1_DATA/.samba/lock/msg.lock
tmpfs 16.0M 0 16.0M 0% /mnt/ext/opt/samba/private/msg.sock
tmpfs 8.0M 0 8.0M 0% /var/syslog_maildir
tmpfs 16.0M 0 16.0M 0% /share/NFSv=4
/dev/mapper/cachedev1
14.1T 5.7T 8.5T 40% /share/NFSv=4/Public
hdsfusemnt 16.0M 0 16.0M 0% /share/CACHEDEV1_DATA/.qpkg/HD_Station/share
/dev/mapper/vg1-lv1312
1.8G 1.1M 1.8G 0% /mnt/pool1
/dev/mapper/vg1-snap10003
14.1T 5.3T 8.8T 37% /mnt/snapshot/1/10003
tmpfs 512.0M 115.7M 396.3M 23% /mnt/.fw_update_dir
/dev/mmcblk1p2 216.9M 206.0M 11.0M 95% /root/FLASH_RFS1
/dev/mmcblk1p3 216.9M 206.0M 11.0M 95% /root/FLASH_RFS2
/dev/mmcblk1p6 3.9M 39.0K 3.8M 1% /tmp/nasconfig_tmp

=== du output ===
6.8M /usr/local/bin
--省略--
104M /var/log/qulog/mariadb.err
104M /var/log/qulog
107M /var/log
--省略--
108M /var
4.4M /bin
401M /
----ここまでFULL.log抜粋-----

書込番号：24283840

[LsLover]

『----ここからFULL.log抜粋-----
　=== df output ===
　Filesystem Size Used Available Use% Mounted on
　none 400.0M 400.0M 0 100% /』

root（/）パーティションが400MBすべてを使用している状態のようです。
以下の内容は、参考になりませんか?
ファイルシステムの設計時に何故400MBに設定したんだろう...?

『
"No space left on device" msg although there is space free #3994
I just had a very similar issue with my qnap nas.
Running a simple borg info resulted in "No space left on device".
How to fix:
Check free space with df -h
Filesystem Size Used Available Use% Mounted on
none 400.0M 400.0M 32.0k 100% /

After running rm -r ~/.cache/borg/

Filesystem Size Used Available Use% Mounted on
none 400.0M 207.9M 192.1M 52% /
Change cache dir to fix the problem
https://borgbackup.readthedocs.io/en/stable/usage/general.html#environment-variables

You should use something in /share/CACHEDEV1_DATA as your cache dir
』
https://github.com/borgbackup/borg/issues/3994

『
General
Borg consists of a number of commands. Each command accepts a number of arguments and options and interprets various environment variables. The following sections will describe each command in detail.
』
https://borgbackup.readthedocs.io/en/stable/usage/general.html#environment-variables

書込番号：24284006

[KplusPlus]

＞LsLoverさん
ありがとうございます。

サポートからは、開発チームにログは渡してあるので、推移を見守ってほしいと連絡がありました。
推移という意味で、4-5時間で
前　none 409600 298760 110840 73% /
今　none 409600 302508 107092 74% /
と徐々に増えていってます。うまいことログローテイトの機能(に類似のもの含めて)が働いていれば、問題はないのでしょうが、そこまで見てみる余裕が今はないのが悩ましいところです。
/を400Mとしたのは、足りると思ったのでしょうね。または、組込としての容量制限とか…
一杯にならないよう、余裕のあるパーティションに逃すのも一手ですね。
開発チームがどういう見立てをしてくるのか楽しみではあります。

書込番号：24284512

[LsLover]

『サポートからは、開発チームにログは渡してあるので、推移を見守ってほしいと連絡がありました。
　推移という意味で、4-5時間で
　前　none 409600 298760 110840 73% /
　今　none 409600 302508 107092 74% /
　と徐々に増えていってます。』

具体的にどのディレクトリのデータがroot partition（/）を圧迫しているのか不明ですが、前73%->今74%と使用率が増えていることが気がかりです。

書込番号：24284631

[KplusPlus]

＞LsLoverさん
ありがとうございます

ルートパーティションだと、どのファイルが増えているか、マウントテーブルで対象外除外しつつ探すと地味に時間がかかりますね。
ざっと見てみたところでは、
　/var/log/qulog/mariadb.err
　/var/log/qulog/qulogd.log
が地味なサイズながら着実に増えていってます。qulogd.logはログローテイトしていますね。
crontab見てみます。久しぶりなので、思い出すのに時間がかかりそうです。
他にもサイズ増えているファイルありそうな気がします。
mariadb.errは
　YYMMDD hh:mm:ss [ERROR] qulogdb: Table './qulog/local_access' is marked as crashed and last (automatic?) repair failed
qulogd.logは
　YYYY-MM-DD hh:mm:ss,msec [Warning] [Database] mysql errno(144) Table './qulog/local_access' is marked as crashed and last (automatic?) repair failed: mysql_stmt_execute
数十秒間隔で出ています。データベーステーブル壊れているみたいですね。壊れ方にもよりますがリペアするだけで済みそうな気が…
QNAPサポート、このログまで収集していったはずなので、次のアクション指定がどうなるか、期待しつつ待つことにします。
(設定バックアップして、シャットダウン。HDD外して再起動してリセット、その後は復旧手順　といったところでしょうか。)
QNAP NAS Community Forumにも似た投稿があるようです。
サポートとのやり取りですが、何故か英語で始まってしまったので、ずっと英語で時々google先生のお世話になりながらやりとりしています。
最初から日本語ならば、日本語ができる人がアサインされるようですが、途中からだとバトンタッチしてくれないようです。お願いしたけど、スルーされました。人員数の関係でしょうか。日本市場のスケールでは仕方ないかも知れません。

Forum等が充実しているIT機器のサポートの場合、サポートより自身の調査の方が、結論に先に辿り着いてしまうことが少なくないと感じています。(内外問わずですが… )
かといって、個人が知りうる情報は限られていますので、サポートの解析を待とうと思っています。

書込番号：24286328

[KplusPlus]

追記
QuLog Centerが本日(つい先ほど)リリースされインストールしたところ、mariadb.errのログは出力されなくなり、qulogd.logの
YYYY-MM-DD hh:mm:ss,msec [Warning] [Database] mysql errno(144) Table './qulog/local_access' is marked as crashed and last (automatic?) repair failed: mysql_stmt_execute
が出力され続けています。

書込番号：24287010

[KplusPlus]

一度投稿しましたが、消えていたので再投稿(申し訳ないですが、思い出すのも面倒なので一部だけ)します。

トラブル事象は無くなったとサポートから連絡がありました。
無くなったとはいっても、実際は一次対処しただけです。/dev/nullにリンクしログを捨てているだけです。
　/var/log/qulog/配下
　　前　-rw-rw---- 1 admin administrators 1184541 2021-08-12 21:37 mariadb.err
　　後　lrwxrwxrwx 1 admin administrators 9 2021-08-13 11:08 mariadb.err -> /dev/null
パーティションフルを出なくした、という意味では解消ですが… 個人的には、穴ほって埋めて隠されたといった感じです。
正常動作しない機能がないことを祈ってます。

書込番号：24290109