OK, that makes sense then. I just couldn’t wrap my head around how the files had gone missing.
I’ve pointed SABnzbd to the /repo-cache folder, and in the categories tab, everything is now back to normal. I’ll make a backup of autoProcessMedia.cfg just in case everything is reset again later.
Thanks for the quick help 
More bad news (it never ends): the developers for Lidarr are now compiling their binaries to require libc 2.29 or later, which isn’t available in QTS. 
So, as of right now, the Lidarr package can’t be run. Existing Lidarr users will find their installation broken when Lidarr next updates, and Lidarr will be removed from sherpa support on the next stable QPKG release.
There are various versions available in the myQNAP repository if you’d like to continue using this application, but these require the purchase of a core QPKG from Stéphane.
You may be able to transfer your existing configs across to it. Don’t install the myQNAP version until you’ve manually backed up your configs though.
Your sherpa Lidarr should be manually uninstalled via your QTS App Center.
p.s. Does anyone know how to compile a later glibc and make it available to a specific application? If so, I could use your help. Please contact me. 
Hi,
I noticed a little hiccup regarding the nzbMedia path.
Recently, the scripts in SabNZB stopped working for me, and I realized that the nzbMedia scripts were now linked under /share/Public/Downloads instead of /share/Download.
So I took a look at nzbmedia.sh:
default_download_share is determined from /etc/config/def_share.info. Mine looks like this:
[SHARE_DEF]
defPublic = Public
defDownload = Download
defMultimedia = Multimedia
defRecordings = none
defUsb = Usb
defWeb = Web
defVolMP = /share/CACHEDEV1_DATA
So for me, it results in /share/CACHEDEV1_DATA/Download.
But then in nzbmedia.sh, there’s this check:
if [[ -z $default_download_share ]]||[[ -n $default_download_share && ! -L $default_download_share ]];then
default_download_share=unspecified
fi
And exactly the ! -L $default_download_share is the problem.
-L is “True if file exists and is a symbolic Link.”
Now, /share/CACHEDEV1_DATA/Download is the actual storage location of the share, so it’s a folder and not a symlink.
/share/Download would be the appropriate symlink.
Thus, default_download_share=unspecified is set and ultimately the symlink for the scripts is created under /share/Public/Download.
For now, I helped myself by adding the following line to /etc/config/qpkg.conf: Scripts_Path = /share/Download. But I’m not sure if this will survive an update of the nzbMedia QPKG.
So if @OneCD is working on a new QPKG, maybe a small fix is needed there.
Hi mate, and thanks for posting your findings. 
The new nzbToMedia QPKG is complete, but is awaiting the next sherpa packages release (which I hope will be this weekend). I’ve altered the logic in the nzbToMedia QPKG so it’s now self-contained. It will no-longer attempt to link to a download location used by another application like SABnzbd or nzbget.
It will be up-to the user to create this link where-ever they like - a symlink isn’t even needed anymore. This means, post-processing scripts no-longer need to be in a “downloads” path.
For existing users, they already have a link. For new users (or existing users wanting to change the scripts location), set the ‘Scripts Folder’ location directly in SABnzbd (or nzbget).
All that remains is for me to create a new wiki page explaining this. 
New sherpa package release has just been pushed to GitHub: v20251108
Lots of changes, so please advise of any issues. Hopefully, things should keep-on working as they did before. 
nzbToMedia QPKG operation has changed too: How to use the new nzbToMedia QPKG · OneCDOnly/sherpa Wiki · GitHub
Also, for users of Sonarr, Readarr and Whisparr only, please reboot your NAS after upgrading your QPKGs. You may see failures reported during the upgrade process: ignore these and reboot anyway.
Long time no see.. The scripts folder has disappeared.. in today’s update..its not at share/CACHEDEV1_DATA/.qpkg/nzbToMedia/repo-cache
Hi mate.
Where is nzbToMedia installed?
getcfg nzbToMedia Install_path -f /etc/config/qpkg.conf
Is there a repo-cache below this directory?
ll $(getcfg nzbToMedia Install_path -f /etc/config/qpkg.conf)/repo-cache
I had to persevere but its working now the scripts are now available.. thanks
The scripts are in the repo root directory now..
The nzbToMedia scripts should be there when the GitHub repo is cloned.
Have you added your own scripts to repo-cache?
@Potestus, it’s very important you don’t put your own scripts in repo-cache. This location is erased whenever you upgrade nzbToMedia.
Let me know if you have your own scripts and we’ll work out how to deal with them.
I’m now getting watcher 3 errors in sab?
Watcher3: Failed to post-process - changed status to Disabled!
I still run this a sideload
ClamAV * incompatible author N/A N/A N/A /share/CAC>
Entware - enabled, active unsupported 1.03a 1.03a /share/CAC>
Headphones - enabled, active start (OK) 251116 dynamic /share/CAC>
LazyLibrarian - enabled, active start (OK) 251116 dynamic /share/CAC>
nzbToMedia - enabled, active start (OK) 251116 dynamic /share/CAC>
OSickGear - enabled, active start (OK) 250628 dynamic /share/CAC>
Par2turbo - enabled, active unsupported 1.2.0 1.2.0 /share/CAC>
SABnzbd - enabled, active start (OK) 251116 dynamic /share/CAC>
sherpa - enabled, active start (OK) 251101 251101 /share/CAC>
Unrar - enabled, active unsupported 7.0.8 7.01 beta 1 /share/CAC>
What should I do.. it still works but tge error is annoying..?
Hi mate.
Watcher3 isn’t developed anymore. It will continue to break in interesting and unpredictable ways as there’s no-one to fix it.
Try Radarr instead.
Hello @onecd…. It’s me again… the needy noob that only seems to pop up when things go sideways
Recently my QNAP had an update. Not sure if that’s when it went pear shaped, but alas, here I am.
I am able to open and see most of the programs installed by sherpa - radarr, sonarr, etc. However, my downloader SABNZBD won’t connect. I’ve stopped/restarted it from within app center, but I am greeted with a ERR_CONNECTION_REFUSED when I go to the local IP:8900…
Using putty, I tried sudo sherpa reinstall sabnzbd but it did not resolve the issue… I tried man, I tried…
Without you, this qnap would be in the dumpster
Hi mate.
Can you please check the status of SABnzbd with the service script?
/etc/init.d/sabnzbd.sh s
- QPKG enabled: true
- application auto-update: true
- active git branch: master
- daemon PID: none
Hoping this is what you’re looking for?
Yup, that’s the one.
Now, try starting it:
/etc/init.d/sabnzbd.sh start
! unable to install addons: virtual Python environment does not exist
= source: sabnzbd.sh, action: start, time: Wed 3 Dec 2025 11:59:13 PM CST, result:
Hmmm…
As a new user to this forum I can only reply 3 times to the same topic “temporarily”. So I will have to edit this (if it’ll allow me) to answer you…
[Eric@QNAP451 ~]$ sudo /etc/init.d/sabnzbd.sh clean
- source: sabnzbd.sh, action: clean, time: Thu 4 Dec 2025 12:02:59 AM CST, load: 0.18
- package: 251121, service: 251121, library: 251121
- QPKG enabled: true
- application auto-update: true
- active git branch: master
- daemon PID: none
> clean local repository: OK
> clean virtual Python environment: OK
> clean PyPI cache: OK
> clean temp path: OK
= source: sabnzbd.sh, action: clean, time: Thu 4 Dec 2025 12:02:59 AM CST, result: OK, elapsed: 76ms, load: 0.18
[Eric@QNAP451 ~]$ sudo /etc/init.d/sabnzbd.sh start
- source: sabnzbd.sh, action: start, time: Thu 4 Dec 2025 12:03:14 AM CST, load: 0.14
- package: 251121, service: 251121, library: 251121
- QPKG enabled: true
- application auto-update: true
- active git branch:
- daemon PID: none
- file exists: /opt/bin/git
> create 'SABnzbd' from remote repository: OK
- active git branch: master
> create new virtual Python environment: failed
> create QPKG 'pip' config: OK
> add location '/share/CACHEDEV1_DATA/.qpkg/SABnzbd/pip-cache' as 'pip' cache: OK
> add location '/share/CACHEDEV1_DATA/.qpkg/SABnzbd/qpkg-wheels' to 'pip' search path: OK
! unable to install addons: virtual Python environment does not exist
= source: sabnzbd.sh, action: start, time: Thu 4 Dec 2025 12:03:15 AM CST, result: FAILED, elapsed: 1,431ms, load: 0.14
[Eric@QNAP451 ~]$
Keeping them up to date? Not intentionally… unless it does it automatically, I haven’t executed any commands to do so. The Qnap does the firmware update magic, but I try not to get under the hood with Sherpa as I’m already embarrassed enough to ask for help as it is….
Ok, let’s clean and start it:
/etc/init.d/sabnzbd.sh clean
/etc/init.d/sabnzbd.sh start
BTW: have you been keeping your sherpa QPKGs up-to-date? 