Discovered critical bug involving shared folders and reset permissions that can wipe a shared folder

  • I really have no idea how this happened. I have no idea what could have possibly caused this to happen. But it did happen. I don't know what logs to look for to figure out what possibly could have caused this, but I lost probably a month's work of work because of this.


    Seriously, why is this even possible?

  • but I lost probably a month's work of work because of this.

    No action on the GUI, deletes files/folders on the drives EXCEPT if you try to create a FS.


    So, explain better what's the issue.


    And start by searching the folders on the host, to see if the DATA is still there.

  • No action on the GUI, deletes files/folders on the drives EXCEPT if you try to create a FS.


    So, explain better what's the issue.


    And start by searching the folders on the host, to see if the DATA is still there.

    It's not in the individual mergerfs folders, I have no idea where else it could have gone. I ran snapraid undelete and got some of the files back, but nowhere near all of them.
    I'm currently running snapraid fix to see if that works any better, but I'm not hopeful.

  • There's too many variables on there (mergerfs, sftp) along the other (snapraid) that you said on the previous posts.

    Since I don't use neither, I can't be of much help.


    What it show has error is:


    What I can tell you is:

    Start by listing the individual drive's that compose the mergerfs/sftp point to see if the files are there (they should be):
    ls -al /srv/dev-disk-by-uuid-6c31ebf6-7d26-4071-8b32-3ccb3e778487/

    ls -al /srv/dev-disk-by-uuid-53d88707-dc91-4726-99e7-610f443f15be/


    And so on...

  • If someone want's to delve deeper, the STACK TRACE is:


  • I've basically confirmed that the files are gone, snapraid fix did not restore anything. Where do we go from here?

  • I have successfully recreated the issue that completely wipes folders, where do I submit a bug report?

    Version is 6.9.15-1 (Shaitan)

    1. Install Reset Permissions addon
    2. Make a shared folder
    3. (Set permissions to 774?)
    4. Give user Read/Write access in OMV permissions (this may not be necessary)
    5. As user, make dummy file.
    6. User Reset Permissions addon to reset the permissions and reset ACLs
    7. Change OMV permission for user from Read/Write to No Access (it might not actually matter what permissions are changed)
    8. Get a massive error, and see that the entire folder is wiped.
  • weanoob

    Hat den Titel des Themas von „Somehow, resetting permissions and setting chmod 774 COMPLETELY WIPED ONE OF MY SHARED FOLDERS“ zu „Discovered critical bug involving shared folders and reset permissions that can wipe a shared folder“ geändert.
    • Offizieller Beitrag

    If you can explain to me how chown and chmod delete files, I would be very impressed. Here are the commands resetperms runs:

    openmediavault-resetperms/usr/sbin/omv-resetperms at master · OpenMediaVault-Plugin-Developers/openmediavault-resetperms
    OpenMediaVault plugin for resetting shared folder permissions - OpenMediaVault-Plugin-Developers/openmediavault-resetperms
    github.com


    Get a massive error, and see that the entire folder is wiped.

    How and where are you looking to see these folders are wiped? Sounds like you are looking with a user that doesn't have permissions to see the files after you reset them.

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • If you can explain to me how chown and chmod delete files, I would be very impressed. Here are the commands resetperms runs:

    https://github.com/OpenMediaVa…r/sbin/omv-resetperms#L74


    How and where are you looking to see these folders are wiped? Sounds like you are looking with a user that doesn't have permissions to see the files after you reset them.

    I have looked using ls -la as a regular user, sudo ls -la as a regular user, and sudo -s followed by ls -la.

    I have managed to reproduce the error and can confirm that the files are, in fact, deleted, based on the drive usage shown in the OMV dashboard.
    I'm not completely sure what you mean by "where" but I've tried looking in both the mergerfs folder and the individual drives as well.

    • Offizieller Beitrag

    I went through your steps to reproduce multiple times on two systems and I didn't lose any files or get the error. Have you changed anything python on your system?

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • I went through your steps to reproduce multiple times on two systems and I didn't lose any files or get the error. Have you changed anything python on your system?

    I don't think so, it's using version 3.9.2.
    I too can't reproduce this on a brand new VM.
    I did change the user/group owning those folders, but I fail to see how that could cause files to be deleted.

    • Offizieller Beitrag

    Looking at the error again, it is the sftp plugin failing to remove a bind mount because the bind mount is in use. It is an error but it isn't a code issue. I still can't replicate your issue on omv 6 or 7.

    did change the user/group owning those folders, but I fail to see how that could cause files to be deleted

    None of the steps you listed have delete commands. So, I really don't know what is deleting files.

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Looking at the error again, it is the sftp plugin failing to remove a bind mount because the bind mount is in use. It is an error but it isn't a code issue. I still can't replicate your issue on omv 6 or 7.

    None of the steps you listed have delete commands. So, I really don't know what is deleting files.

    Okay, I managed to recreate the error in a VM. It seems like you have to have the SFTP addon installed, an SFTP share setup for a user with access to the folder. Then you have to change access to No Access, this causes the folder's contents to be deleted; it seems like Reset Permissions actually has nothing to do with it.
    I will note that this was also done while replicating my mergerfs/snapraid setup, I'll try it on a bare drive just in case.
    Edit: works the same on a bare drive.

    • Offizieller Beitrag

    It seems like you have to have the SFTP addon installed, an SFTP share setup for a user with access to the folder. Then you have to change access to No Access, this causes the folder's contents to be deleted

    Can replicate this. When removing permissions of the user on a share that is used in SFTP data are removed.

    This is the message I get


    • Offizieller Beitrag

    I didn't realize the file.absent saltstack function would do a recursive delete on a directory - https://github.com/OpenMediaVa…ploy/fstab/91sftp.sls#L42


    But this wouldn't be a problem if the unmount didn't fail right before the code that is deleting the mount directory. I will have to look into why saltstack if still running the delete when the unmount fails.


    This whole scenario is something I wouldn't have thought of because you are removing permissions for a shared folder that you are explicitly giving access to in the sftp plugin. This code has been the same for 5+ years (since initial port to OMV 5.x).

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    I changed the code to use commands that can't delete files. 7.0.2 is in the repo.

    use safer bind mount cleanup · OpenMediaVault-Plugin-Developers/openmediavault-sftp@03179f9
    Signed-off-by: Aaron Murray <plugins@omv-extras.org>
    github.com


    I still recommend deleting sftp shares first if you are going to remove privileges for those shares.

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Einmal editiert, zuletzt von ryecoaaron ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!