Do you experience problems during downloading?
Check your connection in Status and Interface settings window.
Use Test Server in Config > Servers.
We will probably ask you to do a test using only basic settings.
Do you experience problems during repair or unpacking?
Enable +Debug logging in the Status and Interface settings window and share the relevant parts of the log here using [ code ] sections.
dkiar wrote:
I wonder why SAB isnt set to use the cache by default.
100Mb/s? wow.
SABnzbd is often used on low-memory systems.
I could have a look at how much is available and then set a cache accordingly.
But I'd rather spend my time on improving the assembly method.
That's 100Mbit/sec, resulting in a maximum of about 11MByte/sec.
BTW: no caps either
I have exactly the same problem, my user has write access to a network drive, but i get the "Incorrect parameter Cannot create complete_dir folder"-message. Was there any solutions to this, or did it just fix itself? It doesn't work for me, and I'm already at the newest version (0.65)
This issue has come back for me on the newest version.
I believe it to be a write permissions based issue. Iv yet to properally troubleshoot and test.
I imagine its based on the permissions of the account that starts the sab process / service and the flow on permissions into the share one it pointing it at.
I think if you log into the machine with Sab on it, as administrator, start Sab as administrator, make sure that administrator account on that local machine has RW access to the share; it works.
I run sab on a server though. Sab starts with a scheduled task using another account (though in the local admin group) That account has RW on the required share.
Thanks for the tip, unfortunately logging in as admin, and starting as admin didn't solve my problem. Interestingly enough setting a network shared folder for a specific profile works completely fine, so thats a kind of work-around for the download-folder, but i still need to get the temp-folder to a network drive.
This happened to me with the current 6.9. Same user running the sab service has the same access to a network share. Using windows explorer works just fine but sab throws back an error. The good guys on chat suggested that I use mapped folder to network share with "subst" which didn't work but that gave me the idea to use a symbolic link instead. Worked like a charm! Now this isn't my ideal solution (personal preference) but it will work fine until another solution presents itself.
example:
FreeNAS mapped to Z: on my win7 desktop (which sab can no longer access) - F: is a physical drive on my desktop.
symbolic link (from a command prompt): mklink /d F:\NAS \\freenas\NAS
"F:\NAS" becomes the symbolic link to the same network share that Z: is mapped to and sab can write to it just fine.
KrakaJap wrote:This happened to me with the current 6.9. Same user running the sab service has the same access to a network share. Using windows explorer works just fine but sab throws back an error. The good guys on chat suggested that I use mapped folder to network share with "subst" which didn't work but that gave me the idea to use a symbolic link instead. Worked like a charm! Now this isn't my ideal solution (personal preference) but it will work fine until another solution presents itself.
example:
FreeNAS mapped to Z: on my win7 desktop (which sab can no longer access) - F: is a physical drive on my desktop.
symbolic link (from a command prompt): mklink /d F:\NAS \\freenas\NAS
"F:\NAS" becomes the symbolic link to the same network share that Z: is mapped to and sab can write to it just fine.
This worked for me. Thanks I started experiencing this issue with a recent version and all subsequent versions. Quite annoying!
Using Windows 7 Home Premium 64 bit. And a Linux based NAS that has never given me a problem
Are you using 0.6.14?
We recently fixed a small issue where SABnzbd's Sort function would send sometimes a slash /
instead of a backslash \ in paths. Windows itself has no issues with that
but it seems that some NAS systems get confused by this.
Other than fixing the (semi) bug I just described (which has been done for 0.6.14), there's nothing we can do.
Paths are transparent for SABnzbd, it just sends them to the OS.
UNC paths (\\server\share) are fully supported, and work fine for most NAS systems connected to Windows.
The trouble you describe looks more like compatibility issues between the NAS and Windows.
Well I've been using SABnzbd for many versions with the same OS and NAS, and only until these last few releases did I start to have the problem. And r/w access to the NAS via windows explorer has always worked.
