rokkonet (original) (raw)
2024 Sep. 19.
環境:Xubuntu 24.04 LTS
マウントオプションに"_netdev,x-systemd.automount"を記述する。
"_netdev"だけではマウントに失敗する。
"x-systemd.automount"はアクセスしたときにだけリモートファイルシステムをマウントする。
/etc/fstab
192.168.1.10:/SERVER/DIR /CLIENT/DIR nfs rw,noatime,hard,_netdev,x-systemd.automount 0 0
システム起動直後に"$ mount"でマウント状況を見てもマウントされていないが、"$ ls /CLIENT/DIR"とすると正常に出力され、それ以後は"$ mount"の出力にも表示される。
Chat GPTより
1. _netdevオプションの役割
_netdevオプションは、ネットワークに依存するファイルシステムであることを指定し、システム起動時にネットワークが使用可能になるまでマウントを遅延させる効果があります。これにより、NFSなどのネットワークファイルシステムが、ネットワークが利用可能でないタイミングでマウントされるのを防ぎます。
ただし、_netdevだけでは、システム起動時の依存関係やタイミングの問題が解決されない場合があり、特に起動時の短時間でネットワークが利用可能にならない環境ではマウントに失敗することがあります。この問題は、ネットワークの起動やシステム全体のリソースの初期化にかかる時間に依存します。
2. x-systemd.automountオプションの役割
x-systemd.automountオプションは、systemdによる自動マウントを有効にし、初めてそのファイルシステムにアクセスしたときにマウントを試みる仕組みです。このオプションを使うと、起動時にマウントに失敗しても、ユーザーがファイルシステムにアクセスした時点で再度マウントを試行するため、ネットワークの起動遅延による失敗を回避できます。
なぜ_netdevだけでは失敗するのか?
_netdevだけの場合、起動時のネットワークの状態やサービスの依存関係により、システムがまだネットワーク接続を確立していない段階でマウントが試行される可能性があります。もしその時点でネットワークが完全に起動していなければ、NFSマウントは失敗します。
x-systemd.automountが追加されると、マウントが初回アクセス時まで遅延されるため、ネットワークが確実に利用可能になった後にマウントが実行されるため、成功する可能性が高まります。
結論
_netdevだけでは起動時のタイミングに依存して失敗する場合がある。
x-systemd.automountを追加することで、初回アクセス時にマウントが実行され、タイミングの問題を回避できる。
このため、x-systemd.automountを追加した構成で成功し、_netdevだけでは失敗していたのだと考えられます。
クラウドストレージのディレクトリ構成の確認
$ rclone lsd MYCLOUD:/DIR
- MYCLOUDの途中からタブ補完されるので、ディレクトリ名が不明でもかまわない。
- 直下のディレクトリのみが出力される。
- "rclone lsd MYCLOUD:/"でタブ補完すると / 直下のディレクトリとファイルが表示される。
- "MYCLOUD:"でクラウドドライブを表すので、":"を付け忘れないこと。
"rclone sync"コマンドでのディレクトリの同期について
rclone sync /DIR-A/DIR-B remote:/DIR-A/DIR-B
ローカルの変更をクラウドに同期する時に有益。
rclone sync remote:/DIR-A/DIR-B /DIR-A/DIR-B
クラウドの変更をローカルに同期する時に有益。
(google Geminiより)
ケース1:ローカルのファイルが新しい場合
- rclone sync /DIR-A/DIR-B remote:/DIR-A/DIR-B: ローカルの変更がリモートに反映されます。
- rclone sync remote:/DIR-A/DIR-B /DIR-A/DIR-B: ローカルの新しいファイルで上書きされる可能性があります。(オプション設定によっては上書きされない場合も)
ケース2:リモートのファイルが新しい場合
- rclone sync /DIR-A/DIR-B remote:/DIR-A/DIR-B: ローカルのファイルがリモートの新しいファイルで上書きされます。
- rclone sync remote:/DIR-A/DIR-B /DIR-A/DIR-B: ローカルにリモートの変更が反映されます。
ケース3:ローカルとリモートでファイルが異なる場合
- rclone sync /DIR-A/DIR-B remote:/DIR-A/DIR-B: ローカルの変更が優先され、リモートがローカルに合わせられます。
- rclone sync remote:/DIR-A/DIR-B /DIR-A/DIR-B: リモートの変更が優先され、ローカルがリモートに合わせられます。
"rclone copy --update"コマンドでのファイルの同期について
rclone copy --update /DIR-A/FILE-B REMOTE:/DIR-A/
ローカルの /DIR-A/FILE-B の変更日時が、リモートの REMOTE:/DIR-A/FILE-B の変更日時よりも新しい場合のみ、ローカルのFILE-Bがリモートにコピーされる。
rclone copy --update REMOTE:/DIR-A/FILE-B /DIR-A/
ローカルの /DIR-A/FILE-B の変更日時がリモートの REMOTE:/DIR-A/FILE-B の変更日時よりも新しい場合はコピーが実行されない。
ローカルの /DIR-A/FILE-B の変更日時がリモートの REMOTE:/DIR-A/FILE-B の変更日時よりも古い場合、コピーが実行される。
ローカルの /DIR-A/FILE-Bが存在しない場合、コピーが実行される。
事前準備
コンテナIDを取得する $ docker ps CONTAINER ID : MYCONTAINERID
psコマンドをインストールする $ docker exec -it MYCONTAINERID apt update $ docker exec -it MYCONTAINERID apt install procps
dockerコンテナ内の実行中プロセスをホストOSからのコマンドで調べる
コンテナIDを取得する $ docker exec -it MYCONTAINERID ps aux
2024 May 26.
lessコマンドでascii制御文字を文字コードのまま表示するのは"-R"オプション
$ less -R FILE
2024 May 26.
catコマンドでascii制御文字を文字コードのまま表示するのは"-v"オプション
$ cat -v FILE
dir \SMB.SERVER.IP.ADDRESS\DIR
Linuxシステムにsmbclientをインストールする。
$ sudo apt update && sudo apt-get install smbclient
LinuxシステムでWindowsでの共有名を確認する。
$ smbclient -L //WIN.SERVER.IP.ADDRESS -U WINDOWSUSER
Linuxシステムでマウントする。
$ sudo mount -t cifs //WIN.SERVER.IP.ADDRESS/共有名 /MOUNT/POINT -o username=ユーザー名,password=パスワード