config not found after pod-restart

[BernhardHaider]

Hello,
this helm chart for crushftp is great!
we did a test with restarting the pod.
but after that the ftp does not find the config anymore and we cannot login anymore (530 permission denied in browser).
not even the set admin user works.
persistent volume is not delete, the data is still there and mounted.
any idea what can be the issue?

thank you!
kind regards
Bernhard

[kbelosevic]

Having the same exact issue

[greggbjensen]

This is likely because you need to update your Persistent Volume for the config storage. Make sure that your shared.storageClassName is set correctly for your cloud provider, and that it is shown as created in Kubernetes.

Default

shared:
  storageClassName: default

Azure

shared:
  storageClassName: azure-files

Can you post the log output from your CrushFTP pod as it starts up, minus any secure information?

[greggbjensen]

I have also looped in CrushFTP support for some additional input.

[spinkb]

Unfortunately the exact config is not something I am familiar with. But the basic issue is that you are loosing your prefs.XML, ssh key files, and your users/ config folder if you don't have the persistence set correctly. So follow Gregg's advice on the config.

--CrushFTPSupport

[ChantalSchot]

It's been a while, I'm running into the same issue. Any pointers on how to solve this?

[BernhardHaider]

Hi, you need to save it on a persisten volume. Otherwise the config is always lost on pod-restart. That is not correct on the original helm-chart From: Chantal ***@***.***> Sent: Montag, 31. Juli 2023 11:28 To: greggbjensen/helm-crushftp ***@***.***> Cc: Haider Bernhard ***@***.***>; Author ***@***.***> Subject: Re: [greggbjensen/helm-crushftp] config not found after pod-restart (Issue #22) It's been a while, I'm running into the same issue. Any pointers on how to solve this? — Reply to this email directly, view it on GitHub<#22 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AN3S3FFRL4UB5V37PFQ6U3LXS53AXANCNFSM5XMVLIMA>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[ChantalSchot]

The configuration is saved in a persistent volume, but on restart no configuration is imported into the new CrushFTP instance, not even de admin user. I think it may be related to the StorageClass. When I try to use the azure-files StorageClass (I'm trying to run the deployment in an azure k8s environment), I'm getting errors while mounting the volume. I'll probably have to contact our azure system admins so they can help out with mounting the volume properly...

As for this helm chart: would it matter whether a ReadWriteOnce or ReadWriteMany volume is used for the CrushFTP server pod?

[BernhardHaider]

We also use K8S and had to modify the helm-chart. My collegue implemented it and will be back tomorrow then I can send you details about the necessary change From: Chantal ***@***.***> Sent: Montag, 31. Juli 2023 13:37 To: greggbjensen/helm-crushftp ***@***.***> Cc: Haider Bernhard ***@***.***>; Author ***@***.***> Subject: Re: [greggbjensen/helm-crushftp] config not found after pod-restart (Issue #22) The configuration is saved in a persistent volume, but on restart no configuration is imported into the new CrushFTP instance, not even de admin user. I think it may be related to the StorageClass. When I try to use the azure-files StorageClass (I'm trying to run the deployment in an azure k8s environment), I'm getting errors while mounting the volume. I'll probably have to contact our azure system admins so they can help out with mounting the volume properly... — Reply to this email directly, view it on GitHub<#22 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AN3S3FAKTT2UK2ML3V7BSQTXS6KEJANCNFSM5XMVLIMA>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[greggbjensen]

Please submit a pull request if you find a fix needed for the helm-chart. I would be happy to update it.

[ChantalSchot]

We managed to correctly mount the pod to a ReadWriteMany PVC (azure files provisioner), the firewall was blocking access from the pod to the PVC. Now the issue is... it seems like the users folder from config /mnt/config/users is linked to the users folder from CrushFTP /var/opt/CrushFTP10/users/users whereas the admin account is automatically saved in /var/opt/CrushFTP10/users/MainUsers. The MainUsers folder is not symbolically linked to the users folder in the config, so after a restart, the admin account is not actually loaded anymore and I can't even log in to the dashboard..

Any idea how to resolve this? It seems related to the start-up script from the docker container?