SFTP Plugin Problem

  • Same problem here, and your insight and help was really really appreciated.


    I installed OMV in a OrangePi Plus 2e, attached a couple of drives and could not make SFTP with chroot to work.


    After chmod 755-ing / everything looks to be working normally.


    Thanks again.

  • and therefore I checked the permissions. I found that my / was set as root:root 775 and not root:root 755.


    I backed up my system and changed the permissions with "chmod 755 /".

    chmod 755 / fixed it for me! Thanks!


    Do you by any chance know why I'm seeing a dev folder when I log in? I see the other folders that I enabled and wanted to see, but I also see dev. How do I remove it from the folder that is being seen when logged in sftp?

  • I don't use the sftp plugin, I set up sftp by hand ages ago long before I started to use OMV so this practice was carried over.


    In my setups, the /dev folder contains a log socket. It is required to be within the chroot environment or it will not work.


    I suppose that if you want to run sftp without any logging enabled (not a good idea) then you could disable logging for the service in /etc/rsyslog.d by determining which is the appropriate file there and renaming it so it does not have conf as the final extension name. Then either restart the logging service or reboot the machine. As root should then be able to delete the /dev folder in the chroot.

    --
    Google is your friend and Bob's your uncle!


    RAID - Its ability to disappoint is inversely proportional to the user's understanding of it.


    OMV 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • Do you by any chance know why I'm seeing a dev folder when I log in? I see the other folders that I enabled and wanted to see, but I also see dev. How do I remove it from the folder that is being seen when logged in sftp?

    The dev folder is there on purpose. That is a link to the rsyslog log socket. Why do you want to remove it?

    omv 5.3.9 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.2.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 installscript will fix this now. https://github.com/OpenMediaVa…ba1199b79c0b1c416200fa7a1


    I did have a very close problem even if I installed OMV 5 with SFTP plugin v.5.0.4.: incorrect permissions on /sftp folder.


    Only thing gone better: /sftp folder was created.

    BUT: no access for sftp-group users, access to / for other users.


    I did chmod 755 /sftp and then the same on the user folder, so chmod 755 /sftp/<sftp_specific_user> in my case

    This fixed almost everything: sftp-group users now can access the right folder, while non sftp-group user have no access at all (in my case the "group" is composed only by <sftp_specific_user>).


    Only problem left: now <sftp_specific_user> and the sftp-group users can access the folder assigned, but all the files and folders that were ALREADY INSIDE that folder can't be accessed.


    Should I do chmod 755 -R /sftp OR chmod 755 -R /sftp/<sftp_specific_user> to change the permissions to avery file/folder ?

    (By the way it's a quite big folder with a lot of subfolders)


    PS: This time I ask BEFORE doing "kamikaze coding" :)

  • Should I do chmod 755 -R /sftp OR chmod 755 -R /sftp/<sftp_specific_user> to change the permissions to avery file/folder ?

    I'm not sure why you need to do that. The saltstack code is supposed to be doing that - https://github.com/OpenMediaVa…10_sftp_user_dirs.sls#L27

    omv 5.3.9 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.2.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!

  • I'm not sure why you need to do that. The saltstack code is supposed to be doing that - https://github.com/OpenMediaVa…10_sftp_user_dirs.sls#L27

    I don't know either, Rye.


    I've read what you say before doing that: but in my case, appearently, something has gone wrong.


    And I tell you: I struggled for more than one day in my attempts to make changes to users, etc to make it work, without any result.

    Then I found an old post where you suggested to a user change permissions that way (for an older version of the plugin) and tried out that way.

    And it was successful!


    Without that changes there has been no way to make sfpt to work , and to make it work on the folder I assigned to the group.

    After that change everything work like a charm!


    That's alla what I can say.


    Only drawback, and important question: the files that were ALREADY present in the folder before changing permissions to the main folder are still not accessible, so I wanted to understand if I should apply the command again, recursively with the "-r" option.


    Is it safe?

  • Is it safe?

    Hard to say. A recursive change will change all files and folders. Other than the folders that the plugin creates, you do NOT want to change anything else because those permissions are set when the files are created. If you can't access them, then they have the wrong permissions for the user that you are trying access them with. I will see if anything is wrong with the plugin for the folders it creates.

    omv 5.3.9 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.2.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!