I had the same problem, I looked at the logs of the csi-attacher-s3 pod, first i saw Failed to list *v1beta1.VolumeAttachment: the server could not find the requested resource. I figured it was a k8s version issue, so I updated the container image of the csi-attacher stateful set, from v2.2.1 to canary (the latest).

kubectl -n kube-system set image statefulset/csi-attacher-s3 csi-attacher=quay.io/k8scsi/csi-attacher:canary

Next I got a permission error: `v1.VolumeAttachment: failed to list *v1.VolumeAttachment: volumeattachments.storage.k8s.io is forbidden: User "system:serviceaccount:kube-system:csi-attacher-sa" cannot list resource "volumeattachments" in API group "storage.k8s.io" at the cluster scope.

I tried to modify the role bindings but I couldn't find the right combinations so I ended up giving the csi-attacher-sa service account cluster-admin privileges as shown below:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: csi-attacher-all
subjects:
  - kind: ServiceAccount
    name: csi-attacher-sa
    namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

@fallmo I've had the same problem, but you can just do this and it worked for me.

  - apiGroups: ["storage.k8s.io"]
    resources: ["*"]
    verbs: ["get", "list", "watch", "update", "patch"]

or

  - apiGroups: ["storage.k8s.io"]
    resources: ["volumeattachments","storageclass"]
    verbs: ["get", "list", "watch", "update", "patch"]

Related to #72 (comment)

Mine fixed by using this https://github.com/ctrox/csi-s3/pull/70/files

Related to #72 (comment)

Mine fixed by using this https://github.com/ctrox/csi-s3/pull/70/files

did this and it seemed to work (haven't checked it right after)
but then I decided to pull the latest from the repo and did

cd deploy/kubernetes
kubectl apply -f provisioner.yaml
kubectl apply -f attacher.yaml
kubectl apply -f csi-s3.yaml

which made it work 👍

So for anyone else who came here after realising that since a Kubernetes upgrade they couldn't create/mount new S3 volumes anymore, I'll save you some time;

1. Apply the latest provisioner, attacher and csi-s3 files from https://github.com/ctrox/csi-s3/tree/master/deploy/kubernetes
2. Change the external-attacher-runner ClusterRole to go from resources: ["volumeattachments"] to resources: ["volumeattachments", "volumeattachments/status", "storageclass"]
3. Find quay.io/k8scsi/csi-attacher:v2.2.0 on the csi-attacher-s3 StatefulSet and bump it up a major version to quay.io/k8scsi/csi-attacher:v3.1.0
4. Apply

That should have it working again until the next (seemingly inevitable) breaking change :)

So for anyone else who came here after realising that since a Kubernetes upgrade they couldn't create/mount new S3 volumes anymore, I'll save you some time;

1. Apply the latest provisioner, attacher and csi-s3 files from https://github.com/ctrox/csi-s3/tree/master/deploy/kubernetes
2. Change the external-attacher-runner ClusterRole to go from resources: ["volumeattachments"] to resources: ["volumeattachments", "volumeattachments/status", "storageclass"]
3. Find quay.io/k8scsi/csi-attacher:v2.2.0 on the csi-attacher-s3 StatefulSet and bump it up a major version to quay.io/k8scsi/csi-attacher:v3.1.0
4. Apply

That should have it working again until the next (seemingly inevitable) breaking change :)

After changing the above one pod is went to running state but we are getting this issue.
"root@csi-s3-test-nginx:/var/lib/www/html# ls
ls: reading directory '.': Input/output error
"
Any help on this?

@Venkatesh7591 you save my day, it worked. Thank you!

@Venkatesh7591 Hello I have encountered the same problem, have you solved it now

follow the @RobinJ1995 instructions.

Related to #72 (comment)

Mine fixed by using this https://github.com/ctrox/csi-s3/pull/70/files

Many thanks!

issue #94

this

- apiGroups: ["storage.k8s.io"]
    resources: ["*"]
    verbs: ["get", "list", "watch", "update", "patch"]

work for us