Longhorn環境でaccessMode:ReadWriteManyを使いたい場合

症状

AWS EC2上に構築したK3sにDifyを導入しようとしたときに問題が出ました。なお、
BorisPolonsky / dify-helm
のhelmファイルを使用させていただきました。
k3sにLonghornを組み合わせましたので、helmのvalue.yamlファイルに「PVCのstorageClassはlonghornを指定するよ」と設定しました。

value.yamlの一部

proxy:
    log:
        persistence:
            persistentVolumeClaim:
                storageClass: longhorn
                accessModes: ReadWriteMany
                size: 1Gi
                subPath: ""

これを、storageClassが出てくるところ全てに記しました。
なので

helm repo add dify https://borispolonsky.github.io/dify-helm
helm repo update
helm install -n dify -f value.yaml dify dify/dify

をやってみて上手く行くかと思いきや、k9sで見てみるとproxyとapiのpodがcontainerCreatingのまま動いてないわけです。どうしたものか。

調査

value.yamlをよく見るとこんなことが書いてあります。

## Dify App Data Persistent Volume Storage Class
## If defined, storageClassName: <storageClass>
## If set to "-", storageClassName: "", which disables dynamic provisioning
## If undefined (the default) or set to null, no storageClassName spec is
##   set, choosing the default provisioner.
## ReadWriteMany access mode required for `api` and `worker`
##

apiとworkerにはReadWriteManyのアクセスモードが必要だよ、と書いてあります(workerじゃなくてproxyの間違いじゃないかと思いますが)。これがヒントになりました。Google検索してみると、
LonghornでReadWriteManyを使用する方法
という記事が見つかりました。

解決

次の手順で解決をみました。k3sがインストールされている各ノードで以下の手順を踏む必要があります。
1.念のため、k3sサービスを止める。
サーバーノード:sudo systemctl stop k3s
エージェントノード：sudo systemctl stop k3s-agent

2.nfs-commonをaptで導入。

sudo apt update
sudo apt install nfs-common

3.k3sサービスを再スタート。
サーバーノード:sudo systemctl start k3s
エージェントノード：sudo systemctl start k3s-agent

以上で、difyが動くようになりました。