qBit does delete the file from my physical drive (direct attached storage, raid5). But won’t update the free space in the WebUI. The discrepency is over 1TB, so I’d like to address this if someone can help me.

Some info:

  • qBit v.5.0.1, docker, from linuxserver.io
  • Ubuntu 24.04
  • Automatic Management Mode is checked
  • Torrent content removing mode: Delete files permanently
  • Brickfrog@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    23
    ·
    edit-2
    14 days ago

    Has it been happening since qBittorrent 5.x ? Only reason I ask is that 5.0 did introduce a new feature per https://www.qbittorrent.org/news

    FEATURE: Allow to move content files to Trash instead of deleting them (glassez)

    Maybe double-check the qBittorrent settings and verify that isn’t somehow enabled? I’m not on on that version yet so can’t be sure how that new feature works or is configured.

    If it’s not that then I suspect the other comments are right e.g. a hardlinked file elsewhere would defintiely mean you need to delete all the hardlinks to actually free up space.

    • ReedReadsOP
      link
      fedilink
      English
      arrow-up
      10
      ·
      14 days ago

      Yeah, I thought about that too. It’s why I noted in the post that my files are set to delete and not be moved to the trash first. Those settings are in options/advanced.

      • Brickfrog@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        3
        ·
        14 days ago

        Yup going to do that soon :)

        Still on 4.x, bummer as I normally wait a while before doing major version software updates but it is what it is.

        • kitnaht@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          14 days ago

          So, I migrated to 5.x and I don’t know if it was just me, or a change in the WebUI or something, but Sonarr stopped wanting to pull files in. I’ve been holding out on the Sonarr upgrade because last I looked at it, it wouldn’t auto-migrate you over, etc.

          But when I went to upgrade it - it said that now auto-migrates, and it does. However, the old migrated rules looked kinda dirty, so I was panicking a little. The imported/converted stuff all worked, mind you, I just didn’t like how they looked. In the end, I ended up really really liking the new Sonarr system, though I did have to ask an LLM how to format some new regex.

    • ReedReadsOP
      link
      fedilink
      English
      arrow-up
      6
      ·
      14 days ago

      I deleted .25 terabytes and it hasn’t changed at all. It used to increment up after every deletion, so this is new.

  • kitnaht@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    ·
    14 days ago

    Are you hard-linking it to somewhere else on the drive via any kind of automation?

    For example, Sonarr can hard-link files to the directories they belong in, so that Qbit can continue seeding. If you then delete/remove the torrent/files – then the hard link would still be there.

    • ReedReadsOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      14 days ago

      It is a really good thought. Your comment prompted me to check the whole machine (SSD + raid array) and I don’t have any hard-linking of media files, torrent files or anything like that. So that isn’t it.

      I think it’s just a bug in the system.

    • adhocfungus@midwest.social
      link
      fedilink
      English
      arrow-up
      1
      ·
      14 days ago

      Exactly what I was going to say because this hit me a while back. I still have no good solution; I have to delete shows/movies from the *arr then manually delete them from qbitorrent too.

  • renegadespork@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    4
    ·
    13 days ago

    I have this issue too, and I figured out a workaround. Deleting the files manually via rm frees up space. Deleting files via qBittorrent via UI or automatically does not.

    Turns out the files were just being moved to a “.Trash-UID” (where UID is the UID of the container) folder in the /downloads directory (or wherever that folder is mapped to on your host). Clearing that out freed up the space.

    I suspect this is a bug where the “Delete files permanently” setting is not being respected. You might want to set up a cron job to delete that folder periodically in the meantime.

  • catloaf@lemm.ee
    link
    fedilink
    English
    arrow-up
    2
    ·
    14 days ago

    Does it update if you refresh the page? You may just want to file a bug report.

    • ReedReadsOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      14 days ago

      It doesn’t. I rolled the version back to 4.6.7 and it didn’t help, so I moved it forward again. Restarted the container, then the stack, then the whole physical machine. Nothing so far. Yeah, maybe I’ll file a report on their page.

  • lime!@feddit.nu
    link
    fedilink
    English
    arrow-up
    1
    ·
    13 days ago

    i’ve seen something like this before, where the kernel holds the file handle open for the process so that it thinks the file is still there. i think it’s related to how the program closes the file but i don’t remember the details. restarting qbittorent will most likely fix it.

  • tkw8@lemm.ee
    link
    fedilink
    English
    arrow-up
    1
    ·
    14 days ago

    Have you tried deleting the docker config and starting with a fresh install?

    • While this would almost certainly work, it would be nice if the root cause can be discovered and either fixed or worked around. Having to reinstall everytime one needs to free up disk space is … less than ideal.

    • ReedReadsOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      14 days ago

      Not yet and hopefully I won’t have to do that.