Solved 404 in volumes files manager

[mehdi]

Since updating to 7.0, my files manager does not work for volumes : when I go to the volumes tab, my volumes show, correctly, but when I try to access the file manager, it loads indefinitely, and the Network tab of dev tools shows a 404 (on /api/v1/volumes/VOLUME_ID/files/)

Happens with 2 volumes, of type filesystem (1 is considered a mountpoint, the other normal)

Any idea how I can fix that ? OR should I just delete volumes and re-create them ?

[neurokrish]

@mehdi I had the same issue recently. I just deleted those volumes and recreated. Everything shows up in the file manager. Don't know if this will survive a reboot though!

[nebulon]

@mehdi can you try to restart the sftp service from the dashboard and see if this fixes the issue? If so we might have some mounting race somewhere.

[mehdi]

@nebulon Nope, looks like it does not fix the issue. Anything else you want me to try ? If you need access to my instance, I can give it to you.

To be very clear, everything besides the file-manager works properly : the volumes are present in the apps and everything.

[nebulon]

@mehdi can you run docker inspect sftp and check if the volumes are mounted into that container?

[mehdi]

@nebulon It appears that they are mounted :

{
  ...
        "HostConfig": {
            "Binds": [
                "/home/yellowtent/appsdata:/mnt/appsdata",
                "/mnt/volumes:/mnt/volumes",
                "/srv/river_files:/mnt/2f65b84f-398d-434d-8938-307b9bb54d40",
                "/srv/video:/mnt/88a42b1c-4517-4d67-be2b-e2abef19eb0a",
                "/home/yellowtent/boxdata/mail:/mnt/maildata",
                "/home/yellowtent/platformdata/sftp/ssh:/etc/ssh:ro"
            ]
}

(if this is what I am supposed to be looking at)

[nebulon]

@mehdi indeed, this looks ok. Can you further check the logs of the sftp service while reproducing the issue?

[mehdi]

@nebulon

Dec 17 16:41:52 [GET] /files/volume-88a42b1c-4517-4d67-be2b-e2abef19eb0a/
Dec 17 16:41:52 get: /mnt/volumes/88a42b1c-4517-4d67-be2b-e2abef19eb0a as download:false
Dec 17 16:41:52 [404]: not found
Dec 17 16:41:54 [GET] /files/volume-88a42b1c-4517-4d67-be2b-e2abef19eb0a/
Dec 17 16:41:54 get: /mnt/volumes/88a42b1c-4517-4d67-be2b-e2abef19eb0a as download:false
Dec 17 16:41:54 [404]: not found
Dec 17 16:41:58 [GET] /files/volume-88a42b1c-4517-4d67-be2b-e2abef19eb0a/
Dec 17 16:41:58 get: /mnt/volumes/88a42b1c-4517-4d67-be2b-e2abef19eb0a as download:false
Dec 17 16:41:58 [404]: not found

[mehdi]

It seems the path is different : it's mounted at /mnt/88a42b1c-4517-4d67-be2b-e2abef19eb0a but the file manager looks for it at /mnt/volumes/88a42b1c-4517-4d67-be2b-e2abef19eb0a

[mehdi]

@nebulon Any way I can help you more on how to debug this ?

[girish]

@mehdi can you drop me us a mail to support@ with access to the server? I can try to debug what's happening. Would be good to get this fixed!

[mehdi]

@girish done, just sent it through the cloudron support ticket page. Let me know if there's anything else I can do !

[girish]

This is fixed in the next release, was a bug in the file manager when using filesystem or the mountpoint volume type.

[mehdi]

@girish Follow-up bug report : it seems i cannot disable the SSH support access

Why would I need to enable PermitRootLogin in order to disable SSHS support access ? It does not seem to make sense.

[nebulon]

@mehdi thanks for reporting, this is fixed now. Next time a separate thread might be better to track those things if possible.