greggbjensen / helm-crushftp

Helm chart and docker image for CrushFTP server.
MIT License
7 stars 7 forks source link

config not found after pod-restart #22

Open BernhardHaider opened 2 years ago

BernhardHaider commented 2 years ago

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 commented 2 years ago

Having the same exact issue

greggbjensen commented 2 years ago

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 commented 2 years ago

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

spinkb commented 2 years ago

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 commented 1 year ago

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

BernhardHaider commented 1 year ago

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 GitHubhttps://github.com/greggbjensen/helm-crushftp/issues/22#issuecomment-1658001693, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AN3S3FFRL4UB5V37PFQ6U3LXS53AXANCNFSM5XMVLIMA. You are receiving this because you authored the thread.Message ID: @.**@.>>

ChantalSchot commented 1 year ago

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 commented 1 year ago

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 GitHubhttps://github.com/greggbjensen/helm-crushftp/issues/22#issuecomment-1658197986, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AN3S3FAKTT2UK2ML3V7BSQTXS6KEJANCNFSM5XMVLIMA. You are receiving this because you authored the thread.Message ID: @.**@.>>

greggbjensen commented 1 year ago

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

ChantalSchot commented 1 year ago

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?