Let’s check that file then:
cat /etc/config/def_share.info
[/share/MD0_DATA/.qpkg/SABnzbd] # cat /etc/config/def_share.info
[SHARE_DEF]
defPublic = Public
defDownload = Download
defMultimedia = Multimedia
defRecordings = none
defUsb = Usb
defWeb = Web
defVolMP =
Well, we can fix that:
setcfg SHARE_DEF defVolMP /share/MD0_DATA -f /etc/config/def_share.info
Then check it was written to file:
cat /etc/config/def_share.info
[/share/MD0_DATA/.qpkg/SABnzbd] # cat /etc/config/def_share.info
[SHARE_DEF]
defPublic = Public
defDownload = Download
defMultimedia = Multimedia
defRecordings = none
defUsb = Usb
defWeb = Web
defVolMP = /share/MD0_DATA
Excellent.
Now try starting SABnzbd again:
/etc/init.d/sabnzbd.sh start debug
No need to post the output unless you see errors.
Started, now need to reconfigure (restore…)
Great, huge thanks! Suppose this also solves the sickgear and nzbtomedia issue…
It might, it might not. 
With regard to restoring: it was the sherpa backup location that couldn’t be calculated. So, you may find there’s nothing to restore. Unless you did a manual config backup of the SABnzbd files.
ok, i try to reconfigure it, seems could not find anything…
and tomorrow will try the others… Thanks for your help!
No worries. You won’t need to diagnose any further, unless SickGear or nzbToMedia have different faults.
Hi OneCD,
I have another question. Since the last update of SABNZBD the extraction process after the download takes way more time that it did previously.
Have you heard from other user having the same problem and do you have any idea what the reason could be? I have a QNAP TS-431XeU, which is per so not really a powerhouse but an 8 gig file takes now more than an hour to unpack.
BR
Hi mate, no I haven’t heard of any unpacking issues so-far.
You could try asking about this on the SABnzbd forum. The developers may have a few suggestions.
I’ll keep an eye-out for your post, and assist where I can.
Thanks OneCD.
I have already tried optimizing the settings (disabling 7zip, adjusting threads, etc.) and checked system resources, but the bottleneck seems to be related to the new SABnzbd binary/optimization for the ARMv7 architecture.
Could you please advise if there is a known optimization issue for this architecture, or—ideally—how I can use Sherpa to downgrade/reinstall version 3.7.2?
Thanks for your help!
Can you provide a link to this change please? If it’s an optimisation that only affects binary releases, it might not affect installs where SABnzbd is run from source.
sherpa doesn’t support user package downgrades. By-design, it’s intended to offer only the current latest stable release for each application. sherpa doesn’t support user package “pinning” (holding a package at a specific version).
Hi @OneCD, is it possible to update Transmission version to latest 4.1.3.
It seems stuck at 4.0.6 since some time. Am I missing something?
Thank you!
Hi mate, and welcome to the new forum. 
We’re limited to the version available in Entware. The sherpa Transmission QPKG is just a convenience wrapper for the Entware binary.
Hi,
Thanks for the quick feedback!
To be completely transparent: I’ve been troubleshooting this performance drop with Gemini, which analyzed my system resources (Resource Monitor showing 0% I/O wait and ~30% CPU load during extraction) and suggested that the bottleneck might stem from how SABnzbd v4.0+ handles unrar process I/O, subprocess pipes, and memory buffering in Python on 32-bit ARM architectures (armv7l).
Since the major rewrite in version 4.0.0, the internal process management for external extractors was refactored (as detailed in the SABnzbd 4.0.0 Release Notes). On 32-bit ARM systems, similar extraction throttling has been discussed in community threads (e.g., SABnzbd Forum Thread on ARM Unpack Throttling and GitHub Issue #2341).
Understood regarding sherpa’s design policy on downgrades and package pinning!
Since sherpa runs SABnzbd from source, is there a recommended way or environment variable within sherpa to specify a custom/legacy unrar binary path, or tweak the subprocess I/O priority for external extractors on ARMv7?
Thanks again for your time and support!
Hi mate, the link to the SABnzbd forum for unpacking isn’t correct. It links to a different topic.
I notice though, you’re comparing the ancient 3.7.2 (and 4.0.0) against the new 5.1.0
Regarding tweaking the unrar priority: that’s a good question for the SABnzbd devs. I don’t think it’ll help though. The AL-314 in your NAS is already terribly underpowered as a processor.
For the location of the binary, I think SABnzbd only checks $PATH for the unrar executable. Do you have an unrar executable you’d rather use instead of the Unrar QPKG?
Hi OneCD,
Thanks for the clarification! You’re totally right about the forum link, my bad.
Just to clarify on the timeline: with the release running around December 2025 (late 4.x branch), extraction on this AL-314 NAS was still working perfectly fast. The severe drop down to ~4 MB/s only started after upgrading to the newer SABnzbd 5.x releases via sherpa one or two weeks ago.
The following assumption is AI supported.
It seems like the I/O piping changes in SABnzbd 5.x specifically hit 32-bit ARM (armv7l) architectures hard, where the CPU can’t cope with the new process buffering overhead.
Out of curiosity: where does Sherpa’s Unrar QPKG place the unrar executable in $PATH? Just in case I want to experiment with different binary builds.
Thanks again for your support!
If I understand correctly, the pipelining was to do with downloading, not extraction. Extraction has always been handled by external utilities. These external utils haven’t changed in quite a while.
For your NAS arch (a41), the Unrar QPKG (by @QNAP_Stephane) is used, and creates a symlink in /usr/bin.
If you’d still like to try other unrar binaries, it’s safe to delete the symlink back to the Unrar QPKG:
rm /usr/bin/unrar
… then place (or symlink to) your unrar binary into /usr/bin.
I think SABnzbd only checks for the unrar location during startup, so you’ll need to restart SABnzbd when your new unrar binary is installed:
/etc/init.d/sabnzbd.sh restart
Check the SABnzbd application log to confirm it successfully located the new file.
When the experiments have concluded, restart the Unrar QPKG to recreate the symlink:
/etc/init.d/Unrar.sh restart
==Translation added by Dolbyman==
Hello OneCD!
Thank you so much for all your efforts.
I wanted to update sabnzbd today, and now it’s not working. The update failed, and now sabnzbd won’t even start. Sherpa fix and other troubleshooting methods didn’t help. I completely uninstalled sabnzbd and tried reinstalling it, but that didn’t work either. I noticed that after every command related to installation or updates, the first line displayed a warning:
“Warning: Remote file download failed”
Do you have any idea what the problem might be?
Thanks for your help,
Martin