次の方法で共有

Linux での Azure Files に関する問題のトラブルシューティング (SMB)

  • [アーティクル]

この記事では、Linux クライアントで SMB Azure ファイル共有を使用するときに発生する可能性のある一般的な問題の一覧を示します。 これらの問題の考えられる原因と解決策についても説明します。

AzFileDiagnostics を使用して症状検出を自動化し、Linux クライアントに正しい前提条件があることを確認できます。 最適なパフォーマンスが得られる環境をセットアップするために役立ちます。 この情報は、Azure ファイル共有のトラブルシューティング ツールでも確認できます。

重要

この記事は SMB 共有にのみ適用されます。 NFS 共有の詳細については、「NFS Azure ファイル共有に関する問題を解決する」を参照してください。

適用対象

ファイル共有の種類 SMB NFS
Standard ファイル共有 (GPv2)、LRS/ZRS
Standard ファイル共有 (GPv2)、GRS/GZRS
Premium ファイル共有 (FileStorage)、LRS/ZRS

ファイルのコピー時にタイムスタンプが失われた

Linux/Unix プラットフォームでは、異なるユーザーがファイル 1 とファイル 2 を所有している場合、 cp -p コマンドは失敗します。

原因

COPYFILE で強制的にフラグを f すると、Unix で cp -p -f が実行されます。 このコマンドでも、所有者でないファイルのタイム スタンプの保持が失敗します。

回避策

ストレージ アカウント ユーザーを使用してファイルをコピーします。

  • str_acc_name=[storage account name]
  • sudo useradd $str_acc_name
  • sudo passwd $str_acc_name
  • su $str_acc_name
  • cp -p filename.txt /share

ls: '<path>' にアクセスできません入出力エラー

ls コマンドを使用して Azure ファイル共有内のファイルを一覧表示しようとすると、ファイルを一覧表示するときにコマンドがハングします。 次のようなエラーが表示されます。

ls: '<path>' にアクセスできません入出力エラー

解決策

この問題が修正されている次のバージョンに Linux カーネルをアップグレードします。

  • 4.4.87 以降
  • 4.9.48 以降
  • 4.12.11 以降
  • 4\.13 以降のすべてのバージョン

シンボリック リンクを作成できない - ln: failed to create symbolic link 't': Operation not supported

原因

既定では、SMB を使用して Linux 上の Azure ファイル共有をマウントしても、シンボリック リンク (symlinks) のサポートは有効になりません。 次のようなエラーが表示される可能性があります。

sudo ln -s linked -n t

ln: failed to create symbolic link 't': Operation not supported

解決策

Linux SMB クライアントは、SMB 2 または 3 プロトコルでの Windows スタイル シンボリック リンクの作成をサポートしていません。 現在のところ、Linux クライアントは、Minshall+French symlinks という別形式のシンボリック リンクを作成操作とフォロー操作の両方でサポートしています。 シンボリック リンクが必要な場合は、"mfsymlinks" マウント オプションを使用できます。 "mfsymlinks" 形式は Mac でも使用されるため、この形式の使用をお勧めします。

シンボリック リンクを使用するには、SMB mount コマンドの末尾に以下を追加します。

,mfsymlinks

そのため、コマンドは次のようになります。

sudo mount -t cifs //<storage-account-name>.file.core.windows.net/<share-name> <mount-point> -o vers=<smb-version>,username=<storage-account-name>,password=<storage-account-key>,dir_mode=0777,file_mode=0777,serverino,mfsymlinks

そのようにすると、wiki で提案されているようにシンボリック リンクを作成することができます。

名前の終わりにスペースまたはドットが含まれるフォルダーまたはファイルにアクセスできない

Linux にマウントされている間、Azure ファイル共有からフォルダーやファイルにアクセスすることはできません。 共有にアクセスしようとすると、du や Is のようなコマンド、あるいはサードパーティ アプリケーションが失敗し、"ファイルまたはディレクトリが存在しません" というエラーが表示されることがあります。しかし、そのようなフォルダーに、Azure portal からファイルをアップロードすることはできます。

原因

フォルダーやファイルは、名前の最後の文字を別の文字にエンコードするシステムからアップロードされました。 Macintosh コンピューターからアップロードされたファイルには、0x20 (スペース) または0X2E (ドット) の代わりに "0xF028" 文字または "0xF029" 文字が含まれる場合があります。

解決策

Linux に共有をマウントするとき、共有で mapchars オプションを使用します。

代替案:

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino

以下を使用します:

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino,mapchars

Azure ストレージ アカウントのライブ マイグレーションに関する DNS の問題

マウントされたファイルシステム上でファイル I/O を行うと、"Host is down" (ホストがダウンしています) または "アクセス許可が拒否されました" というエラーが発生し始めます。 クライアント上の Linux dmesg ログに、次のようなエラーが繰り返し表示されます。

Status code returned 0xc000006d STATUS_LOGON_FAILURE
cifs_setup_session: 2 callbacks suppressed
CIFS VFS: \\contoso.file.core.windows.net Send error in SessSetup = -13

また、サーバーの FQDN が現在接続されている IP アドレスとは異なる IP アドレスに解決されるようになったことも確認できます。 この問題は、アカウントの移行など、サーバーの IP アドレスが変更される可能性があるあらゆるシナリオで発生する可能性があります。 もう 1 つの既知のシナリオは、DNS マッピングが変更される可能性があるため、ストレージ アカウントのフェールオーバーです。

原因

ストレージ アカウントは、容量の負荷分散を目的として、あるストレージ クラスターから別のストレージ クラスターにライブ マイグレーションされる場合があります。 アカウントの移行により、移行先クラスターを指すように DNS マッピングが更新され、Azure Files トラフィックを移行元クラスターから移行先クラスターにリダイレクトするためのトリガーとなります。 これにより、そのアカウントから移行元クラスターへのすべてのトラフィックがブロックされます。 SMB クライアントが DNS 更新プログラムを受け取り、さらにトラフィックを宛先クラスターにリダイレクトすることが期待されます。 しかし、Linux SMB カーネル クライアントのバグにより、このリダイレクトは有効になりません。 その結果、データ トラフィックは、移行後もこのアカウントの処理を停止した移行元クラスターに送信され続けます。

回避策

この問題は、クライアント OS を再起動することで軽減できますが、クライアント OS をアカウント移行に対応した Linux ディストリビューション バージョンにアップグレードしないと、問題が再び発生する可能性があります。

共有のマウントを解除して再マウントすると、一時的に問題が解決しているように見えるかもしれませんが、永続的な解決策ではありません。 クライアントがサーバーに再接続すると、問題が再び発生する可能性があります。 一時的な軽減策は、新しいマウント アクションによって SMB カーネル キャッシュがバイパスされ、ユーザー空間の DNS アドレスが解決されるために発生します。 ただし、カーネル DNS キャッシュは、ネットワーク切断の復旧中に使用されるため、問題が再発する可能性があります。 この動作は、ストレージ アカウントの移行の外部でも保持されます。

この問題を回避するには、カーネル DNS リゾルバー キャッシュをクリアします。

  1. 次のコマンドを実行して、カーネル dns_resolver モジュールの状態を表示します。

    grep '.dns_resolver' /proc/keys

    次の例のようなコマンド出力が表示されます。

    132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: 1

  2. 次のコマンドを実行して、カーネル DNS リゾルバー キャッシュをクリアします。

    sudo keyctl clear $((16#$(grep '.dns_resolver' /proc/keys | cut -f1 -d\ ) ))

  3. カーネル dns_resolver モジュールの状態をもう一度表示します。

    grep '.dns_resolver' /proc/keys

    次の例のようなコマンド出力が表示され、キャッシュが空になったことが示されます。

    132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: empty

  4. 問題を軽減するために、共有のマウントを解除して再マウントします。

Note

一部の古い Linux ディストリビューションでは、軽減手順が機能しない可能性があります。 このような場合、クライアント OS を再起動すると、問題が一時的に解決されます。 永続的な修正のために、ストレージ アカウントにプライベート エンドポイントを追加し、プライベート リンクを使用してファイル共有に接続できます。

ソリューション

永続的な解決を行う場合は、クライアント OS をアカウント移行に対応した Linux ディストリビューション バージョンにアップグレードします。 Linux SMB カーネル クライアントに対するいくつかの修正プログラムが、メインラインの Linux カーネルに提出されています。 次のディストリビューションには修正が含まれています。

  • Ubuntu: 20.04、22.04、24.04、および AKS 22.04 (修正はカーネル バージョン 5.15.0-1068 でロールアウトされます)
  • RHEL: 8.6 以降
  • SLES: 15SP2、15SP3、15SP4、15SP5
  • Azure Linux: 2.0 (修正はカーネル バージョン 5.15.159.1 でロールアウトされます) と 3.0

一部のディストリビューションでは、これらの修正プログラムがバックポートされています。 使用しているディストリビューション バージョンに次の修正プログラムが存在するかどうかを確認できます。

FIPS が有効になっているときに SMB ファイル共有をマウントできない

Linux VM で Federal Information Processing Standard (FIPS) が有効になっている場合、SMB ファイル共有をマウントできません。 クライアントの Linux dmesg ログには、次のようなエラーが表示されます。

kernel: CIFS: VFS: Could not allocate crypto hmac(md5)
kernel: CIFS: VFS: Error -2 during NTLMSSP authentication
kernel: CIFS: VFS: \\contoso.file.core.windows.net Send error in SessSetup = -2
kernel: CIFS: VFS: cifs_mount failed w/return code = -2

重要

FIPS は、米国政府がコンピューター システムのセキュリティと整合性を確保するために使用する一連の標準です。 システムが FIPS モードの場合、これらの標準で概説されている特定の暗号化要件に準拠します。

原因

SMB ファイル共有のクライアントは、MD5 ハッシュ アルゴリズムを必要とする NTLMSSP 認証を使用します。 ただし、FIPS モードでは、MD5 アルゴリズムは FIPS に準拠していないため制限されます。 MD5 は、128 ビットハッシュ値を生成する広く使用されているハッシュ関数です。 ただし、MD5 は暗号化のために安全でないと見なされます。

FIPS モードが有効になっているかどうかを確認する方法

クライアントで FIPS モードが有効になっているかどうかを確認するには、次のコマンドを実行します。 値が 1 に設定されている場合は、FIPS が有効になります。

sudo cat /proc/sys/crypto/fips_enabled

ソリューション

この問題を解決するには、SMB ファイル共有の Kerberos 認証を有効にします。 FIPS が意図せずに有効になっている場合は、 option2 を参照して無効にします。

オプション 1: SMB ファイル共有の Kerberos 認証を有効にする

FIPS が有効になっている Linux VM に SMB ファイル共有をマウントするには、Kerberos/Azure AD 認証を使用します。 詳細については、「Azure Files にアクセスする Linux クライアントに対して SMB 経由で Azure Active Directory 認証を有効にする」を参照してください。

オプション 2: FIPS を無効にして Samba 共有をマウントする

  1. /etc/sysctl.confで、crypto.fips_enabledの sysctl 値を 0 に変更します。

  2. ファイル内のGRUB_CMDLINE_LINUX_DEFAULT/etc/default/grub変更し、パラメーター fips=1を削除します。

  3. 次のコマンドを使用して grub2 構成ファイルを再構築します。

    sudo grub2-mkconfig -o /boot/grub2/grub.cfg

  4. 次のコマンドを使用して、initramfs イメージをリビルドします。

    sudo dracut -fv

  5. VM を再起動してください。

詳細については、Linux ディストリビューターの次のドキュメントを参照してください。

ヘルプが必要ですか?

まだ支援が必要な場合は、問題を迅速に解決するために、サポートにお問い合わせください。

関連項目

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。