Ubuntuで最小限のメモリ使用量で画像を表示する

Ubuntuで最小限のメモリ使用量で画像を表示する

Ubuntuで最小限のメモリ使用量で画像を表示するには、Xサーバー(GUI)環境下での軽量ビューア、または端末(コンソール)環境下での表示ツールを使用します。

最もおすすめの軽量なツールは以下の通りです。

1. グラフィカル環境 (GUI) での最軽量ツール

Xサーバーが動いている環境で、非常に少ないメモリで高速に表示できます。 

  • feh
    • 特徴: コマンドラインベースで動作する、爆速かつ超軽量な画像ビューア。
    • インストール: sudo apt install feh
    • 使い方: feh image.jpg
    • 特徴: 画像をfitさせて表示、slideshow、キーボード/マウス操作に対応。
  • sxiv (Simple X Image Viewer)
    • 特徴: 名前通り、シンプルで高速、キーボード操作主体の画像ビューア。
    • インストール: sudo apt install sxiv
    • 使い方: sxiv image.jpg 

2. コンソール (CLI) 環境での最軽量ツール

GUIなし、またはSSH経由のターミナル画面で、画像ファイルを直接表示します。

  • fbi (Frame Buffer Imageviewer)
    • 特徴: フレームバッファを使用して、Xサーバーがなくてもコンソール画面に直接画像を表示。
    • インストール: sudo apt install fbi
    • 使い方: fbi image.jpg
    • 注意: 基本はコンソール(ローカル)での表示用。
  • viu
    • 特徴: ターミナル(端末)の中で画像を表示するツール。
    • インストール: sudo apt install viu
    • 使い方: viu image.jpg
    • 特徴: 画像を文字(ブロック文字)としてターミナルに描画。 

3. デフォルトの軽量ツール

  • Ristretto
    • 特徴: Xfceデスクトップ環境の標準画像ビューア。軽量でシンプル。
    • インストール: sudo apt install ristretto

まとめ(用途別)

  • とにかくメモリを抑えたい、かつGUIが良い: feh
  • GUIがなく、SSHターミナルで画像を見たい: viu
  • GUIがなく、直接サーバーの画面で画像を見たい: fbi 

メモリが極端に少ない環境(例: 512MB〜1GB RAM)の場合は、これら軽量ツールの使用を強く推奨します。

階層分けされた相当な数のjpgファイルの中からランダムに1つ抜き出すにはどうすればいいですか

階層分けされた相当な数のjpgファイルの中からランダムに1つ抜き出すにはどうすればいいですか

大量のファイルの中からランダムに1つだけを抽出するのは、手動では大変ですよね。
お使いの環境(Windows、Mac/Linux、またはPython)に合わせて、最も効率的な方法を紹介します。


1. Windows (PowerShell) を使う場合

特別なソフトをインストールせずに、標準機能だけで実行できます。

  1. 対象のルートフォルダ(一番上のフォルダ)を「Shift + 右クリック」します。
  2. PowerShell ウィンドウをここで開く」を選択します。
  3. 以下のコマンドをコピーして貼り付け、Enterを押します。

powershell

Get-ChildItem -Recurse -Filter *.jpg | Get-Random | Invoke-Item
  • 解説: Get-ChildItem -Recurse でサブフォルダまで全検索し、Get-Random で1つに絞り、Invoke-Item でそのファイルを開きます。

2. Mac / Linux (ターミナル) を使う場合

MacやLinuxの方は、ターミナルで以下のコマンドを実行するのが最も早いです。

  1. ターミナルを開き、対象フォルダへ移動します(cd /path/to/folder)。
  2. 以下のコマンドを実行します。

bash

find . -type f -iname "*.jpg" | shuf -n 1 | xargs open
  • 解説: find で全jpgを探し、shuf -n 1 でシャッフルして1行だけ取り出し、open で開きます。

3. Python を使う場合

もし「特定のフォルダにコピーしたい」など、その後の処理も自動化したい場合はPythonが便利です。

python

import os
import random
import glob

# 検索したいルートディレクトリを指定
root_dir = './your_folder_path' 

# 再帰的にjpgファイルをリストアップ
files = glob.glob(f"{root_dir}/**/*.jpg", recursive=True)

if files:
    random_file = random.choice(files)
    print(f"選ばれたファイル: {random_file}")
    # os.startfile(random_file) # Windowsでファイルを開く場合
else:
    print("jpgファイルが見つかりませんでした。")

💡 ヒント:ファイル数が「万」を超える場合

ファイル数が膨大な場合、OSの検索機能(エクスプローラーの検索窓に *.jpg と入力)を使い、検索結果が出揃ったところで適当にスクロールして目をつぶってクリックするのが一番アナログで速いこともあります。

次に行いたい作業はありますか?
「選んだファイルを特定のフォルダに集めたい」「名前を書き換えたい」など、具体的な要望があればコードを作成します。

Ubuntuの端末でjpgファイルを抜き出してfbi(フレームバッファイメージビューワー)で表示させたいです。

Ubuntuのターミナル(CUI環境)で、階層下のJPGからランダムに1つ選んで 

fbi で表示するには、以下のコマンドを組み合わせて実行します。

実行コマンド

対象のディレクトリに移動した状態で、以下のワンライナーを実行してください。

bash

find . -type f -iname "*.jpg" | shuf -n 1 | xargs -I {} sudo fbi -T 1 -a {}

コマンドの解説

  1. find . -type f -iname "*.jpg": カレントディレクトリ以下の全階層から、拡張子が .jpg(大文字小文字問わず)のファイルをリストアップします。
  2. | shuf -n 1: リストをシャッフルし、その中から1行(1ファイル)だけをランダムに抜き出します。
  3. | xargs -I {} sudo fbi -T 1 -a {}:
    • xargs -I {}: 前のコマンドの結果を {} という場所に代入して実行します。
    • sudo fbifbi はフレームバッファデバイス(/dev/fb0)に直接書き込むため、通常は 管理者権限 が必要です。
    • -T 1: 使用する仮想コンソール(TTY1など)を指定します。これがないとエラーになる場合があります。
    • -a: 画像を画面サイズに合わせて自動リサイズして表示します。 

注意点

  • 仮想コンソールでの実行fbi は X Window System(デスクトップ環境)上のターミナルエミュレータからは直接表示できませんCtrl + Alt + F3 などで切り替えた黒い画面(仮想コンソール)で実行してください。
  • デスクトップ環境で表示したい場合: もしGUI環境のターミナルから画像を表示したいのであれば、fbi の代わりに eog(Eye of GNOME)などを使うのが一般的です。bashfind . -type f -iname "*.jpg" | shuf -n 1 | xargs eog コードは注意してご使用ください。
  • 権限エラーの回避: 毎回 sudo を使いたくない場合は、ユーザーを video グループに追加することで解決できる場合があります。bashsudo usermod -aG video $USER コードは注意してご使用ください。(※実行後、再ログインが必要です) 

このコマンドを実行する環境は、サーバー版などのCUI環境(黒い画面)でしょうか? それともデスクトップ版のターミナルでしょうか?

CUIです

UbuntuのCUI(仮想コンソール)環境で、階層下のJPGからランダムに1つを選び、

fbi で表示するコマンドは以下の通りです。

実行コマンド

bash

find . -type f -iname "*.jpg" | shuf -n 1 | xargs -I {} sudo fbi -noverbose -T 1 -a {}

各オプションの解説

  • find . -type f -iname "*.jpg": カレントディレクトリ以下の全階層から、拡張子が .jpg(大文字小文字問わず)のファイルをリストアップします。
  • shuf -n 1: リストからランダムに1行(1ファイル)だけを抽出します。
  • xargs -I {} sudo fbi ... {}: 抽出されたパスを fbi コマンドに渡します。
    • sudofbi はフレームバッファ(画面描画デバイス)に直接アクセスするため、通常は管理者権限が必要です。
    • -noverbose: 画面下部のステータスバーを非表示にし、画像だけを綺麗に映します。
    • -T 1: 出力先の仮想端末(TTY)を指定します。SSH経由や特定の環境で「Invalid argument」エラーが出るのを防ぐために有効です。
    • -a: 画面サイズに合わせて画像を自動的に拡大・縮小(オートズーム)します。 

うまくいかない場合の代替案

もし fbi でエラーが出る、あるいはより高機能なツールを使いたい場合は、後継ソフトである fim (fbi improved) がおすすめです。

  1. インストールsudo apt install fim
  2. 実行コマンド:bashfind . -type f -iname "*.jpg" | shuf -n 1 | xargs -I {} fim -a {} コードは注意してご使用ください。
    • fim はデバイスの自動検出機能に優れており、fbi よりも安定して動作することが多いです。 

表示された画像を閉じるには q キーを押してください。 他に「一定時間ごとに自動で切り替えたい」などの要望はありますか? 

はい、一定時間ごとに画像を切り替えることを考えています。15~20秒ごと

CUI環境での自動スライドショーですね。

fbi には標準で自動巡回機能がありますが、「ランダムに選び続ける」という動作をさせるには、シェルスクリプトの while ループで回すのが最も確実です。

以下のコマンドをターミナルに貼り付けて実行してください。

実行コマンド(15秒ごとにランダム切り替え)

bash

while true; do
    find . -type f -iname "*.jpg" | shuf -n 1 | xargs -I {} sudo fbi -T 1 -t 15 -1 -a -noverbose {}
done

解説

  • while true; do ... done: 手動で終了(Ctrl+C)するまで、無限に処理を繰り返します。
  • -t 15fbi が画像を 15秒間 維持するように指定します。
  • -1: 1枚表示したらすぐに fbi を終了させ、ループの先頭(次のランダム抽出)に戻るようにします。
  • -noverbose: 切り替え時に画面下のファイル名表示などを消し、没入感を高めます。

より滑らかに動作させたい場合(fim 推奨)

fbi は起動のたびに画面が暗転しがちです。もし fim をインストール済みであれば、以下のコマンドの方がスマートに動作します。

bash

# fim を使う場合(15秒おき)
find . -type f -iname "*.jpg" | shuf | fim -a -p -t 15
  • shuf: 最初に全ファイルをシャッフルしてリスト化します。
  • -p: パイプからの入力を受け取ります。
  • -t 15: 15秒ごとに自動で次の画像へ進みます。

補足

  • 終了方法Ctrl + C でループを止めることができます。
  • 秒数の調整-t 15 の数字を 20 に変えれば20秒間隔になります。

特定のフォルダだけを除外したい、あるいは特定の時間になったら停止させたいといった追加の条件はありますか?

ありません。やってみます。また質問があったら書き込みますね。

承知いたしました!ぜひ試してみてください。

while ループを使った方法は、「毎回リストをシャッフルし直す」ので、ファイル数が膨大でも偏りなくランダムに表示され続けるはずです。

もし途中で「特定のフォルダだけ読み込まないようにしたい」や「画像が横向きになってしまうのを直したい」といったことがあれば、いつでもお気軽に書き込んでくださいね。

無事にスライドショーが動くことを願っています!Ctrl + C でいつでも終了できるので、安心してお試しください。

*** buffer overflow detected ***: terminatedというメッセージがでてabouted(core dumped)で中断してしまいます。

そのエラー(buffer overflow detected)は、fbiが読み込んだファイル名やパスが長すぎる場合や、画像ファイルのヘッダー解析中にメモリ制限を超えた場合に発生することが多いです。

fbiは非常に古いツールであるため、現代の深いディレクトリ階層や複雑なファイル名、あるいは特定のJPG形式をうまく扱えず、内部でバッファオーバーフローを起こして強制終了(Core Dump)してしまうことがあります。

以下の手順で対策を試してみてください。

1. 後継ツール fim に切り替える(推奨)

fbi の改良版である fim (Fbi IMproved) を使うと、メモリ管理が改善されているため、この手のエラーを回避できる可能性が高いです。

  • インストール:bashsudo apt update && sudo apt install fim
  • 実行コマンド(15秒おき):bashwhile true; do find . -type f -iname "*.jpg" | shuf -n 1 | xargs -I {} fim -a -t 15 {} done
    • ※ fim の場合、sudo や -T 1 オプションがなくても動作することが多いです。

2. ファイルパスを短くして実行する

もしディレクトリ階層が非常に深く、パスが極端に長い(数百文字以上)場合は、一度 /tmp などにコピーしてから表示させることでエラーを回避できます。

bash

while true; do
    # ランダムに1つ選んで /tmp/slide.jpg としてコピー
    find . -type f -iname "*.jpg" | shuf -n 1 | xargs -I {} cp {} /tmp/slide.jpg
    
    # 固定された短いパスを表示
    sudo fbi -T 1 -t 15 -1 -a -noverbose /tmp/slide.jpg
done
  • メリットfbi に渡す引数が常に短くなるため、パス長に起因するオーバーフローを防げます。

3. 特定の「壊れた画像」を特定する

もし特定の画像が表示される瞬間に必ず落ちるなら、その画像ファイル自体が fbi にとって不正な形式である可能性があります。

  • チェック方法: エラーが出る直前にどのファイルを表示しようとしていたか確認します。bashwhile true; do target=$(find . -type f -iname "*.jpg" | shuf -n 1) echo "Now playing: $target" # 表示前にファイル名を出力 sudo fbi -T 1 -t 15 -1 -a -noverbose "$target" done
  • これで落ちた直前の「Now playing: …」のファイルが原因だと特定できます。その画像を除外するか、別の形式に変換してみてください。 

まずは 手順1の fim への変更 を試してみるのが最も解決への近道です。これでも同様のエラーが出ますか?

fimで表示させてみたのですが、ssh上にASCIIアートで表示され、hdmlで接続したディスプレイ出力には何も出ません。hdml出力に出力はできませんか。

SSH経由で実行すると、

fim が「表示先のディスプレイがない」と判断し、SSHターミナル内に文字(ASCIIアート)で画像を表示しようとしてしまいます。 

HDMI接続したディスプレイ(フレームバッファ)に強制的に出力させるには、出力先デバイス(-o fb と 仮想コンソール(-T 1 を明示的に指定する必要があります。

HDMI出力させるコマンド

以下のコマンドを試してみてください。

bash

while true; do
    find . -type f -iname "*.jpg" | shuf -n 1 | xargs -I {} sudo fim -a -o fb -T 1 -t 15 {}
done

修正のポイント

  • -o fb: 出力デバイスを フレームバッファ (fb) に固定します。これによりSSH上へのASCII表示を防ぎます。
  • -T 1: 出力先の画面(TTY1など)を指定します。
  • sudo: フレームバッファ(/dev/fb0など)への書き込み権限が必要なため、SSHからの実行時は必須です。 

まだ何も映らない場合

もし上記でも画面が真っ暗な場合は、OS側で出力先(/dev/fbX)の番号が異なっている可能性があります。

  1. デバイス番号を確認:
    /dev/fb0 以外に /dev/fb1 などがないか確認してください。
  2. 出力先を fb1 に変えてみる:
    もし fb0 で反応がなければ、デバイスを直接指定します。bash# 例:fim のデバイス指定オプションを追加 sudo fim -a -o "fb:/dev/fb0" ...

まずは -o fb -T 1 を追加して実行してみてください。これでHDMI側の画面が切り替わるはずです。

表示を止めたい場合は、SSHの画面で Ctrl + C を押してください。他にご不明な点はありますか?

-o fb -T1では変化なし。 直接指定の -o “fb:/dev/fb0″でも変化はありません。

SSH経由で実行している場合、標準の状態ではOSが「どのディスプレイに描画すべきか」を判断できず、手元のターミナルにASCII表示をしてしまいます。

-o fb や -T 1 で変化がない場合、フレームバッファデバイスの指定方法を修正し、さらに環境変数を明示することで解決できる可能性が高いです。以下のコマンドを試してください。

1. HDMI出力(/dev/fb0)を強制指定するコマンド

SSHの画面から以下を実行してください。

bash

while true; do
    find . -type f -iname "*.jpg" | shuf -n 1 | xargs -I {} sudo fim -a -o fb:/dev/fb0 -T 1 -t 15 {}
done

ポイント:

  • -o fb:/dev/fb0: デバイスパスを直接渡します。HDMIが/dev/fb0以外(/dev/fb1など)として認識されている場合があるため、もし映らなければ fb1 に書き換えてみてください。
  • -T 1: 仮想コンソール1番を指定します。 

2. それでも映らない場合のチェックリスト

CUI環境(特にサーバー版Ubuntuなど)では、初期状態でフレームバッファが正しく初期化されていないことがあります。

  • デバイスの存在確認:
    ls /dev/fb* を実行して、そもそもデバイスファイルが存在するか確認してください。
  • コンソールの切り替え:
    HDMI接続したディスプレイ側が「ログイン待ち」の画面になっている必要があります。もし画面が真っ暗(省電力モード)なら、HDMI側のキーボードで何かキーを叩くか、以下のコマンドで画面を強制復帰させてください。bashsudo sh -c 'setterm -blank 0 -powersave off -cursor off > /dev/tty1'
  • 権限の確認:
    SSH越しの場合、デバイスへのアクセス権が厳しいため、必ず sudo をつけて実行してください。 

3. オススメの代替案:fbv

fim や fbi が環境に合わない場合、より軽量な fbv というツールもCUIでの画像表示に特化しています。

  1. インストールsudo apt install fbv
  2. 実行:bashwhile true; do find . -type f -iname "*.jpg" | shuf -n 1 | xargs -I {} sudo fbv -a {} sleep 15 done
  3. ※ fbv は表示し続ける機能がシンプルなので、sleep 15 で間隔を調整します。

まずは 手順1の fb:/dev/fb0 を試し、ダメなら ls /dev/fb* でデバイス番号が合っているか確認してみてください。

HDMI側の画面には今、何が表示されていますか?(例:ログインプロンプト、真っ暗、カーソルのみ点滅など)

hdmlを直接指定する方法でもssh画面のアスキーアートで、hdml側はカーソル点滅状態。デバイス番号はfb0でした。fbvはapt installで見つからないと言われました。

SSH経由での実行において、ツール側が「表示先(端末)」を手元のSSH画面だと誤認してしまい、ASCIIアートを出力している状態です。

fbi でのバッファオーバーフローや fim の挙動を考慮し、「一度別の場所にコピーしてファイル名を固定する」 ことでエラーを回避しつつ、HDMI側(フレームバッファ)へ強制的に描画させる確実な方法を提案します。

解決策:ファイル名を固定して HDMI (/dev/fb0) へ出力する

以下のスクリプトをSSH画面で実行してください。

bash

while true; do
    # 1. ランダムに1つ選んで、名前を短く安全なものにして /tmp にコピー
    # (長いパス名によるオーバーフローを回避)
    find . -type f -iname "*.jpg" | shuf -n 1 | xargs -I {} cp {} /tmp/current.jpg

    # 2. fim を使い、出力先を強制的にフレームバッファ (/dev/fb0) に指定
    # (-i オプションで対話モードをオフにし、SSH側への出力を抑制)
    sudo fim -a -o fb:/dev/fb0 -T 1 -i /tmp/current.jpg &
    
    # 3. 指定秒数待機
    sleep 15
    
    # 4. 前の fim プロセスを終了させて次の画像へ
    sudo killall fim > /dev/null 2>&1
done

この方法のポイント

  1. /tmp/current.jpg へのコピーfbi で発生していた buffer overflow は、ファイルパスが長すぎることが主な原因です。一旦短い固定名にコピーすることでこれを根本から防ぎます。
  2. -i オプション(fim): これにより、fimがターミナルと対話しようとするのを防ぎ、SSH側へのASCIIアート表示を抑制します。
  3. killall による制御fim の自動スライドショー機能がSSH越しで不安定な場合があるため、シェルスクリプト側で「表示→待機→終了」を制御することで確実にHDMI側の画面を更新します。 

まだHDMI側に映らない場合(環境の確認)

もしこれでもHDMI側が「カーソル点滅」のままなら、以下の2点を確認してください。

  • コンソールの表示を強制リセット:
    HDMI側の画面が「スリープ」している可能性があります。一度以下のコマンドを打って、HDMI側の画面を真っさらにしてから上記スクリプトを実行してください。bashsudo cat /dev/urandom > /dev/fb0 # 画面に砂嵐が出れば、fb0へのアクセスは成功しています sudo clear > /dev/tty1 # 画面を清掃
  • fbv について:
    fbv は古いパッケージのため、sudo apt update をした直後でも見つからない場合は、Ubuntuの universe リポジトリが有効になっていない可能性があります(sudo add-apt-repository universe で追加可能)。しかし、まずは上記の fim + cp 作戦が最も安定します。 

まずは上記のスクリプトで、HDMI側の画像が切り替わるか確認してみてください。

hdml側の状態が変わりました。入力待ちの状態と真っ黒な画面が交互に現れます。画面描写がうまくいっていないようですね。

HDMI側の画面が「入力待ち(プロンプト)」と「真っ黒」を繰り返すのは、

表示された画像が瞬時に終了しているか、コンソールのテキスト描画(カーソルなど)が割り込んで画像を上書きしてしまっているのが原因です。

これを解決するために、fbi に戻りつつ、「パス長制限」と「表示の維持」をクリアする以下の方法を試してください。

解決策:一時ファイル化 + fbi の待機モード

fbi のバッファオーバーフローは「ファイルパスの長さ」が原因であることが多いため、/tmp に短い名前でコピーしてから表示させるのが最も確実です。

以下のコマンドをSSHから実行してください。

bash

while true; do
    # 1. ランダムに1つ選んで短いパスへコピー(オーバーフロー対策)
    find . -type f -iname "*.jpg" | shuf -n 1 | xargs -I {} cp "{}" /tmp/slide.jpg
    
    # 2. fbiで表示(1枚表示して15秒維持)
    # -T 1: HDMI側の仮想コンソール1を指定
    # -1: 1枚表示したら終了する
    # -t 15: 15秒間表示を維持する
    # -noverbose: 余計な文字を表示しない
    sudo fbi -d /dev/fb0 -T 1 -t 15 -1 -a -noverbose /tmp/slide.jpg
done

これでもチラつく場合の追加対策

もし画像が一瞬しか映らない場合は、HDMI側の「カーソル」や「画面保護機能」が干渉しています。以下の2つのコマンドを実行前に一度だけ打ってください。

  1. カーソルを消す(HDMI側の画面に対して)bashsudo sh -c 'setterm -cursor off > /dev/tty1' コードは注意してご使用ください。
  2. 画面のスリープ(ブランク)を無効化するbashsudo sh -c 'setterm -blank 0 -powersave off > /dev/tty1' コードは注意してご使用ください。

なぜ fim ではなく fbi なのか

fim はSSH環境だと気を利かせてASCIIアートに逃げてしまいますが、fbi は最初から「フレームバッファ専用」ツールなので、デバイス(/dev/fb0)とパス(/tmp/slide.jpg)さえ正しく指定すれば、確実にHDMI側へ描画してくれます。

この「コピーしてから fbi」の方法で、画像は静止して表示されるようになりますか?

表示されるようになりました。ただ、写真に合わせてhdmlディスプレイを縦位置に回転(90°)しているのです。表示画像を回転するようなオプションはありませんか。

無事に表示されたとのこと、良かったです!

fbi には表示時に画像を回転させるオプションがあります。
-2 オプションを使うと画像を右に90度(時計回り)回転させることができます。
(もし逆向きなら -1 で180度、-3 で270度(反時計回り90度)になります)

以下のコマンドで試してみてください。

回転オプション付きコマンド

bash

while true; do
    # ランダムに1枚選んでコピー
    find . -type f -iname "*.jpg" | shuf -n 1 | xargs -I {} cp "{}" /tmp/slide.jpg
    
    # -2 オプションで90度回転して表示
    sudo fbi -d /dev/fb0 -T 1 -t 15 -1 -a -2 -noverbose /tmp/slide.jpg
done

主な回転オプション

  • -2: 90度回転(時計回り)
  • -3: 270度回転(反時計回り90度)
  • -1: 180度回転
    ※ -1 は「1枚表示して終了」という以前使ったオプションと同じ記法ですが、fbi の仕様上、引数の位置や文脈で回転として機能します。もし「1枚で終了」が効かなくなる場合は、-2 などの後に再度 -1 を書いてみてください。

補足:もしすべての画像ではなく「横向きの写真は回転させたいが、縦向きはそのままでいい」場合

fbi 自体には自動で向きを判別する機能が乏しいため、上記コマンドは「すべての画像を90度回して縦長ディスプレイに合わせる」設定です。

もし画像ごとに判断が必要な場合は、exiftran というツールでコピー時にファイルを自動回転させる方法もあります。

全ての画像が同じ向きに回転して表示されれば、これで完成でしょうか?

全て同じ向きに表示されればOKなのですが、hdml画面に「-2: loading FAILED」と表示されて画像が表示されなくなりました。

申し訳ありません。

fbi の引数において -2 などの数字オプションは、「起動後にキーボードの ‘2’ を押す」動作をシミュレートする特殊な指定方法(または古いバージョンの仕様)であり、環境によっては「ファイル名 -2 を読み込もうとして失敗した」と誤認されることがあります。

現在の fbi で確実に画像を回転させて表示するには、表示オプションではなく、コピーする際に画像を物理的に回転させてしまう方法が最も確実でエラーが起きません。

fbi の代わりに、画像処理ツール convert (ImageMagick) を組み合わせて、「ランダムに選ぶ → 90度回転して保存 → 表示」 という流れにします。

1. 必要なツールのインストール

画像を回転させるための ImageMagick をインストールします。

bash

sudo apt update && sudo apt install imagemagick -y

2. 実行コマンド(90度回転スライドショー)

以下のスクリプトをコピーして実行してください。

bash

while true; do
    # 1. ランダムに1つ選ぶ
    target=$(find . -type f -iname "*.jpg" | shuf -n 1)
    
    # 2. 90度回転させて一時ファイルに保存 (時計回りに90度)
    # 反時計回りが良ければ 270 に変更してください
    convert "$target" -rotate 90 /tmp/slide.jpg
    
    # 3. fbiで表示(15秒間)
    sudo fbi -d /dev/fb0 -T 1 -t 15 -1 -a -noverbose /tmp/slide.jpg
done

この方法のメリット

  • エラー回避fbi に変なオプションを渡さないので、「FAILED」エラーが出ません。
  • 柔軟性-rotate 90 の数字を変えるだけで、90度、180度、270度と自由に調整できます。
  • アスペクト比-a オプション(オートズーム)と組み合わせることで、縦長ディスプレイにぴったりのサイズで表示されます。

これでHDMI画面に、正しい向きで画像が表示されますでしょうか?
(もし回転方向が逆なら、90 を 270 に書き換えてみてください)

OKです。スクリプトを組んで表示させているのですが、test.sh: line 14: 3272 Killed convert “$target” -rotate 90 /tmp/slide.jpg というメッセージが時々ssh側に現れて同じ画像がずっと表示されるという現象が出ています。

そのメッセージは、「ImageMagick (convert) がメモリ不足(OOM Killer)などの理由でOSによって強制終了させられた」ことを示しています。

特に、元画像が非常に高解像度(4Kや数千万画素など)な場合、convert は回転処理のために大量のメモリを消費しようとして、Ubuntuのシステム保護機能によって「Killed」されてしまいます。その結果、新しい /tmp/slide.jpg が生成されず、古い画像が表示され続けてしまいます。

これを防ぎ、より低負荷で安定させるための対策を2つ提案します。

対策1:メモリ消費を抑えて高速に回転させる (jpegtran)

convert の代わりに、JPEG専用の高速・低メモリツール jpegtran を使います。これは画像を再エンコードせず「ハフマンテーブル」の書き換えだけで回転させるため、劇的に軽く、メモリ不足で落ちることもまずありません。

  1. インストール:bashsudo apt update && sudo apt install libjpeg-progs -y
  2. スクリプトの書き換え:
    convert の行を以下に差し替えてください。bash# 90度回転 (時計回り) jpegtran -rotate 90 "$target" > /tmp/slide.jpg

対策2:メモリ制限をかけてリサイズしつつ回転 (convert 改良)

もし jpegtran が使えない事情がある場合は、convert に対して「メモリを使いすぎない」「先にリサイズして負荷を下げる」指定を追加します。

bash

# メモリ使用量を制限しつつ、画面サイズ(例: 1080x1920)に収めてから回転
convert -limit memory 256MiB -limit map 512MiB "$target" -resize 1920x1920 -rotate 90 /tmp/slide.jpg

修正後の安定版スクリプト (jpegtran 推奨)

bash

#!/bin/bash

# 念のため初期化
sudo touch /tmp/slide.jpg
sudo chmod 666 /tmp/slide.jpg

while true; do
    # 1. ランダムに1枚抽出
    target=$(find . -type f -iname "*.jpg" | shuf -n 1)
    
    # 2. 高速・低メモリで90度回転 (失敗してもループを止めない)
    jpegtran -rotate 90 "$target" > /tmp/slide.jpg 2>/dev/null
    
    # 3. jpegtranが失敗(空ファイル)した時のためのチェック
    if [ ! -s /tmp/slide.jpg ]; then
        cp "$target" /tmp/slide.jpg # 失敗時は回転なしでコピー
    fi

    # 4. 表示
    sudo fbi -d /dev/fb0 -T 1 -t 15 -1 -a -noverbose /tmp/slide.jpg
done

jpegtran を使う方法なら、大きな写真が混ざっていてもサクサクと切り替わるはずです。まずは libjpeg-progs のインストールから試してみてください。

これで「Killed」が出ずに安定して動作しますでしょうか?

rsync: [generator] recv_generator: failed to stat “/mnt/nas10tb/Signage/20210518/20210518-15.jpg”: Bad message (74)何の意味?

rsync: [generator] recv_generator: failed to stat “/mnt/nas10tb/Signage/20210518/20210518-15.jpg”: Bad message (74)何の意味?

このエラーは、rsyncが特定のファイルの状態を確認(stat)しようとした際、OSレベルで「ファイルデータが壊れている」と判断されたことを意味します。

具体的には、Linuxのシステムエラー番号 74 (EBADMSG: Bad message) が発生しています。

主な原因

このエラーは単なるrsyncの不具合ではなく、ストレージや通信の根本的な問題である可能性が高いです。 

  • ファイルシステムの破損: NAS(/mnt/nas10tb)上の該当ファイルが物理的または論理的に破損しており、OSが読み取れない状態。
  • ハードウェアの故障: HDD/SSDの物理的な不良セクタや、NASのメモリ(RAM)エラー。
  • 通信経路の異常: NASとの接続に使用しているプロトコル(NFSやSMBなど)が不安定で、データ整合性が崩れている。

推奨される対処法

  1. ファイルの生存確認:
    該当ファイル(20210518-15.jpg)を ls -l や cat 等で手動で読み取れるか確認してください。同様にエラーが出る場合はファイル自体が壊れています。
  2. ファイルシステムのチェック:
    NAS側で管理画面やSSHを利用し、fsck などのコマンドでファイルシステムの修復を試みてください。
  3. NASのログ確認:
    NAS側のシステムログ(dmesgなど)に、I/Oエラーやディスクの異常(S.M.A.R.T.エラー)が記録されていないか確認してください。
  4. 再マウント:
    一時的な通信エラーであれば、NASをアンマウントして再度マウントし直すことで解消する場合があります。

まずは、該当するファイルを手動で別の場所にコピーできるか試してみるのが一番の切り分けになります。

    コピーできませんし、sudo rmで削除しようとしてもrm: cannot remove ‘/mnt/nas10tb/Signage/20210518/20210518-15.jpg’: Bad messageで拒否されます。

    sudo rm

     でも削除できない状態は、OSがファイルシステム上のデータ構造(メタデータ)を正しく解釈できていない深刻な不整合を示しています。

    「Bad message」エラーが出ている場合、通常のファイル操作コマンド(rmcpmv)は受け付けられません。以下の順序で対処を検討してください。

    1. NASの「修復機能」を実行する(最優先)

    マウントしているPC側から操作するのではなく、NAS自体のOS(管理画面)からチェックを行うのが最も安全です。

    • 管理画面から: QNAPやSynology、バッファロー等のNASであれば、ブラウザの管理画面にある「ストレージマネージャー」等から「ファイルシステムのチェック」や「ボリュームの修復」を実行してください。
    • RAIDの整合性チェック: RAID構成を組んでいる場合は、データスクラビング(整合性確認)を実行することで修復される可能性があります。

    2. ファイルシステムチェック(fsck)の実行

    Linuxサーバー等にHDDを直接接続、またはNASにSSHで入れる場合は fsck コマンドを使用します。

    注意fsck は必ず対象のパーティションを アンマウント(umount) した状態で実行してください。マウントしたまま行うとデータが完全に破壊される恐れがあります。

    bash

    # アンマウント(例: /dev/sdb1 が対象の場合)
    sudo umount /mnt/nas10tb
    
    # チェックと修復の実行
    sudo fsck -y /dev/sdb1
    

    ※ -y オプションはすべての修復提案に自動で “yes” と答える設定です。 1.4.6 

    3. ディレクトリごと削除を試みる

    ファイル単位で「Bad message」が出る場合でも、その親ディレクトリごと削除(rm -rf)することで、ディレクトリのエントリごと消去できる場合があります。

    • リスク: そのフォルダ内の正常なファイルもすべて消えます。必要なデータは先に別の場所へ退避させてください。
    • 方法sudo rm -rf /mnt/nas10tb/Signage/20210518/ 

    4. ハードウェア故障(不良セクタ)の疑い

    修復を試みてもエラーが消えない、あるいは fsck が途中で止まる場合は、HDDの物理的な不良セクタ(メディア故障)が原因です。 1.4.3

    • この場合、無理に書き込み(削除)を続けようとすると他のデータまで破損する恐れがあります。
    • NASのログで「I/O Error」や「SMART Error」が出ていないか確認し、異常があればHDDの交換を検討してください。

    このNASは、メーカー製品(QNAP/Synology等)でしょうか、それとも自作のLinuxサーバーでしょうか?機種や構成がわかれば、より具体的な修復手順を提示できます。

    自作のUbuntuサーバーです。

    自作のUbuntuサーバーで 

    Bad message により削除すらできない場合、ファイルシステムのメタデータが壊れており、カーネルがそのファイルへの操作を拒否しています。 

    以下の手順で、ファイルシステムの強制修復を試みてください。

    手順1:ファイルシステムの種類とデバイス名の確認

    修復には正確なデバイス名(/dev/sdb1 など)が必要です。以下のコマンドで確認してください。

    bash

    df -Th | grep /mnt/nas10tb
    
    • ここで表示される「Filesystem」列(例: /dev/sdc1)と「Type」列(例: ext4xfs)をメモしてください。

    手順2:アンマウント

    修復作業(fsck)は、対象のディスクをマウントしたまま行ってはいけません。 

    bash

    sudo umount /mnt/nas10tb
    

    コードは注意してご使用ください。

    ※ 「target is busy」と出る場合は、sudo fuser -mk /mnt/nas10tb でアクセス中のプロセスを強制終了させてから再度試してください。

    手順3:強制修復(fsck)の実行

    ファイルシステムの種類に合わせて以下のコマンドを実行します。

    • ext4 の場合:bashsudo fsck.ext4 -fy /dev/対象デバイス名 コードは注意してご使用ください。-f は強制チェック、-y はすべての修復に自動で「はい」と答えるオプションです。
    • XFS の場合:bashsudo xfs_repair /dev/対象デバイス名 コードは注意してご使用ください。 

    手順4:再マウントと確認

    修復が終わったら、再度マウントしてファイルが消えているか(または削除できるか)確認します。

    bash

    sudo mount -a
    ls /mnt/nas10tb/Signage/20210518/
    

    コードは注意してご使用ください。

    それでも解決しない場合

    もし fsck で「Input/output error」が出る、あるいは修復後も再発する場合は、HDDの物理故障(不良セクタ)が確定です。

    • dmesgの確認sudo dmesg | grep -i error で、ディスク関連のハードウェアエラーが出ていないかチェックしてください。
    • 物理故障の疑い: 故障している場合は、該当ドライブのデータを可能な限り救出した後、速やかにHDDを交換することをお勧めします。 

    現在、ファイルシステムの種類(ext4 や zfs など)は何を使用されていますか?

    対象のnas10tbはRAID5のアレイです。ext4を使用しています。

    自作のUbuntuサーバーかつRAID5(ext4)の環境で 

    Bad message が出ている場合、「RAIDアレイ内の特定のディスクで読み取りエラーが発生し、それがファイルシステムの破損(メタデータの矛盾)として現れている」 可能性が非常に高いです。

    通常の rm では消せないため、以下の手順で RAIDの整合性チェック と ファイルシステムの修復 を組み合わせて対処してください。

    手順1:RAIDの状態を確認する

    まず、RAIDアレイ自体が正常(Active)か、どこかのディスクが脱落(Degraded)していないか確認します。

    bash

    cat /proc/mdstat
    
    • [UUU] のようにすべて U であれば正常です。[_UU] のように _ がある場合はディスクが故障しています。 1.5.3

    手順2:RAIDの整合性チェック(check)を実行 

    RAID5のパリティを利用して、不整合を修復させます。これにより、ファイルシステムレベルの修復(fsck)が通りやすくなることがあります。 1.5.4 

    bash

    # md0 はご自身の環境に合わせて読み替えてください
    echo check | sudo tee /sys/block/md0/md/sync_action
    
    • /proc/mdstat を見ると進捗が確認できます。10TBだと数時間〜一日以上かかる場合があります。 

    手順3:アンマウントして fsck を実行

    RAIDのチェックが終わるか、あるいは待てない場合は、対象のアレイをアンマウントして ファイルシステムの強制修復 を行います。 

    bash

    # 1. アンマウント
    sudo umount /mnt/nas10tb
    
    # 2. 強制修復(-f: 強制, -y: 全てyesで修復)
    sudo fsck.ext4 -fy /dev/md0
    
    • Bad message の原因となっている不正なiノードやディレクトリエントリがここで修正・削除されます。 1.3.1

    手順4:ディスクの物理故障を確認(重要)

    Bad message は物理故障の前兆であることが多いです。特定のディスクに異常がないか、S.M.A.R.T.情報を確認してください。 1.2.8

    bash

    # 各物理ディスク(/dev/sda, sdb...)に対して実行
    sudo smartctl -a /dev/sda | grep -i error
    
    • Reallocated_Sector_Ct や Current_Pending_Sector の値が 0 以外であれば、そのディスクの寿命です。

    アドバイス:
    RAID5は1台の故障には耐えられますが、修復中(リビルド中)に2台目が壊れると全データが消失します。10TBの大容量HDDではリビルド負荷で連鎖故障が起きやすいため、もし fsck で直っても、早めに重要なデータのバックアップを別の媒体に取ることを強くお勧めします。 1.3.7 

    まずは cat /proc/mdstat の結果に _(異常)が含まれていないか教えていただけますか

    全てUです。S.M.A.R.T.情報にも問題はありませんでした。いまfsckをかけています。

    RAIDアレイ(

    mdstat)も物理ディスク(S.M.A.R.T.)も正常であるとのこと、ひとまず「物理的な崩壊」の可能性が低そうで安心しました

    となると、今回の原因はハードウェア故障ではなく、「OSのクラッシュ」「停電」「不適切なアンマウント」などによって、ext4のメタデータ(管理情報)に論理的な矛盾が生じたものと考えられます。

    fsck実行中の注意点と次のステップ

    1. 「lost+found」ディレクトリの確認
      fsck -fy が完了して再マウントした後、/mnt/nas10tb/lost+found/ を覗いてみてください。
      ファイル名が特定できなくなったデータが #12345 のような番号で復元されている場合があります。今回エラーが出ていた 20210518-15.jpg も、実体が生きていればここに放り込まれている可能性があります。 参考: Cyberciti – lost+found folder
    2. rsyncの再開
      修復が終われば、再び rsync が通るようになるはずです。
      もし rsync がまた止まるようなら、別のディレクトリにも同様の破損が潜んでいるサインですので、再度 fsck が必要になるかもしれません。
    3. dmesg のモニタリング
      もし fsck 中に大量の「Pass 1: Checking inodes, blocks, and sizes」的な修正が走っているなら、完了後に念のため以下を実行して、カーネルがまだ何か文句を言っていないか確認してください。bashdmesg | tail -n 50 コードは注意してご使用ください。

    10TBという大容量だと fsck の完了まで時間がかかるかもしれませんが、途中で中断(Ctrl+C)しないようにだけご注意ください。

    無事に 20210518-15.jpg(あるいはその残骸)が消去または修復されることを祈っています。修復完了後、正常にアクセスできるようになったか教えてくださいね。

    fsckで修復されたようです。念のためcpして内容の確認もしておきます。

    無事に 

    fsck で修復できたようで何よりです!
    物理故障(S.M.A.R.T.エラー)がなく、アレイも正常(All U)だったことから、純粋なファイルシステムの論理矛盾だった可能性が高いですね。

    cp での確認は非常に賢明な判断です。以下の点もあわせてチェックしておくと安心です。

    1. ファイルの整合性:
      コピーできたとしても、画像ファイル(.jpg)の場合、下半分がグレーになっていたりノイズが乗っていたりすることがあります。一度ビューアーで開いて画像が壊れていないか確認することをおすすめします。
    2. rsync の再走:
      原因となったファイル以外にも、インデックス(inode)が狂っていた箇所があるかもしれません。一度 rsync --dry-run を実行して、他に同様のエラーが出ないかサッと流してみるのが確実です。
    3. lost+found の掃除:
      もし fsck で「ファイル名が特定できないデータ」が救出されていた場合、マウントポイント直下の lost+found フォルダに溜まっています。不要であれば容量を食うだけなので、確認後に削除してOKです。

    今回のトラブルが一時的なソフトエラー(書き込み中の瞬断など)であれば良いのですが、もし今後も頻発するようなら、SATAケーブルの接触不良メモリ(RAM)の相性・故障も疑ってみてください。

    このまま rsync は無事に完走しそうですか?

    やってみます。ありがとうございました。

    承知いたしました。無事に解決することを祈っています!

    もし rsync 中に再び似たようなエラー(Bad message や Input/output error)が出る場合は、ファイルシステムではなく、RAIDコントローラやケーブル、あるいはメモリ(RAM)など、別のレイヤーのトラブルも疑う必要が出てきます。

    しばらくは dmesg -w などでシステムログを監視しながら作業を進めてみてください。

    また何かお困りのことがあれば、いつでもご相談ください。
    rsync が無事に完走することを願っています!

    macOSで作業しています。フォルダ内に画像が沢山入っているフォルダがいくつかあります。jpgとpngが混在しています。中にはjpegというのもあります。全てjpgに統一したいのです。スクリプトを組みたいのですが、サンプルをお願いします。

    macOSで作業しています。フォルダ内に画像が沢山入っているフォルダがいくつかあります。jpgとpngが混在しています。中にはjpegというのもあります。全てjpgに統一したいのです。スクリプトを組みたいのですが、サンプルをお願いします。

    macOSで画像形式(拡張子)を一括でJPGに統一するには、標準搭載されている強力な画像処理コマンド sips を使用するのが最も効率的です。 

    以下に、特定のフォルダ(およびその中にある子フォルダ)内の画像をすべて .jpg に変換し、元のファイルを削除するスクリプトのサンプルを紹介します。

    1. ターミナルで実行するワンライナー

    最も手軽な方法です。対象のフォルダに移動して実行してください。

    zsh

    # 対象のフォルダへ移動
    cd /path/to/your/folder
    
    # png, jpeg, JPEG などを一括で jpg に変換
    for f in *.{png,jpeg,JPEG,PNG}; do [ -f "$f" ] && sips -s format jpeg "$f" --out "${f%.*}.jpg" && rm "$f"; done
    
    • sips -s format jpeg: 画像をJPEG形式に変換します。
    • ${f%.*}.jpg: 元のファイル名から拡張子を取り除き、一律 .jpg を付与します。
    • rm "$f": 変換が成功した後に元のファイルを削除します(不要な場合は削除してください)。 

    2. 複数のフォルダ(サブフォルダ)をまとめて処理するスクリプト

    階層構造になっている複数のフォルダを一度に処理したい場合は、以下のスクリプトをファイル(例: convert.sh)として保存して実行してください。

    bash

    #!/bin/bash
    
    # 変換したい親フォルダのパスを指定
    TARGET_DIR="./target_images"
    
    # 指定フォルダ内の png, jpeg を探し、1つずつ jpg へ変換
    find "$TARGET_DIR" -type f \( -iname "*.png" -o -iname "*.jpeg" \) | while read -r file; do
        # 出力ファイル名を作成(拡張子を .jpg に変更)
        output="${file%.*}.jpg"
        
        # 変換実行
        sips -s format jpeg "$file" --out "$output" > /dev/null 2>&1
        
        # 変換が成功し、かつ元ファイルと別名であれば元を削除
        if [ $? -eq 0 ] && [ "$file" != "$output" ]; then
            rm "$file"
            echo "Converted: $file -> $output"
        fi
    done
    

    実行方法

    1. テキストエディタに上記コードを貼り付け、convert.sh として保存します。
    2. ターミナルで実行権限を与えます:chmod +x convert.sh
    3. スクリプトを実行します:./convert.sh

    補足・注意点

    • 画質の指定sips -s formatOptions 80 のようにオプションを追加することで、圧縮率(画質)を調整できます(0〜100、デフォルトは約80)。
    • 既存の .jpg: 元々 .jpg という拡張子のファイルは、このスクリプトでは(二重変換を避けるため)処理対象から外しています。
    • バックアップ: 大量のファイルを操作するため、実行前にフォルダのコピー(バックアップ)を取っておくことを強く推奨します。 

    スクリプトではなく、Finderの右クリックメニュー(クイックアクション)から一括変換したい場合は、Automator を使用して「イメージのタイプを変更」アクションを設定する方法も便利です。 

    処理したいフォルダの構造(1つのフォルダか、階層構造か)や、変換後の画質へのこだわりはありますか?

    画質はデフォルトでOKです。フォルダ構造はフォルダの中に1階層だけです。

    「親フォルダ > 子フォルダ > 画像ファイル」という1階層の構造ですね。

    macOS標準の sips コマンドを使用し、子フォルダ内の .png や .jpeg を一括で .jpg に変換し、元のファイルを削除するスクリプトを作成しました。 

    1. 実行用スクリプト(保存して使う場合)

    以下のコードをテキストエディタに貼り付け、convert.sh という名前で保存してください。

    bash

    #!/bin/zsh
    
    # 1. 処理したい「親フォルダ」のパスを指定してください
    # 例: TARGET_DIR="$HOME/Desktop/MyPhotos"
    TARGET_DIR="./対象の親フォルダ名"
    
    # 2. 親フォルダ直下の子フォルダをループ処理
    for subfolder in "$TARGET_DIR"/*(/); do
        echo "Processing folder: $subfolder"
        
        # 3. 子フォルダ内の png, jpeg, JPEG, PNG を探して変換
        # 拡張子が jpg 以外のものを対象にします
        for file in "$subfolder"/*.{png,jpeg,PNG,JPEG}(N); do
            # 出力ファイル名(拡張子を .jpg に変更)
            output="${file%.*}.jpg"
            
            # sipsで変換実行
            sips -s format jpeg "$file" --out "$output" > /dev/null 2>&1
            
            # 変換に成功し、かつ元ファイルと別名なら元を削除
            if [[ $? -eq 0 && "$file" != "$output" ]]; then
                rm "$file"
            fi
        done
    done
    
    echo "完了しました。"
    

    使い方

    1. パスの書き換えTARGET_DIR の部分を作業したいフォルダ名(またはパス)に書き換えます。
    2. 実行権限の付与: ターミナルで chmod +x convert.sh を実行します。
    3. 実行./convert.sh で開始します。

    2. ターミナルで即座に実行する(ワンライナー)

    スクリプトを作らずに、ターミナルで親フォルダまで移動(cd)してから直接実行する方法です。 

    zsh

    for d in *(/); do for f in "$d"/*.{png,jpeg,PNG,JPEG}(N); do sips -s format jpeg "$f" --out "${f%.*}.jpg" && rm "$f"; done; done
    
    • *(/): フォルダ(ディレクトリ)のみを対象にします。
    • (N): 該当する拡張子のファイルがない場合にエラーを出さない設定です。

    注意事項

    • 上書き確認: このスクリプトは変換後に元のファイルを削除 (rm) します。念のため、最初はテスト用のフォルダで動作を確認するか、バックアップを取ってから実行してください 1.2.2, 1.3.1。
    • 拡張子の統一: 全て小文字の .jpg に統一されます。 

    このスクリプトを定期的に使いたい、あるいは特定の画質(圧縮率)を指定したいといったご要望はありますか?

    Windows11でデバイスドライバには認識されているにもかかわらず、ドライブDとして認識されていないHDDがあります。どうチェックすればいいですか。

    Windows11でデバイスドライバには認識されているにもかかわらず、ドライブDとして認識されていないHDDがあります。どうチェックすればいいですか。

    Windows 11でデバイスマネージャーには表示されているのに「Dドライブ」として認識されない場合、ハードウェア自体はPCに繋がっていますが、「OS側でドライブレター(D:)が割り当てられていない」か、「パーティションが未定義」である可能性が高いです

    以下の手順で「ディスクの管理」ツールを使用してチェック・修正してください。

    1. 「ディスクの管理」を開く 

    1. 画面下の「スタート」ボタンを右クリックします。
    2. メニューから [ディスクの管理] を選択します。 

    2. ディスクの状態を確認する 

    開いた画面の下半分にある「ディスク 0」「ディスク 1」といった一覧から、該当のHDDを探します。その右側のバー(ボリューム)の状態によって対処が異なります。

    • 「未割り当て」と表示されている場合
      • 原因: パーティションが作成されていません(新品のHDDなど)。
      • 対処: 右クリックして [新しいシンプルボリューム] を選択し、画面の指示に従ってフォーマットとドライブ文字の割り当て(D:)を行います。※データは消去されるため、データが入っているはずの場合は注意してください。
    • 「(文字なし)」または「正常」でバーが青い場合
      • 原因: パーティションはあるが、ドライブレター(D:など)が割り当てられていません。
      • 対処: その部分を右クリックし、[ドライブ文字とパスの変更] を選択 → [追加] を押し、ドライブ文字に「D」を割り当てて [OK] をクリックします。
    • 「不明・初期化されていません」と表示されている場合
      • 原因: パーティションスタイルが設定されていません。
      • 対処: 「ディスク X」と書かれた左端の領域を右クリックして [ディスクの初期化] を行います。通常は「GPT」を選択します。 エプソン ホームページエプソン ホームページ +4

    3. それでも認識されない場合のクイックチェック

    • USBポートの変更: ポータブルHDDの場合、電力不足で動作が不安定になることがあります。PC背面のポートや別のUSBポートに差し替えてみてください。
    • ドライバーの再認識: デバイスマネージャーで該当のHDDを右クリックし、[デバイスのアンインストール] を選んだあと、PCを再起動して自動で再読み込みさせてください。 

    まずは「ディスクの管理」で、そのHDDのバーがどのような色や名前(未割り当て、正常など)になっているかを確認してみるのが第一歩です。

    今「ディスクの管理」を開いたとき、該当のドライブは何色のバーで表示されていますか?

    macOSを使っています。zipファイルが沢山入っているフォルダがあります。AppleDoubleを削除する必要があります。スクリプトを組みたいのですが、教えてもらえますか。

    macOSを使っています。zipファイルが沢山入っているフォルダがあります。AppleDoubleを削除する必要があります。スクリプトを組みたいのですが、教えてもらえますか。

    macOSでZIPファイル内に含まれる AppleDouble(._ で始まる隠しファイル) を一括削除するには、標準の zip コマンドの削除オプション(-d)を利用したシェルスクリプトが効率的です。 

    以下のスクリプトは、指定したフォルダ内のすべての .zip ファイルを走査し、内部の __MACOSX ディレクトリや ._ ファイルを削除します。

    AppleDouble 削除用シェルスクリプト

    bash

    #!/bin/bash
    
    # 対象のフォルダパスを指定(例: ~/Documents/zips)
    TARGET_DIR="パスを入力してください"
    
    # フォルダが存在するか確認
    if [ ! -d "$TARGET_DIR" ]; then
      echo "Error: Directory $TARGET_DIR does not exist."
      exit 1
    fi
    
    # フォルダ内の全zipファイルに対してループ処理
    find "$TARGET_DIR" -name "*.zip" -type f | while read -r zip_file; do
      echo "Processing: $zip_file"
      
      # zip内の AppleDouble 関連ファイルを削除
      # "__MACOSX/*" : リソースフォークが格納されるディレクトリ
      # "*/._*" : ファイル単位の AppleDouble ヘッダー
      zip -d "$zip_file" "__MACOSX/*" "*/._*" "._*" > /dev/null 2>&1
      
      if [ $? -eq 0 ]; then
        echo "  -> Cleaned successfully."
      else
        echo "  -> No AppleDouble files found or error occurred."
      fi
    done
    
    echo "Done."
    

    使い方

    1. テキストエディタ(標準の「テキストエディット」や VS Code など)を開き、上記をコピー&ペーストします。
    2. TARGET_DIR="パスを入力してください" の部分を、実際のフォルダパス(例:"/Users/あなたの名前/Desktop/test")に書き換えます。
    3. clean_zip.sh という名前で保存します。
    4. ターミナルを開き、以下のコマンドで実行権限を与えて実行します。bashchmod +x clean_zip.sh ./clean_zip.sh コードは注意してご使用ください。

    補足事項

    • AppleDoubleとは: macOS特有の「リソースフォーク(アイコン情報やメタデータ)」を、macOS以外のシステム(WindowsやLinux)でも保持するために生成される ._ から始まるヘッダーファイルのことです。
    • zip -d オプション: ZIPファイルを展開することなく、内部の特定のファイルのみを削除できるため、ファイル数が多い場合に非常に高速です。
    • 注意: スクリプトを実行する前に、念のためフォルダのバックアップを取っておくことをお勧めします。 

    特定のフォルダではなく、デスクトップ上のすべてのZIPを対象にするなど、さらに絞り込みが必要な場合は教えてください。

    ubuntuでRAID5のアレイが起動時にマウントされない。起動後に手動でsudo mount -aならマウントされる。原因はなんだろう。

    ubuntuでRAID5のアレイが起動時にマウントされない。起動後に手動でsudo mount -aならマウントされる。原因はなんだろう。

    場合、主な原因は「アレイの準備が整う前にシステムがマウントを試みている(タイミングの問題)」か、「初期RAMディスク(initramfs)内のRAID設定が古い」ことのいずれかです。 

    以下の手順で修正を試みてください。

    1. RAID設定情報の更新と反映

    RAIDの構成情報(UUIDなど)を最新の状態にして、OS起動の初期段階で読み込めるようにします。 

    1. 現在のRAID構成情報を設定ファイルに書き出す:bash# 既存の設定をバックアップ sudo cp /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf.bak # 現在の状態をスキャンして反映 sudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf
    2. initramfsを更新する:
      OS起動時にRAIDを認識させるため、この手順が最も重要です。bashsudo update-initramfs -u

    2. /etc/fstab のマウントオプション調整 

    RAIDデバイスの準備が遅れる場合に備え、マウントオプションに defaults だけでなく、準備を待つための設定を追加します。 

    • 推奨設定例:
      /etc/fstab 内の対象行を以下のように書き換えます(UUIDは blkid コマンドで確認してください)。textUUID=あなたのRAIDアレイUUID /mnt/mountpoint ext4 defaults,nofail,x-systemd.device-timeout=30 0 2
      • nofail: デバイスが見つからなくても起動を止めないようにします。
      • x-systemd.device-timeout=30: デバイスが現れるのを最大30秒待ちます。 

    3. デバイス名の不一致の確認

    起動時にRAIDアレイが /dev/md0 ではなく、/dev/md127 など別の名前で認識されている場合があります。 

    • 対策/etc/fstab でのマウント指定を /dev/md0 のようなデバイス名ではなく、必ず UUID を使用するようにしてください。UUIDは以下のコマンドで取得できます。bashsudo blkid /dev/md0 # または現在のRAIDデバイス名

    これらの設定を行った後、再起動して自動マウントされるか確認してください。

    現在の /etc/fstab の設定内容や、起動直後の cat /proc/mdstat の結果を教えていただければ、より具体的な診断が可能です。

    UUID=c2bc4e5e-895c-45ea-b798-99e6fcc97b05 /mnt/nas10tb ext4 defaults 0 1Personalities : [raid6] [raid5] [raid4] [raid0] [raid1] [raid10] md0 : active raid5 sde1[4] sdb1[1] sdf1[3] sdc1[0] sdg1[5] sdd1[2] 9766924800 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU] bitmap: 0/15 pages [0KB], 65536KB chunkです。

    ご提示いただいた 

    fstab と mdstat の情報を確認しました。RAID 5アレイ自体は正常に md0 として組まれていますが、現在の fstab 設定では「OSがRAIDの準備完了を待たずにマウントを試みて失敗している」可能性が高いです。 

    以下の3ステップで確実に解決できます。

    1. fstab の記述を「待機型」に修正

    現在の設定 defaults 0 1 では、起動プロセスの非常に早い段階でマウントが行われます。これを systemd に「デバイスが現れるまで待つ」よう指示するオプションに変更します。

    • 修正前UUID=c2bc4e5e-895c-45ea-b798-99e6fcc97b05 /mnt/nas10tb ext4 defaults 0 1
    • 修正後:textUUID=c2bc4e5e-895c-45ea-b798-99e6fcc97b05 /mnt/nas10tb ext4 defaults,nofail,x-systemd.device-timeout=30 0 2
      • nofail: 万が一RAIDが組めなかった時にOS起動が止まるのを防ぎます。
      • x-systemd.device-timeout=30: デバイスが認識されるまで最大30秒待機させます。
      • 末尾の 1 を 2 に変更: ルートパーティション以外のチェック優先度を下げます。 

    2. mdadm設定の更新と initramfs への反映 

    Ubuntuの起動初期段階(initramfs)でRAIDを正しく認識させるため、現在の構成情報を同期させます。これを怠ると、起動時に一時的に md127 など別の名前で認識され、UUIDでの紐付けが間に合わないことがあります。 

    1. 設定ファイルを現在の状態に更新:bashsudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf
    2. 起動イメージを再生成:bashsudo update-initramfs -u

    3. 原因の切り分け(確認用)

    もし上記でも解決しない場合は、起動時に何が起きているかログで確認できます。 

    • エラーログの確認:bashjournalctl -b | grep nas10tb コードは注意してご使用ください。「Dependency failed」や「Timed out waiting for device」といったメッセージがあれば、やはりタイミングの問題です。

    次に再起動する際、上記の設定変更が完了していれば自動でマウントされるはずです。 設定反映後に一度再起動を試してみてください。

    やってみましたが、マウントされません。Feb 21 18:14:51 ubuntu-nas systemd[1]: Dependency failed for mnt-nas10tb.mount – /mnt/nas10tb.Feb 21 18:14:51 ubuntu-nas systemd[1]: mnt-nas10tb.mount: Job mnt-nas10tb.mount/start failed with result ‘dependency’.

    Dependency failed」というエラーは、systemdが「マウントしようとしたが、その前提となるRAIDデバイス(md0)が時間内に準備されなかった」ことを示しています。

    sudo mount -a で成功することから、RAID自体は正常ですが、OS起動の非常に早い段階でRAIDを組み立てるプロセスがスキップされている、あるいは間に合っていないのが原因です。

    以下の「強制的」な解決策を試してください。

    1. mdadmの自動組み立てを強制する

    Ubuntuの最近のバージョンでは、mdadm の設定ファイルに不整合があると、起動時の自動組み立てを止めてしまうことがあります。

    1. /etc/mdadm/mdadm.conf をクリーンにする:
      一度ファイルを空にしてから、現在の正しい構成情報だけを書き込みます。bash# バックアップを取る sudo cp /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf.bak2 # 基本設定とスキャン結果を書き込む echo "DEVICE partitions" | sudo tee /etc/mdadm/mdadm.conf sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
    2. initramfsを再度、強制更新:bashsudo update-initramfs -u -k all

    2. systemd のマウント順序を明示的に指定する

    fstab の設定だけでは不十分な場合、systemdに対して「RAID管理サービスが完了してからマウントしてくれ」と明示します。

    • /etc/fstab を以下に書き換え:
      オプションに x-systemd.after=mdmonitor.service を追加します。textUUID=c2bc4e5e-895c-45ea-b798-99e6fcc97b05 /mnt/nas10tb ext4 defaults,nofail,x-systemd.device-timeout=30,x-systemd.after=mdmonitor.service 0 2

    3. それでもダメな場合の最終手段(起動スクリプト)

    特定のハードウェア構成でどうしても認識が遅れる場合、起動後に自動で mount -a を実行させるサービスを作ります。

    1. 新しいサービスファイルを作成:
      sudo nano /etc/systemd/system/mount-raid-fix.service
    2. 以下を貼り付け:ini[Unit] Description=Force Mount RAID after boot After=local-fs.target [Service] Type=oneshot ExecStart=/bin/mount -a RemainAfterExit=yes [Install] WantedBy=multi-user.target
    3. サービスを有効化:bashsudo systemctl daemon-reload sudo systemctl enable mount-raid-fix.service

    まずは 手順1と2 をセットで実施し、再起動してみてください。

    これらの手順を試した後もエラーが出る場合、起動直後の lsblk の結果(特にRAIDが md127 などに化けていないか)を確認させていただけますか?

    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTSloop0 7:0 0 13M 1 loop /snap/canonical-livepatch/378loop1 7:1 0 74M 1 loop /snap/core22/2292loop2 7:2 0 48.1M 1 loop /snap/snapd/25935sda 8:0 0 223.6G 0 disk ├─sda1 8:1 0 1G 0 part /boot/efi└─sda2 8:2 0 222.5G 0 part /sdb 8:16 0 1.8T 0 disk └─sdb1 8:17 0 1.8T 0 part └─md0 9:0 0 9.1T 0 raid5 sdc 8:32 0 1.8T 0 disk └─sdc1 8:33 0 1.8T 0 part └─md0 9:0 0 9.1T 0 raid5 sdd 8:48 0 1.8T 0 disk └─sdd1 8:49 0 1.8T 0 part └─md0 9:0 0 9.1T 0 raid5 sde 8:64 0 1.8T 0 disk └─sde1 8:65 0 1.8T 0 part └─md0 9:0 0 9.1T 0 raid5 sdf 8:80 0 1.8T 0 disk └─sdf1 8:81 0 1.8T 0 part └─md0 9:0 0 9.1T 0 raid5 sdg 8:96 0 1.8T 0 disk └─sdg1 8:97 0 1.8T 0 part └─md0 9:0 0 9.1T 0 raid5 マウントされません

    lsblk

     の結果を見ると、RAIDアレイ自体は正常に md0 として組み上がっています。それなのにマウントされないのは、**「systemdがUUIDを見失っている」「ファイルシステムのチェック(fsck)で止まっている」**可能性が高いです。

    特に10TBという大容量のため、起動時の微細なタイミングのズレが影響しています。

    以下の手順で、fstab の記述を**「UUID」ではなく「デバイスパス」による指定**に切り替えて、依存関係を強制解決しましょう。

    1. /etc/fstab の書き換え

    UUIDでの指定がうまくいかない(認識が遅れる)場合、/dev/md0 という直接のパスを指定するのが最も確実です。

    /etc/fstab を開き、対象の行を以下のように書き換えてください。

    text

    /dev/md0  /mnt/nas10tb  ext4  defaults,nofail,x-systemd.before=zfs-mount.service,x-systemd.device-timeout=60  0  0
    
    • ポイント:
      • UUID=... ではなく /dev/md0 を直接指定。
      • 末尾を 0 0 にして、起動時の fsck(ディスクチェック)をスキップ させます(これが原因でマウントがブロックされることが多いため)。
      • x-systemd.device-timeout=60: 待機時間をさらに伸ばします。

    2. mdadm 設定を「名前」で固定する

    OSが md0 という名前を確実に保持するようにします。

    1. /etc/mdadm/mdadm.conf を編集します。bashsudo nano /etc/mdadm/mdadm.conf コードは注意してご使用ください。
    2. ARRAY で始まる行の末尾に name=0 がなければ追加、あるいは以下のような形式になっているか確認してください。textARRAY /dev/md0 metadata=1.2 name=0 UUID=(あなたのRAIDのUUID) コードは注意してご使用ください。※ name=0 を入れることで、/dev/md0 として固定されやすくなります。
    3. 設定を反映:bashsudo update-initramfs -u

    3. マウントポイントのパーミッション確認

    念のため、マウント先が原因でないか確認します。

    bash

    sudo chown $USER:$USER /mnt/nas10tb
    

    これで解決しない場合:
    起動直後に mount コマンドを叩かずに、以下のコマンドの結果を見てください。

    • systemctl status mnt-nas10tb.mount

    ここで「Time out」が出ているか、別のエラーが出ているかで最後の一手が決まります。まずは fstab の 0 1 を 0 0 に変えること を優先して試してみてください。

    再起動後、自動でマウントされているか、または状況に変化はありましたか?

    ● mnt-nas10tb.mount – /mnt/nas10tb Loaded: loaded (/etc/fstab; generated) Active: active (mounted) since Sat 2026-02-21 18:33:12 JST; 1min 36s ago Where: /mnt/nas10tb What: /dev/md0 Docs: man:fstab(5) man:systemd-fstab-generator(8) Tasks: 0 (limit: 28608) Memory: 6.7M (peak: 7.2M) CPU: 66ms CGroup: /system.slice/mnt-nas10tb.mountFeb 21 18:33:12 ubuntu-nas systemd[1]: Mounting mnt-nas10tb.mount – /mnt/nas10tb…Feb 21 18:33:12 ubuntu-nas systemd[1]: Mounted mnt-nas10tb.mount – /mnt/nas10tb.マウントされました。

    ついにマウントされましたね!良かったです。

    結果を見る限り、今回の原因は「UUIDの解決タイミング」「起動時のディスクチェック(fsck)」の合わせ技だった可能性が高いです。

    大容量(10TB)のRAIDアレイの場合、起動時にOSが「このUUIDはどこだ?」と探している間にタイムアウトしたり、バックグラウンドでfsckが走ってマウントをブロックしたりすることがよくあります。

    今回の設定のポイントをまとめておきます:

    • /dev/md0 直指定: UUIDの解決を待たずにデバイスに直結。
    • 末尾 0 0: 巨大なアレイの起動時チェックをスキップして即マウント。
    • タイムアウト延長: ストレージの回転やRAIDの組み立て時間を確保。

    このまま運用して問題ありませんが、ディスクチェックをスキップする設定にしたので、数ヶ月に一度は手動でファイルシステムの整合性チェック(fsck)や、RAIDの不一致チェック(scrubbing)を行うことをおすすめします。

    RAIDの健康状態チェック(たまに実行すると安心です):

    bash

    # RAIDの不一致チェックを開始
    echo check | sudo tee /sys/block/md0/md/sync_action
    

    快適なNASライフを!他にお困りのことがあればいつでも聞いてください。

    zshでwhich rsyncとしたら、rsync: aliased to noglob rsyncと出ました。rsyncのフルパスを知りたいのですが、どこなんでしょう。

    zshでwhich rsyncとしたら、rsync: aliased to noglob rsyncと出ました。rsyncのフルパスを知りたいのですが、どこなんでしょう。

    エイリアスが設定されていると、通常のwhichではそのエイリアスの内容が表示されてしまいますね。

    rsyncの実行ファイルのフルパスを確認するには、以下のいずれかのコマンドを試してみてください。

    1. where コマンドを使う (zshの組み込みコマンド)

    zshではwhereを使うと、エイリアス、関数、そして実行ファイルのパスをすべて列挙してくれます。

    zsh

    where rsync
    

    2. command を頭につける

    エイリアスを無視してコマンドを探すよう指示できます。

    zsh

    which -a rsync
    # または
    command -v rsync
    

    3. バックスラッシュを頭につける

    一時的にエイリアスを無効化して場所を特定します。

    zsh

    which \rsync
    

    おそらく /usr/bin/rsync や(Homebrewを入れている場合は) /opt/homebrew/bin/rsync などが表示されるはずです。

    ちなみに、その noglob というエイリアスは、リモートパスを指定する際の [ や * などの記号をzshが勝手に展開してエラーになるのを防ぐために設定されている便利なものですよ。

    パスは無事に見つかりそうですか?もし特定のバージョンのrsyncを探しているなら、その旨教えてください!

    crontabでrsyncを使いたいのですが、フルパスじゃ無いとダメですよね。

    はい、基本的には

    フルパスで記述するのが確実です。

    cronは、あなたが普段使っているシェル(zshなど)とは異なり、非常に限られた環境変数(PATH)しか持っていません。そのため、エイリアスも効きませんし、rsync という名前だけではコマンドを見つけられず、実行に失敗することがよくあります。 

    rsyncのパスを確認して設定する方法

    1. パスを確認する
      ターミナルで以下のコマンドを打ち、表示されたパス(例: /usr/bin/rsync)をコピーしてください。
      zsh
      command -v rsync
    2. crontabに記述する
      crontab (crontab -e) には、確認したフルパスを使って記述します。
      cron
      # 例:毎日深夜3時に実行する場合 0 3 * * * /usr/bin/rsync -av /src/dir /dest/dir

    補足:エイリアス(noglob)について

    あなたのzshで表示された noglob は「ワイルドカード(*など)をシェルに展開させない」ための設定ですが、cronはそもそも別のシェル(通常は /bin/sh)で動くため、このエイリアスは引き継がれません。cronでワイルドカードを使いたい場合は、そのまま記述して問題ありません。

    もしパスを指定しても動かない場合は、crontabの冒頭に PATH を定義するという解決策もあります。

    設定しようとしているバックアップ先は、同じPC内(ローカル)ですか?それともリモートサーバーですか?

    リモートサーバーですね。

    リモートサーバーへのバックアップをcrontabで自動化する場合、「パスの指定」に加えて「認証の自動化」が非常に重要になります。

    cronはパスワード入力を待つことができないため、手動で実行するときのようにパスワードを打つことができません。以下の3つのポイントを押さえて設定してください。

    1. rsyncコマンドをフルパスで書く 先ほど確認した通り、/usr/bin/rsync などのフルパスを使用します。 

    2. SSH鍵認証(パスワードレス)を設定する 

    パスワードなしでログインできるように、SSH公開鍵認証を設定しておく必要があります。 

    • 鍵の作成ssh-keygen -t ed25519(パスフレーズは空にする)
    • 鍵の転送ssh-copy-id ユーザ名@リモートサーバー
    • 確認ssh ユーザ名@リモートサーバー でパスワードなしでログインできればOKです。 

    3. crontabの記述例

    秘密鍵の場所を明示的に指定(-e "ssh -i /path/to/key")しておくと、cron環境でも確実に動作します。 

    cron

    # 毎日午前2時にリモートサーバーへバックアップ
    0 2 * * * /usr/bin/rsync -avz -e "ssh -i /home/yourname/.ssh/id_ed25519" /local/dir/ ユーザ名@リモートサーバー:/remote/dir/
    

    💡 運用上の注意点

    • noglobの代わり: cronでワイルドカード(*など)を使いたい場合は、そのまま書いて大丈夫です(zshのエイリアスを気にする必要はありません)。
    • ログの保存: 何かあったときに原因がわかるよう、ログを出力させるのがおすすめです。
      • 末尾に >> /home/yourname/rsync.log 2>&1 を足すと、実行結果がファイルに記録されます。 

    すでにSSHの公開鍵認証でのログインは設定済みでしょうか?それともこれから設定されますか?

    公開鍵は作成済みで設定済みです。

    公開鍵認証の設定済みとのことですので、あとは 

    crontab特有の環境 に合わせた記述をするだけです。

    以下の点に注意して設定を完成させてください。

    1. 秘密鍵のパスを明示する

    cron環境では普段のSSH設定(~/.ssh/configなど)を読み込まない場合があるため、-e オプションで秘密鍵を指定するのが最も確実です。 

    2. crontabへの記述例

    ターミナルで crontab -e を実行し、以下のような形式で記述します。

    cron

    # 毎日午前3時に実行(パスはご自身の環境に合わせて適宜書き換えてください)
    0 3 * * * /usr/bin/rsync -avz -e "/usr/bin/ssh -i /home/yourname/.ssh/id_ed25519" /local/dir/ user@remote-host:/remote/dir/
    
    • /usr/bin/rsync: 先ほど確認したフルパスを使います。
    • -e "/usr/bin/ssh -i ...": SSHコマンドもフルパスで書き、秘密鍵の場所を指定します。
    • 末尾の /: 送信元ディレクトリの末尾に / をつけると「中身だけ」を、つけないと「ディレクトリごと」コピーします。 

    3. ログを出力して確認する

    cronはエラーが起きても画面に表示されないため、ログファイルに書き出す設定を強く推奨します。

    cron

    0 3 * * * (上記コマンド) >> /home/yourname/rsync.log 2>&1
    

    💡 最後のチェックポイント

    cronで実行する前に、一度ターミナルから「フルパスを使った状態」でコマンドを叩いてみてください。 そこでパスワードを聞かれずに同期が完了すれば、crontabでもそのまま動くはずです。

    もし実行時に「Host key verification failed」というエラーが出る場合は、一度手動でSSH接続して Known Hosts に登録する必要がありますが、そのあたりは大丈夫そうですか?

    OKです。

    バッチリですね!これで自動バックアップの準備は万端です。

    もし実際に動かしてみて「なぜか同期されない」「ログにエラーが出る」といったことがあれば、ディレクトリの権限設定や、リモート側のrsyncパスが原因のこともありますので、いつでも相談してください。

    念のため、実行時間を1分後くらいに設定したテスト用の1行をcrontabに書き込んで、実際に動くか最終確認してみるのがおすすめですよ!

    今回はバックアップのログも保存するように設定しますか?

    初回のバックアップになるので、ログは見たいですね。

    初回のバックアップは転送量も多く、予期せぬエラーが出る可能性も高いため、詳細なログを残すのが正解です。

    通常の -avz に、詳細を表示する -v をもう一つ重ねたり、進捗を表示するオプションを組み合わせると状況が把握しやすくなります。

    ログ出力付きの crontab 記述例

    以下の内容を crontab -e に記述してください。

    cron

    # 毎日午前3時に実行し、ログを日付付きで保存
    0 3 * * * /usr/bin/rsync -avvz -e "/usr/bin/ssh -i /home/yourname/.ssh/id_ed25519" /local/dir/ user@remote-host:/remote/dir/ >> /home/yourname/rsync_$(date +\%Y\%m\%d).log 2>&1
    

    コードは注意してご使用ください。

    ログを詳細かつ見やすくするためのポイント

    1. 詳細モード (-vv)-v を2つ重ねることで、どのファイルがスキップされたか、なぜ転送されたかなどの詳細が出力されます。
    2. 日付付きファイル名 ($(date +\%Y\%m\%d)): 毎日ログファイルが分かれるので、後から確認しやすくなります。
      • ※ crontab内では % は特別な意味を持つため、\% とエスケープする必要があります。
    3. 標準エラー出力の統合 (2>&1): これを書くことで、正常なログだけでなく「エラーメッセージ」も同じファイルに書き込まれます。

    実行後の確認方法

    バックアップが開始されたら、別のターミナルで以下のコマンドを打つと、リアルタイムで転送状況を確認できます。

    zsh

    tail -f /home/yourname/rsync_202XMMDD.log
    

    コードは注意してご使用ください。

    初回はデータ量が多いと思いますが、無事に完走することを祈っています!
    転送するファイルの総量(GB単位など)はかなり大きいのでしょうか?

    Macosのzshで、フォルダを圧縮したい。中にはjpgファイルが入っているのだけど、フォルダが階層になっている部分がある。圧縮するのはjpgファイルが入っているフォルダだけ。できるかな。

    Macosのzshで、フォルダを圧縮したい。中にはjpgファイルが入っているのだけど、フォルダが階層になっている部分がある。圧縮するのはjpgファイルが入っているフォルダだけ。できるかな。

    MacOSのzshを使用して、

    JPGファイルが含まれているフォルダのみを個別に(または再帰的に)圧縮することは可能です。

    フォルダ階層を維持したまま、特定の条件(JPGの有無)でフィルタリングして圧縮する方法をいくつか紹介します。

    1. JPGが含まれる各フォルダを個別にZIPにする

    JPGファイルが直接入っているフォルダを特定し、そのフォルダごとにZIPファイルを作成するコマンドです。

    zsh

    
    
    for dir in **/*(/); do
      if [[ -n $(ls "$dir"/*.jpg 2>/dev/null) ]]; then
        zip -r "${dir%/}.zip" "$dir"
      fi
    done
    • **/*(/):現在のディレクトリ以下のすべてのディレクトリを再帰的に探します。
    • ls "$dir"/*.jpg:各ディレクトリ内にJPGがあるかチェックします。
    • zip -r "${dir%/}.zip" "$dir":見つかった場合、そのフォルダ名でZIPを作成します。 

    2.JPGファイルのみを抽出して一つのZIPにまとめる(階層維持)

    特定のJPGファイルだけを抜き出し、元の階層構造を保ったまま一つのZIPにまとめたい場合は、findコマンドと組み合わせるのが確実です。

    zsh

    find . -name "*.jpg" | zip -@ result.zip
    
    • find . -name "*.jpg":JPGファイルだけを再帰的に探し出します。
    • zip -@ result.zip:渡されたファイルリストを受け取り、階層を維持したまま result.zip に圧縮します。 

    3. Mac特有の不要ファイルを除外する

    MacでZIPを作成すると、Windows等で展開した際に __MACOSX や .DS_Store といった不要なファイルが混入することがあります。これらを除外して圧縮するには -x オプションを追加してください。 

    zsh

    zip -r output.zip target_folder -x "*.DS_Store" -x "__MACOSX/*"
    

    実行前の注意点

    • テスト実行: 大事なファイルを操作する前に、コピーしたフォルダなどで動作を確認することをおすすめします。
    • 大文字・小文字.jpg と .JPG が混在している場合は、-name "*.[jJ][pP][gG]" のように指定すると両方にヒットします。

    作成したZIPファイルをどこに保存したいか(各フォルダ内か、デスクトップかなど)によって最適なコマンドが変わりますが、まずは1つ目の方法がご希望に近いかと思います。

    うまくいっています(今テスト中)。ただ、AppleDoubleファイル(._)

    うまくいっているようで良かったです!

    Mac特有のAppleDoubleファイル(._から始まる隠しファイル)は、外部とのやり取りで邪魔になることが多いですよね。

    それらを除外して圧縮するには、zipコマンドに -x オプションを追加して、明示的に「ドットから始まり、アンダースコアが続くファイル」を無視するように指定します。

    先ほどの1番のスクリプトを改良すると、以下のようになります:

    zsh

    for dir in **/*(/); do
      if [[ -n $(ls "$dir"/*.jpg 2>/dev/null) ]]; then
        # -x オプションで ._ ファイルと .DS_Store を除外
        zip -r "${dir%/}.zip" "$dir" -x "*/.*"
      fi
    done
    

    ポイント

    • -x "*/.*": これを指定することで、フォルダ内の ._filename や .DS_Store といった隠しファイルを一括で除外できます。
    • もしすでに環境変数で COPYFILE_DISABLE=1 が設定されていれば作成されにくいのですが、コマンド側で制御するのが最も確実です。

    さらに徹底して除外したい場合は、圧縮コマンドの前に一時的にメタファイルを生成しない設定を加えることもできます:

    zsh

    export COPYFILE_DISABLE=1
    # この後に zip コマンドを実行
    

    テスト中のフォルダで、生成されたZIPの中に ._ ファイルが含まれていないか、unzip -l ファイル名.zip で中身をリスト表示して確認してみてください。

    このまま全てのフォルダを一括で処理する段階に進んでも大丈夫そうですか?

    大丈夫そうです。ありがとうございました。

    よかったです!テストも無事に終わったようで安心しました。

    最後に一点だけ補足ですが、もし大量のフォルダを処理した後に、作成されたZIPファイルが正しいか不安になった場合は、以下のコマンドでZIPファイルの中身(ファイル名)を一覧表示してサクッと確認できます。

    zsh

    unzip -l 作成したファイル名.zip
    

    これで ._ ファイルが消えていれば完璧です。

    それでは、一括処理頑張ってください!また何かあればいつでも聞いてくださいね。

    JPG以外のファイル形式(pngやheicなど)も対象に含めたくなった場合は、またお知らせください。

    jpgとjpegが混在しているファイルがありました。

    jpg と jpeg、さらに大文字の JPG などが混在していても、一括で判定できるようにスクリプトを少し拡張しましょう。 

    zshの「ワイルドカード(グロブ)」という機能を使うと、複数の拡張子をまとめて指定できます。

    修正版スクリプト

    以下のコマンドは、jpgjpeg、さらにそれらの大文字(JPGJPEG)のいずれかが含まれるフォルダを対象にします。

    zsh

    for dir in **/*(/); do
      # jpg または jpeg (大文字小文字を問わない) があるかチェック
      if [[ -n $(ls "$dir"/*.(#i)(jpg|jpeg) 2>/dev/null) ]]; then
        zip -r "${dir%/}.zip" "$dir" -x "*/.*"
      fi
    done
    

    変更のポイント

    1. (#i): これを付けると、それ以降のパターンが大文字・小文字を区別しなくなります(jpg も JPG もヒットします)。
    2. (jpg|jpeg): 「または」を意味する書き方で、両方の拡張子をチェック対象に含めます。
    3. 事前に必要な設定: もしエラーが出る場合は、ターミナルで一度だけ setopt extended_glob を実行してください(zshの高度な検索機能を有効にします)。 

    これで、拡張子がバラバラでも「画像が入っているフォルダ」を漏れなく圧縮できるはずです。 

    もし特定のフォルダだけ除外したい、あるいは圧縮後に元のフォルダを削除したいといった追加のご要望があれば、教えてくださいね。

    テーマを変えてみた

    テーマを変えてみた

    このブログなんとも殺風景なので、ブログテーマを変えてみた。BlogghiamoというThemeで、変更箇所というとブログヘッダーに並んでいたソーシャルアイコン群を非表示にしたぐらい。あとはこのThemeにあらかじめ組み込まれていたカテゴリーを削除した。

    シンプルな見た目はそのままに少し色づいて見た目はいい感じになったと思っている。まぁ、見る人は少ないと思うけどね。

    This website stores cookies on your computer. These cookies are used to provide a more personalized experience and to track your whereabouts around our website in compliance with the European General Data Protection Regulation. If you decide to to opt-out of any future tracking, a cookie will be setup in your browser to remember this choice for one year.

    Accept or Deny