SABnzbd Forums

Version: 1.2.0 [1be50eb]
OS: Debian 8.7
Install-type: python source/OMV package
Skin (if applicable): Default
Firewall Software: None
Are you using IPV6? no
Is the issue reproducible? yes

Since the 1.2.0 update, my nzbToMedia script fails with the following error
I have checked the permissions for the script and folder and they are set to 777. I am able to run the script manually, so it's not the script.

Is this just something obvious that I'm missing?

Thanks

what is the output of:

-rwxrwxrwx 1 sabnzbd users 6999 Jan 3 00:25 /media/Data/downloads/scripts/nzbToMedia/nzbToSickBeard.py

That looks good to me.

The SABnzbd code that gives the message is in
sabnzbd/newsunpack.py: So apparantly "os.access(command[0], os.X_OK)" results in a False on your system, or "no X bit". Can you check in python:
FWIW:
... so it could also be a no-access problem

There's also the possibility of the filesystem being mounted with the noexec option.

Also comes up false here
>>> import os
>>> print os.access("/media/Data/downloads/scripts/nzbToMedia/nzbToSickBeard.py", os.X_OK)
False

mcawley wrote:Also comes up false here
>>> import os
>>> print os.access("/media/Data/downloads/scripts/nzbToMedia/nzbToSickBeard.py", os.X_OK)
False

Good: now it's python / OS thing, not a SABnzbd problem.

Do you know how to verify jcfp's hypothesis? If not: post the output of "mount" here.

I can run the script manually './nzbToSickBeard.py' and via a cron job.

mount output is below (I run openmediavault with a UnionFileSystem)

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=504323,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=811568k,mode=755)
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=23,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
9ca7a9ac-a72e-4189-8416-3a4e532d518f:a3afe1f6-8955-4a25-9f8f-d9c5f153d4d3 on /media/0c50dfbd-62d5-4c40-98f5-1a67c44d7001 type fuse.mergerfs (rw,relatime,user_id=0,group_id=0,allow_other)
9ca7a9ac-a72e-4189-8416-3a4e532d518f:a3afe1f6-8955-4a25-9f8f-d9c5f153d4d3 on /export/TV-Kids type fuse.mergerfs (rw,relatime,user_id=0,group_id=0,allow_other)
9ca7a9ac-a72e-4189-8416-3a4e532d518f:a3afe1f6-8955-4a25-9f8f-d9c5f153d4d3 on /export/TV type fuse.mergerfs (rw,relatime,user_id=0,group_id=0,allow_other)
9ca7a9ac-a72e-4189-8416-3a4e532d518f:a3afe1f6-8955-4a25-9f8f-d9c5f153d4d3 on /export/Music type fuse.mergerfs (rw,relatime,user_id=0,group_id=0,allow_other)
9ca7a9ac-a72e-4189-8416-3a4e532d518f:a3afe1f6-8955-4a25-9f8f-d9c5f153d4d3 on /export/Movies-Kids type fuse.mergerfs (rw,relatime,user_id=0,group_id=0,allow_other)
9ca7a9ac-a72e-4189-8416-3a4e532d518f:a3afe1f6-8955-4a25-9f8f-d9c5f153d4d3 on /export/Movies type fuse.mergerfs (rw,relatime,user_id=0,group_id=0,allow_other)
/dev/sdb1 on /media/9ca7a9ac-a72e-4189-8416-3a4e532d518f type ext4 (rw,noexec,relatime,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)
/dev/sdc1 on /media/a3afe1f6-8955-4a25-9f8f-d9c5f153d4d3 type ext4 (rw,noexec,relatime,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
/dev/sda1 on /var/lib/docker/aufs type ext4 (rw,relatime,errors=remount-ro,data=ordered)
proc on /run/docker/netns/default type proc (rw,nosuid,nodev,noexec,relatime)
none on /var/lib/docker/aufs/mnt/f6778d0933693d09bd30be25370c6979ce79a2bfe867d528d13afab196870e26 type aufs (rw,relatime,si=35e22056cb65b70c,dio,dirperm1)
shm on /var/lib/docker/containers/4268988e2bce9b4d9beb0f1f2c9f5b668546ddfdb4ea45376e8dfca6b9eaed2b/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
none on /var/lib/docker/aufs/mnt/8b327c2bbdf545ad8c19b688543d846a0c7ab110adf705651777f45955c37424 type aufs (rw,relatime,si=35e2205600f5f70c,dio,dirperm1)
shm on /var/lib/docker/containers/da9653904913d057683651972558483adec3b930c52f88596f23fd8fa11f9f7b/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=405784k,mode=700,uid=1000,gid=100)

As an experiment I disabled the raise IO Error command after the error being logged, just to see what happened.

The script is able to run normally when called from Sab, so it appears the issue is with the detection rather than the actual permissions.

Not sure if this helps.

Mind sharing the output of:

mcawley wrote:As an experiment I disabled the raise IO Error command after the error being logged, just to see what happened.

The script is able to run normally when called from Sab, so it appears the issue is with the detection rather than the actual permissions.

Not sure if this helps.

It's only run because SAB manually puts 'python' in front of it, which ignores the system's execute permissions.

jcfp wrote:Mind sharing the output of:

Code: Select all

namei -lx /media/Data/downloads/scripts/nzbToMedia/nzbToSickBeard.py

safihre wrote:It's only run because SAB manually puts 'python' in front of it, which ignores the system's execute permissions.

So the post-processing bombs out if the execute permission reports as not set, even though it not required?

This is a security measure.
Otherwise someone with access to your SAB (but not your computer) could download a script using usenet and use it to take over your computer.
This actually happened.

So now we require for the user to manually set the execute permissions so no non-user-defined script can be ran from SAB.
This is standard practice for other scripts as well.

Thanks for the update. That makes sense, although not sure why it's failing to detect that the script already has execute permission.