Is this intented behaviour?
Yep. sftp bind mounts the path. Bind mounts don't care if the path is mounted or not.
Yep. sftp bind mounts the path. Bind mounts don't care if the path is mounted or not.
Thanks. Is there a way to restrict access to folders that are not meant to be seen by the sftp user?
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.
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.
Don’t have an account yet? Register yourself now and be a part of our community!
