Azure Filesにマウントできない。異なるサブスクリプションかつ同一リージョンの場合は要注意。（mount error(13): Permission denied）

# はじめに
- Azure FilesをVMからマウントする際に、かなりてこずったので調査内容をまとめます。

# 事象
- Azure Files構築後、VMからマウントしようすると以下のエラーが表示されマウントできない。
- VMのGIPをAzure FilesのFWで許可しても以下のエラーとなる。

```
# sudo mount -t cifs //xxxxxxxxxxxxxx.file.core.windows.net/test /mnt/test-azurefiles -o vers=3.0,username=xxxxxxxxxxxxxx,password=yyyyyyyyyyyyyyyyyyy==,dir_mode=0777,file_mode=0777,sec=ntlmssp
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
```

## 環境
### VMの設定
- サブスクリプション：サブスクリプションA
- リージョン：東日本
- その他：GIPを持つ
- kernelバージョン：4.20.6-1.el7.elrepo.x86_64
- OS：Red Hat Enterprise Linux Server release 7.5 (Maipo)

### Azure Filesの設定
- サブスクリプション：サブスクリプションB
- リージョン：東日本
- 安全な転送の設定：有効
- IP制限：有効（上記VMのGIPを許可）

# 原因
- 同一リージョンのVMから、IP制限されたAzure Filesをマウントしようとすると「プライベート通信」になる。
- そのため、VNET経由からのみアクセス可能となる。
- しかし、異なるサブスクリプションかつ異なるAADテナント配下のためVNETの許可をすることができない。
- [公式ドキュメント：インターネットのIPアドレスからアクセスを許可する](https://docs.microsoft.com/en-us/azure/storage/common/storage-network-security?toc=%2fazure%2fvirtual-network%2ftoc.json#grant-access-from-an-internet-ip-range)

# 解決策
- Azure FilesでIP制限を行い、かつ異なるサブスクリプションの環境の場合は、**Azure FilesとVMは別リージョンにする。**

### ダメな設定例（VMが東日本or西日本にある場合）
- VMが東日本or西日本にある場合、以下のようにLRS以外で構成されるとAzure Filesも複数リージョンでレプリケーションされるので気を付けてください。

<img width="558" alt="WS000006.JPG" src="https://qiita-image-store.s3.amazonaws.com/0/168635/043aa5d7-5cfb-eba9-9776-e847d9ac5287.jpeg">

### 構築する際はこの設定（VMが東日本or西日本にある場合）
- VMが存在しないのリージョンでAzure Filesを作成し、LRSにします。
- ※VMを日本リージョンで作成し、Azure Filesを海外リージョンで作成する場合はあまり「レプリケーション」を気にしなくてよいです。
- VMとAzure Filesのリージョンが重複しなければOKなので。

<img width="429" alt="WS000009.JPG" src="https://qiita-image-store.s3.amazonaws.com/0/168635/e9751df5-90b9-927c-8000-beefb4e552be.jpeg">



## 調査過程
### ⑴AWSのEC2からAzure Filesへマウントしてみる
- 結果：マウントOK
    - Azure FilesのIP制限でEC2のGIPは許可済み
- 考察：Azure環境特有の問題の可能性大

### ⑵WindowsからAzure Filesへマウントしてみる
- 結果：マウントOK
    - Azure FilesのIP制限で作業端末のGIPは許可済み
- 考察：KernelやOSのバージョンが影響している可能性あり

### ⑶IP制限なしの状態でSMB3.0とSMB2.1を利用してみる
- 結果：SMB3.0はマウントOK。SMB2.1は「mount error(13): Permission denied」
    - AWSでもAzureのVMでも同様でした
    - 「安全な転送の設定：有効」だからです
- 考察：SMBのバージョンは3.0を使えば行けるので問題なし

### ⑷VMとAzure Filesを同一サブスクリプションにしてマウントしてみる
- 結果：IP制限をしてもしなくてもマウントOK
- 考察：同一サブスクリプションだと発生しない！

### ⑸Kernelのバージョンを変えてみる（3.10と4.20）
- 結果：同一サブスクリプションのVMからマウントすると「mount error(13): Permission denied」
    - AWSのEC2からマウントするとOK
- 考察：Kernelのバージョンは関係なし！完全にAzure間で起こる問題だ！！

### ⑹Azure Filesのリージョンを東日本から東南アジアに変えてみる
- 結果：IP制限をしてもマウントOK
- 考察：リージョンが同一だと通信経路がおかしい？？

### ⑺Azure Filesのリージョンを東日本から西日本に変えてみる
- 結果：「mount error(13): Permission denied」
- 考察：リージョン近いとダメなのか？？？ちょっとわからなくなってきた。。
    - でも東南アジアと東アジアはうまくいった。もうMSに問い合わせよう。。。。。

# まとめ
- Azure Filesを異なるサブスクリプションで利用する場合は、**マウントする側とされる側のリージョンを別にするように意識しましょう。**
    - 【NG】東日本VM（サブスクリプションA）→東日本Azure Files（サブスクリプションB）
    - 【NG】東日本VM（サブスクリプションA）→西日本Azure Files（サブスクリプションB）　★これ本当に疑問。。。。
    - 【OK】東日本VM（サブスクリプションA）→東アジアAzure Files（サブスクリプションB）
    - 【OK】東日本VM（サブスクリプションA）→東南アジアAzure Files（サブスクリプションB）


問い合わせの結果が来たら更新します。。。


# その他
## エラーまとめ
### mount error(115): Operation now in progress
- NSGのアウトバウンドを制限していないか確認してください。

## 参考にしたドキュメントたち
- [Linux での Azure Files に関する問題のトラブルシューティング](https://docs.microsoft.com/ja-jp/azure/storage/files/storage-troubleshoot-linux-file-connection-problems)
- [LEM mount error(115): Operation now in progress
](https://support.solarwinds.com/Success_Center/Log_Event_Manager_(LEM)/Knowledgebase_Articles/LEM_mount_error_115_Operation_now_in_progress)