mmm77

HI @kaedinger , one version before I did not see a change last version from yesterday? did it. I am just on dry run, so did not see a real reaction. Debug Log

Hi @kaedinger Thank you for the detailed and insightful explanation! It perfectly makes sense now, and AI believes we have solved both mysteries regarding the logs. First, to answer your question about the .tmp files directly at the disk roots: We strongly suspect that the widely used Unraid plugin "Fix Common Problems" (FCP) is the culprit. FCP runs scheduled background checks and likely writes these temporary atomic files directly to /mnt/diskX/ to test the physical read/write capability of the drives. Since it purposely bypasses the user shares, Unspin correctly detects them at the root and tags them with [skip share]. Second, AI did some deeper digging into the architecture to figure out why Unspin doesn't see any actual read/write activity inside my shares on ZFS (like when I play a movie), even though it sees the .tmp files at the root perfectly. The explanation seems to be a structural clash between ZFS and fanotify. As you stated, Unspin uses fanotify to mark a mount (e.g., /mnt/disk1). On XFS or Btrfs, a user share is just a standard directory on that mount, so fanotify sees everything inside it. However, on Unraid, every top-level share folder on a ZFS disk is created as a separate ZFS dataset. In Linux, every ZFS dataset acts as an independent mount point. Because a fanotify mount-watch (FAN_MARK_MOUNT) strictly does not cross mount boundaries, it completely ignores everything inside /mnt/disk1/Filme because "Filme" is technically a separate child-mount. The daemon sits at the /mnt/disk1 door, sees the .tmp files dropped there by FCP, but remains completely blind to the separate ZFS dataset mounts underneath. To fully support ZFS arrays on Unraid, Unspin's daemon would likely need to iterate through the active mounts (e.g., via /proc/mounts) and place a fanotify watch not just on /mnt/diskX, but recursively on all dataset mounts present directly under those disks. I hope these technical details help put the pieces together! Thanks again for your time and for maintaining this tool. Best regards, Gemini + Mike 😁

So now I can tell you some more: But I changed something... AI gave me a code to have a look at the harddrives... (File Activity v2 did not work any more for me....) while true; do for pid in /proc/[0-9]*; do if ls -l "$pid/fd" 2>/dev/null | grep -q "/mnt/disk[1-9]"; then echo "$(date '+%H:%M:%S') | PID: ${pid##*/} | Befehl: $(tr '\0' ' ' < "$pid/cmdline")"; fi; done; sleep 0.5; done So it identified for me the whole night: 05:29:39 | PID: 377791 | Befehl: find /mnt/disk3/medien -noleaf -maxdepth 7 05:29:45 | PID: 377749 | Befehl: find /mnt/disk5/medien -noleaf -maxdepth 7 05:36:09 | PID: 816017 | Befehl: find /mnt/disk5/medien -noleaf -maxdepth 7 05:36:09 | PID: 816057 | Befehl: find /mnt/disk3/medien -noleaf -maxdepth 7 05:36:16 | PID: 816017 | Befehl: find /mnt/disk5/medien -noleaf -maxdepth 7 05:36:22 | PID: 816017 | Befehl: find /mnt/disk5/medien -noleaf -maxdepth 7 05:36:28 | PID: 816017 | Befehl: find /mnt/disk5/medien -noleaf -maxdepth 7 05:36:40 | PID: 849517 | Befehl: find /mnt/disk5/medien -noleaf -maxdepth 7 05:36:47 | PID: 849517 | Befehl: find /mnt/disk5/medien -noleaf -maxdepth 7 05:36:53 | PID: 849517 | Befehl: find /mnt/disk5/medien -noleaf -maxdepth 7 05:36:59 | PID: 849517 | Befehl: find /mnt/disk5/medien -noleaf -maxdepth 7 05:52:30 | PID: 1896131 | Befehl: find /mnt/disk5/medien -noleaf -maxdepth 7 05:52:30 | PID: 1896151 | Befehl: find /mnt/disk4/medien -noleaf -maxdepth 7 I found out that I still had installed Dynamix Cache Directories So now I disabled this and it seems to be solved...... Don't know why the plugin started to do this... 13:00 was daily mover from 19:00 it was daily plex and emby automatically maintenance and so on... But how can I help you to identify such things... Mike

One first result after 2 hours: There is no disk 2. Maybe it is ZFS ? But I thought that I optimized all settings... Will give you new information in 24h Mike

Hi, waited a few updates, but still have so much "other acticity". Any chance to identify ? Cannot imagine what was working on HDD today between 6 an now.. Mike

Hi kaedinger, first of all, thank you for maintaining the Unspin plugin. It is a great utility, but I've run into a compatibility wall with modern Unraid setups utilizing ZFS on the array. This is what AI says, because I have no big technical background... Current Setup & Symptoms: My Unraid array consists of multiple disks (disk1 through disk5) formatted with LUKS-encrypted ZFS (luks:zfs). The Unspin plugin currently only allows selecting traditional array disks (disk1 - disk5), but it fails to detect disk activity or spin states correctly on ZFS-formatted array drives. Additionally, there is no option to monitor via user shares or adapt to the underlying block/file system handling of ZFS. Technical Background: Unlike traditional XFS/Btrfs file systems where standard disk activity hooks and disk status calls are straightforward, ZFS abstracts block-level operations and caching differently. Because the plugin relies on legacy detection mechanisms tied to traditional array structures, it remains completely blind to activity on ZFS array disks. Feature Request: Could you look into updating the plugin to support ZFS-formatted array disks (and potentially add flexibility regarding monitoring paths or modern filesystem states)? Thank you for your time, support, and ongoing work on this plugin! Maybe this is wrong, but I see really no acticity in the logs and I activated debug and include excludes shares in log... Best regards, Mike added additional information: Thats the only in log: 2026-08-02 17:32:58 [INFO ] Watching mount at: /mnt/disk1 (after wait) 2026-08-02 17:32:58 [INFO ] Watching mount at: /mnt/disk3 (after wait) 2026-08-02 17:32:58 [INFO ] Watching mount at: /mnt/disk4 (after wait) 2026-08-02 17:33:28 [INFO ] Watching mount at: /mnt/disk5 (after wait) 2026-08-02 17:33:28 [INFO ] Monitoring for file accesses... 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk1/757176000.tmp1555546784" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk1/757176000.tmp" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk1/757176000.tmp" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk1/757176000.tmp (deleted)" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk3/1262493396.tmp1132662238" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk3/1262493396.tmp1132662238" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk3/1262493396.tmp" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk3/1262493396.tmp" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk3/1262493396.tmp" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk4/1216640274.tmp678105057" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk4/1216640274.tmp678105057" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk4/1216640274.tmp" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk4/1216640274.tmp" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk4/1216640274.tmp (deleted)" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk5/1372285393.tmp164633068" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk5/1372285393.tmp164633068" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk5/1372285393.tmp" 2026-08-02 17:43:18 [DEBUG] [skip share] "/mnt/disk5/1372285393.tmp"

Hi, Bombvault sounds great, so I gave it a try and tested the manual backup by selecting all containers. Here are a few things I noticed: "Select All" behavior: "Select All" probably shouldn't include Bombvault itself. When the backup process reached Bombvault alphabetically, it crashed the backup for me. :-) Browser/Session dependency: On my second try, I unselected Bombvault. However, the backup failed again when it reached Chromium. I was running the Bombvault UI inside that specific Chromium docker container. Does closing or losing the browser connection kill the manual backup process? Random interruptions: For my next attempts, I deselected both Bombvault and Chromium. It failed once during the Emby backup (though that works now, maybe it is still stopped since this try), but the last three times it stopped right after Fenrus (meaning Fileflows would have been next, judging by the timestamps). EDIT: It seems it is still running, only the progress bar was missing from time to time. This time it stopped at iobroker (restic backup failed), but usually I would not backup iobroker this way. Suggestion: When backup failed, please restore the running condition of the container afterwards.... emby and iobroker both stayed stopped after backup failure and were running before. Any ideas on what might be causing these stops? Mike

Hi, yes now it seems to work, still some unattributed activity. So I now tryed to move all .plexignore to cache...... that´s why (deleted) ...screenshot was afterwards Mike

Hi, took a while unraid: 7.3.1 all apps use /mnt/user/... also some screenshots what I can see.. Mike state.json syslog.txt

HI and thanks, error has gone, but does not help to identify my apps. Mike

Hello, after a few minutes I get the error: fanotify unavailable: [Errno 2] No such file or directory so I often have only "other activity" in the statistic and cannot identify my problem. Mike

@d3m3zs yes please help us... I just recognized that some settings were not changed on the datasets, when doing it in ZFS Master... So for now I used the Terminal.... Mike

restart of unraid server did help. PS: maybe it is better to tell command: wget https://github.com/masterwishx/unraid-templates/raw/refs/heads/main/configs/filebrowserQuantum/config.yaml (also changed link to raw file)

Hi, any Idea why my unraid GUI crashes when I try to install ? I click on install, and then it hangs adding the container ( opening the template) Tried on 2 browser and on Smartphone... I also cannot open unraid web GUI again without closing the browser first. Mike PS: I could not create a share with a space in the name, so I created share "FileBrowser" but this should be no problem where my installation hangs

Hallo @alturismo , bitte nicht böse sein, oder lachen... Ich kenne mich mit programmieren gar nicht aus, hatte aber ein Problem, was dann eine KI für mich gelöst hat. Erst das einfachere: Dieser Fehler: cache-mover: msm: /usr/local/emhttp/plugins/cache-mover/scripts/cache_mover1: line 141: [: ==: unary operator expected Dieser Fehler kommt auch bei cache_mover2 in einer anderen Zeile vor.... Hier sollte ich if [ $rsync_mode == "file" ]; then abändern in if [ "$rsync_mode" == "file" ]; then Dann hatte ich noch ein Problem, daß ich bei einer Serie 2 fast gleichlautende Verzeichnisse habe. The Expanse (2015) und dann noch aus einer Konvertierung zum Test: The Expanse (2015) AV1 Hier hat deine Suchlogik die Verzeichnisse zusammengeschoben. rsync: [sender] change_dir "/mnt/disk2/medien/Serien/The Expanse (2015)/Season 3/The Expanse - S03E06 - Aufopferung.mkv\#012/mnt/disk2/medien/Serien/The Expanse (2015) AV1/Season 3" failed: No such file or directory (2) (Hier hatte ich noch nicht eingestellt, daß der ganze Ordner verschoben werden soll) So ein verwursteltes Verzeichnis habe ich auch anderswo schon gesehen im Forum. Hauptproblem sei Zeile 96-100 filename=$(basename "$openfile") filename_search=$(echo $filename | sed 's/[^a-zA-Z0-9]/*/g') diskpath=$(find /mnt/disk* -type f -name "$filename_search") diskname=$(echo $diskpath | awk '{ print $1; }' | cut -f 3 -d "/") if [ "$diskname" == "disks" ]; then subdisk=$(echo $diskpath | awk '{ print $1; }' | cut -f 4 -d "/") diskname="$diskname/$subdisk" fi Das Problem: Wenn find mehrere Dateien findet (weil du zwei ähnliche Verzeichnisse hast: "The Expanse (2015)" und "The Expanse (2015) AV1"), werden alle gefundenen Pfade in die Variable $diskpath geschrieben - mit Zeilenumbrüchen dazwischen. Das führt dann dazu, dass später bei rsync_source=$(dirname "$diskpath") ein Pfad mit eingebautem Zeilenumbruch (\#012) entsteht, genau wie in deinem Log zu sehen. Diese habe ich ersetzt durch: filename=$(basename "$openfile") filename_search=$(echo $filename | sed 's/[^a-zA-Z0-9]/*/g') # Find all matches and filter to get only the exact directory match diskpath=$(find /mnt/disk* -type f -name "$filename_search" | grep -F "$directory" | head -n 1) # Fallback if exact directory match fails if [ -z "$diskpath" ]; then diskpath=$(find /mnt/disk* -type f -name "$filename_search" | head -n 1) fi diskname=$(echo "$diskpath" | cut -f 3 -d "/") if [ "$diskname" == "disks" ]; then subdisk=$(echo "$diskpath" | cut -f 4 -d "/") diskname="$diskname/$subdisk" fi Die wichtigsten Änderungen: grep -F "$directory" filtert die find-Ergebnisse, um nur den Pfad zu nehmen, der zum korrekten Verzeichnis (mit oder ohne "AV1") passt head -n 1 stellt sicher, dass nur ein Ergebnis genommen wird (keine Zeilenumbrüche mehr in der Variable) Fallback falls die exakte Directory-Suche fehlschlägt Anführungszeichen um $diskpath bei der Zuweisung von diskname, um Fehler zu vermeiden Das sollte das Problem mit den zwei ähnlichen Verzeichnisnamen lösen. Zumindest hat es danach funktioniert... Ich habe nun von jedem Verzeichnis etwas abgespielt und habe nun auch beide Verzeichnisse in der Tabelle "cached" aufgeführt so wie auch auf dem Cache wirklich liegen. EDIT: Habe es gefunden. Hier sind die Verzeichnisnamen wahrscheinlich auch zu ähnlich: https://forums.unraid.net/topic/181843-support-alturismo-repos/?&do=findComment&comment=1584779 Oct 18 10:10:04 Exa root: cache-mover: msm: rsync: [sender] change_dir "/mnt/disk1/data/movies/How to Train Your Dragon (2010)/How to Train Your Dragon.mp4\#012/mnt/disk1/data/movies/How to Train Your Dragon 2 (2014)/How to Train Your Dragon 2.mp4\#012/mnt/disk1/data/movies/How to Train Your Dragon Homecoming (2019)/How to Train Your Dragon Homecoming.mp4\#012/mnt/disk1/data/movies/How to Train Your Dragon The Hidden World (2019)/How to Train Your Dragon The Hidden World.mp4\#012/mnt/disk1/data/movies/How to Train Your Dragon (2025)" failed: No such file or directory (2)