Helediron

Still an issue in 7.1.4. The bug is that adding a share robs the pci address of the network card in the vm definition. The interface does get a new pci address, but that changes the network interface names inside the vm. So, you either have to restore the pci address in the vm definition, or adjust network settings inside the vm. I myself used the fix in this comment . In a nutshell, restore back the old pci address of the network interface. The bus attribute in "<address ... >" got changed. When restoring, move the new bus value from the interface into the new share's bus value. Otherwise there are two devices with same pci address.

Pardon necro, but i just got same error. Don't know if this is exactly same but i got mine fixed. I had array, zfspool and tinypool. Few months ago I removed the tinypool. I thought that the tinypool was unused (it WAS tiny :) ), and shares were (or should have been) configured using zfspool and array and mover zfspool -> array. Anyway, i just tried to add stuff to the share and i got that "No medium found". While troubleshooting i noticed that the GUI showed tinypool was in use for the share as primary, and it showed error that tinypool was missing. Syslog had lines "... shfs: assign_disk: /shared/Setups/MSUserMigration (123) No medium found" I changed the missing tinypool to zfspool and got rid of the error, and was able to add files/directories to the share. Now, i didn't really pay attention to details until i saw actual errors, but it might be worth testing what really happens in Unraid when a pool is deleted.

My daily scan time has crept to 16 hours and i thought to do something to that. I made a modification to my script. The old script keeps scanning old files day after day. The modification makes it to concentrate to only new or modified files. The change selects folders which have modified files within a month, or directories modified within a month. A test run reduced scan time from 16 hours to one. Please note that this change is to my original script and @Masterwishx has a newer version. I have not compared the scripts and don't know if it fits directly into it. The snippet still creates same clamavtargets.txt file as before. But instead of listing the top-level folder it generates a list of subfolders under the top folder - modified within last month. When old script sent e.g. whole "/mnt/user/media" folder for scanning, now it may send e.g. "/mnt/user/media/movies2020s", "/mnt/user/media/SomeNewMusic" folders. Assuming there were folders like movies2010s, movies2000s and so on, the scan will skip a large part of (old) files. This modification is inefficient if you have all files in one huge directory. The snippet (not the whole script) ... echo Creating scan list: $FOLDERS rm $HOSTAPPDATA/clamavtargets.txt 2> /dev/null rm $HOSTAPPDATA/clamavmaplog.txt 2> /dev/null maperrors=0 for f in $FOLDERS do if [ -d "$HOSTSCANDIR/$f" ]; then # Find directories containing modified files. find "$HOSTSCANDIR/$f" -type f ! -name '*.log' -mtime -30 -exec dirname {} \; > $HOSTAPPDATA/clamavtargets_temp.txt # Find modified directories biut skip x top levels (mindepth). find "$HOSTSCANDIR/$f" -mindepth 2 -type d -mtime -30 -print >> $HOSTAPPDATA/clamavtargets_temp.txt # Relocate folder list into container cat $HOSTAPPDATA/clamavtargets_temp.txt | sort --unique | sed -e "s,$HOSTSCANDIR,/scan," >> $HOSTAPPDATA/clamavtargets.txt #echo "/scan/$f" >> $HOSTAPPDATA/clamavtargets.txt echo "Scanning container /scan/$f -> host $HOSTSCANDIR/$f" echo "Scanning container /scan/$f -> host $HOSTSCANDIR/$f" >> $HOSTAPPDATA/clamavmaplog.txt else echo "Warning: can't find share: $HOSTSCANDIR/$f" echo "Warning: can't find share: $HOSTSCANDIR/$f" >> $HOSTAPPDATA/clamavmaplog.txt maperrors=1 fi done # Remove children if higher level folder is on the list. cat $HOSTAPPDATA/clamavtargets.txt > $HOSTAPPDATA/clamavtargets_temp.txt while read f; do grep -v "$f/" $HOSTAPPDATA/clamavtargets_temp.txt > $HOSTAPPDATA/clamavtargets_temp2.txt; cat $HOSTAPPDATA/clamavtargets_temp2.txt > $HOSTAPPDATA/clamavtargets_temp.txt ; done < $HOSTAPPDATA/clamavtargets.txt cat $HOSTAPPDATA/clamavtargets_temp.txt > $HOSTAPPDATA/clamavtargets.txt echo "Scan list:" cat $HOSTAPPDATA/clamavtargets.txt echo "" ... Changing e.g. "-mtime -30" to "-mtime -7" reduces the time window from one month to a week. The "-mindepth 2" prevents top level folder and immediate children being added to the list if the directory is modified. Changing it to "-mindepth 1" allows including folders immediately below top folder to list. Note that even top level folder may be added if there are modified FILES right under it. The snippet ignores all *.log files. Remove "! -name '*.log' " if you want to include them. The snippet is released to public domain.

Reverse proxy to containers so that i don't need to expose their WebUI to network and keep them behind Unraid login.

I noticed a small issue with the Clamav container parameters. It uses path "/mnt/cache/appdata/clamav". I recently converted my cache to ZFS pool and named it "zfspool". So, i no longer have "cache" pool. A better value for the signatures folder would be "/mnt/user/appdata/clamav". The "Fix Common Problems" plugin starts to yell about spurious "cache" folder under /mnt because of the parameter.

Thank you @Masterwishx. I edited my original script post to point here.

This fixed 6.12.4 docker containers with static ip4/6 addresses not starting. Otherwise works fine.

Hi, script parameter and container parameter customisation sshould be enough. ClamAV scans whatever it finds in the Docker container's internal /scan folder, which usually is mapped to external folder /mnt/user. If you change that container parameter to e.g. /mnt/cache (assuming "standard" naming), then you can direct the container to scan the cache. Now, if you want to scan the cache completely, you don't need my script. Just point the container to the cache as above and run the container. This one-liner starts the scan: docker start ClamAV Put that into a user script, schedule it daily and you're done. If you want the folder selection or those fancy notifications, then continue. -> To modify the script, there are more parameters in the script to customise. Find this block: #Technical parameters # name of the container. CONTAINER=ClamAV # Location of ClamAV application data folder in Unraid host. # Must match with container parameter "ClamAV Signatures:" HOSTAPPDATA=/mnt/user/appdata/clamav # Location of scanned directory. # Must match with container parameter "Folder to Scan:" HOSTSCANDIR=/mnt/user ... and customize the script too. The script parameter HOSTSCANDIR must match with the container parameter. Change "HOSTSCANDIR=/mnt/user" to "HOSTSCANDIR=/mnt/cache". Put into FOLDERSDAILY and FOLDERSWEEKLY directories right under /mnt/cache, e.g. FOLDERSDAILY="domains isos" . If you want to run both user shares and directories under cache, it's getting more complex. There are two options: If you want to scan both /mnt/cache and /mnt/user completely, then set the scan point to /mnt and set FOLDERSDAILY and FOLDERSWEEKLY to "cache user" . We just moved here one step higher in folder hierarchy. If you want to scan subsets in both, then you have to duplicate the ClamAV container and script and customise them independently. In the second script you have to change CONTAINER and HOSTAPPDATA to match the second container. (Actually i don't yet know how that's done in Unraid, i'm Unraid noob). The script prints some debugging info. You'll see that if you run the script interactively with User Script plugin. It verifies that the folders actually exist and prints what it finds and finds not. If the scan takes long time, you can safely stop the script, but remember to stop the ClamAV container too.

Thank you @TQ for this. EDIT 2024-01-14: please see updated version here: I wrote another user script to start and control the scanning. With it you can select which shares to scan. The script can be scheduled. You can select one day in a week when the script runs another set of shares. The intention is to scan a small set daily and then a full scan once per week, and and completely avoid scanning some shares. Some snippets as a sample: # Edit these parameters: # List of Unraid shares to scan under /mnt/user. Check YOUR Unraid "Shares" tab. # Put a space between each share name. FOLDERSDAILY="incoming shared" FOLDERSWEEKLY="isos incoming shared backups myverybigshare" # Select which day is weekly scan day (1=mon, 7=sun). WEEKLYDAY=2 The script writes the target directories into a parameter file. # Switch to advanced mode (click basic mode at top right) and change # "Post parameters" to "-i -f /var/lib/clamav/clamavtargets.txt". # This tells the scanner to use a target list in a file instead of # scanning every Unraid share. This is the only required change to the container definition. The user script writes the parameter file and runs the container. Full script is here: https://github.com/Helediron/unraid-dailyclamavscan Credits to @Squid for the original script, on which this is based.

Some motherboards use same pci lanes in two places. I suggest to read the mb manual and check if e.g. using last m.2 slot or card slot excludes some sata ports.

I just had troubles with three NICs bonded, two on motherboard: 1G is eth0, 2.5G is eth1 and 10G card eth2. The default configuration seems to want to use eth0 as primary and others as backup. I'm not sure if i saw just UI issue or real, but after trying to swap eth0 <-> eth2 in interface rules all cards showed same MAC. The 10G card (which was now eth0) didn't work after the swap. I ended up disabling in BIOS the motherboard NICs, and using just the 10G card. Now it works.