Sabnzbdplus 0.7.1 errors xbmcbuntu

[quotaholic]

Hi All, First post. Just installed Sabnzbdplus last week. Running on xbmc-live. I mapped my NAS shares to my local home folder via nfs and fstab as /home/xbmc/NAS/X3/Downloads and /home/xbmc/NAS/X3/Downloads/Incomplete respectively. Worth noting that my X3 share is on a NTFS volume. Up to this morning my incomplete folder was on my local drive. This morning I woke to a broken sabnzbdplus as it said it could not write to logfile. There was a 32gb download it was working on just before going to bed. Looking at the folders and logs I can see errors on this download that look similar to the error I will post below. This morning I removed sabnzbdplus and reinstalled. Chowned the log file itself and only then could I get sabnzbdplus to start. Seems like that large download broke something. Once it was up and running again I tried to add a download and this is what came back:

Traceback (most recent call last):
File "/usr/share/sabnzbdplus/cherrypy/_cprequest.py", line 618, in respond
cherrypy.response.body = self.handler()
File "/usr/share/sabnzbdplus/cherrypy/_cpdispatch.py", line 25, in __call__
return self.callable(*self.args, **self.kwargs)
File "/usr/share/sabnzbdplus/sabnzbd/interface.py", line 2361, in add
orphan_add(kwargs)
File "/usr/share/sabnzbdplus/sabnzbd/interface.py", line 1075, in orphan_add
sabnzbd.nzbqueue.repair_job(path, None)
File "/usr/share/sabnzbdplus/sabnzbd/decorators.py", line 43, in call_func
return func(*params, **kparams)
File "/usr/share/sabnzbdplus/sabnzbd/decorators.py", line 31, in newFunction
return f(*args, **kw)
File "/usr/share/sabnzbdplus/sabnzbd/nzbqueue.py", line 883, in repair_job
NzbQueue.do.repair_job(folder, new_nzb)
File "/usr/share/sabnzbdplus/sabnzbd/nzbqueue.py", line 164, in repair_job
self.add(nzo)
File "/usr/share/sabnzbdplus/sabnzbd/decorators.py", line 31, in newFunction
return f(*args, **kw)
File "/usr/share/sabnzbdplus/sabnzbd/nzbqueue.py", line 294, in add
nzo.nzo_id = sabnzbd.get_new_id('nzo', nzo.workpath, self.__nzo_table)
File "/usr/share/sabnzbdplus/sabnzbd/decorators.py", line 31, in newFunction
return f(*args, **kw)
File "/usr/share/sabnzbdplus/sabnzbd/__init__.py", line 798, in get_new_id
raise IOError
IOError

I am about to move my incomplete directory back to the local drive (small SSD). It seems logical that permissions are whacky on NTFS. The only question I have is if I have a 32gb file broken in to rars would it make sense that I would error if I set the incomplete dir to 40gb in settings? Not sure why that logfile was changed in permissions.

Just moved my incomplete directory back to local volume and now I get:

2012-07-16 09:37:14,361 WARNING: Invalid NZB file Four Rooms 1995 1080p BluRay AC3 DTS ML x264 HDC.nzb, skipping (reason=, line=0)

and

Failure in tempfile.mkstemp

Chowned everything in incomplete as well as the directory itself after aiming at the local drive. No luck.

No luck, I cannot seem to get sabnzbdplus back on its feet. Any tips?

[shypike]

SABnzbd is naive in the sense that it assumes that any file system that it works on,
behaves like the native file system of the platform.
If a volume behaves differently, then it's a bit hard to predict what will happen.
In NTFS newly created files normally automatically inherit right from their parent folders.
On Linux, SABnzbd will try so set rights according to what your "permissions" value in Config->Folders says.
It doesn't know that NTFS is underneath.
When no permissions are set explicitly, the session umask is used instead.
I'm not sure if that will work in combination with NTFS.
BTW: there's no explicit rights setting for the logfile.

[quotaholic]

Interesting. After chowning the log I was able to restart and get a web interface back.

The error I sent was a result of re-adding something from the orphaned jobs list in "Status".

Watching the log I see permissions problems in the /Downloads/incomplete/downloading-file/__ADMIN__ directory. I went in and chowned the __ADMIN__ directory for a re-added download and then things started to work fine. Assuming that I will need to do this for each orphaned job I am wondering if reinstalling sabnzbdplus caused this or if I should avoid using NTFS volumes? Sure enough going in and chowning the __ADMIN__ dir lets me add to download queue without errors.

Still kinda wondering how this broke in the first place. If the 32 gb pack of rars was downloading then permissions should have been okay. Unless I ran out of room for unpacking but I fail to see how that would result in a permissions change on files and directories in question. In the interface I can see 63.57 available in (Temp). I kinda have to figure that since sabnzbdplus wants to assign permissions to files as it deposits in the completed directory and that since NTFS wont return a call on said permission change then NTFS connected to a host running EXT4 is not a great idea. Potential instability.

[shypike]

Did you ever run SABnzbd under different user credentials.
Like once a an automatic service and once from a user account.
Not sure what to make of the NTFS situation.
SABnzbd never does anything with chown.
When it tries to apply the umask (converted to permissions) to completed folders/files,
it will not report any errors when that fails.
It will report errors when you set an explicit permissions value in Config->Folders.
Of course I have no idea what the OS will do when SABnzbd attempts to set permissions on an NTFS drive.

You could experiment a bit with Python to test this.

Code: Select all

import os
os.chmod(filename, permissions)

where permissions is the familiar octal number, in Python written like this (the leading 0 (zero) means octal): 0777