SFTP Server serving root directory if specified dir not accessable

  • Is this intented behaviour?

    Yep. sftp bind mounts the path. Bind mounts don't care if the path is mounted or not.

    omv 5.6.4 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • So I have figured out that allowing access only to members of the sftp group should jail them inside their directory. Now I have got the problem that even though the luks device is decryptet sftp still serves the root directory, just without access to the folders inside it. I have no way to access the desired folder.

  • Now I have got the problem that even though the luks device is decryptet sftp still serves the root directory, just without access to the folders inside it. I have no way to access the desired folder.

    The bind mounts will need to be remounted after the LUKS device is decrypted. Using LUKS has many issue with OMV because OMV expects drives to be accessible always. Unlocking on boot is my only suggestion.

    omv 5.6.4 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • The bind mounts will need to be remounted after the LUKS device is decrypted. Using LUKS has many issue with OMV because OMV expects drives to be accessible always. Unlocking on boot is my only suggestion.

    Thanks for the info but I figured out what my problem was. The reason was the "share root filesystem" plugin by omv-extras. Since I removed this one the sftp server refuses connections when the encrypted device is not mounted and only accepts requests once its unlocked. Since I don't use "share root fs" atm it is not relevant to me, but is there a possibility for a fix in the future?

  • The reason was the "share root filesystem" plugin by omv-extras.

    That isn't an omv-extras plugin. It is a core plugin.


    is there a possibility for a fix in the future?

    I gave you the only possible fix I know of (auto unlock). OMV (not the plugin) would need a major redesign to handle these filesystems that aren't mounted or even exposed until the device is decrypted. If you want something that works well, I wouldn't use LUKS.

    omv 5.6.4 usul | 64 bit | 5.11 proxmox kernel | omvextrasorg 5.6
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!