Can't add any nzb files - Failure in tempfile.mkstemp. Docker & NFS

[unsoldier]

I am setting up sabnzbd / radarr / sonarr etc on a docker host and having a problem when trying to add new media via *arr. sabnzbd won't create the download properly. It seems like a permissions problem but I can't figure out why sabnzbd is unhappy. I am able to shell into the sabnzbd docker container and create all the files & directories in the exact paths it's complaining about in the log file. Any ideas?

The paths are on a NFS share on a TrueNAS box. Permissions are mapped via GID that matches the docker container user's group, and as I said if I shell into the container I can manually create everything listed in the log. I can't post the log because the forum says I'm not allowed to post links (???)

[unsoldier]

Trying to post log again. Ok so after a lot of trial and error I found it will let me post if I change the py extensions to something else, so I changed all py to .PYTHON, otherwise the log is unchanged. Would be nice if the forum didn't prevent you from posting logs straight out of the application. You literally can't type "period p y" together without it blocking you.

Code: Select all

2022-07-08 09:28:05,658::INFO::[nzbparser:89] Attempting to add Heavy.Metal.1981.1080p.BluRay.x264.YIFY.nzb
2022-07-08 09:28:05,660::INFO::[filesystem:703] Creating directories: /data/usenet/download/Heavy.Metal.1981.1080p.BluRay.x264.YIFY
2022-07-08 09:28:05,661::INFO::[filesystem:703] Creating directories: /data/usenet/download/Heavy.Metal.1981.1080p.BluRay.x264.YIFY/__ADMIN__
2022-07-08 09:28:05,661::INFO::[filesystem:1233] Saving /data/usenet/download/Heavy.Metal.1981.1080p.BluRay.x264.YIFY/__ADMIN__/Heavy.Metal.1981.1080p.BluRay.x264.YIFY.nzb.gz
2022-07-08 09:28:05,683::ERROR::[filesystem:1100] Failure in tempfile.mkstemp
2022-07-08 09:28:05,683::INFO::[filesystem:1101] Traceback: 
Traceback (most recent call last):
  File "/app/sabnzbd/filesystem.PYTHON", line 1094, in get_new_id
    fd, path = tempfile.mkstemp("", "SABnzbd_%s_" % prefix, folder)
  File "/usr/lib/python3.9/tempfile.PYTHON", line 332, in mkstemp
    return _mkstemp_inner(dir, prefix, suffix, flags, output_type)
  File "/usr/lib/python3.9/tempfile.PYTHON", line 251, in _mkstemp_inner
    fd = _os.open(file, flags, 0o600)
PermissionError: [Errno 1] Operation not permitted: '/data/usenet/download/Heavy.Metal.1981.1080p.BluRay.x264.YIFY/__ADMIN__/SABnzbd_nzf_1ppn86id'
2022-07-08 09:28:05,683::WARNING::[nzbstuff:794] Invalid NZB file Heavy.Metal.1981.1080p.BluRay.x264.YIFY.nzb, skipping (error: )
2022-07-08 09:28:05,683::INFO::[nzbstuff:795] Traceback: 
Traceback (most recent call last):
Traceback (most recent call last):
  File "/app/sabnzbd/nzbstuff.PYTHON", line 791, in __init__
    sabnzbd.nzbparser.nzbfile_parser(full_nzb_path, self)
  File "/app/sabnzbd/nzbparser.PYTHON", line 467, in nzbfile_parser
    nzf = sabnzbd.nzbstuff.NzbFile(file_date, file_name, raw_article_db_sorted, file_bytes, nzo)
  File "/app/sabnzbd/nzbstuff.PYTHON", line 361, in __init__
    self.nzf_id: str = sabnzbd.filesystem.get_new_id("nzf", nzo.admin_path)
  File "/app/sabnzbd/filesystem.PYTHON", line 1104, in get_new_id
    raise IOError

[unsoldier]

I believe I found the issue thanks to post 127328

I think the problem is with permissions on the sabnzbd config path and not the path it's trying to manipulate downloads on. More to come.

edit: Nah that wasn't it, if I point downloads at the docker host config paths it works fine. So this is something wrong with TrueNAS permissions I guess. I don't understand why I seem to have full permissions when I shell into the container and access the NFS paths, but whatever the reason this doesn't appear to be a sabnzbd issue.

[sander]

Trying to post log again. Ok so after a lot of trial and error I found it will let me post if I change the py extensions to something else, so I changed all py to .PYTHON, otherwise the log is unchanged. Would be nice if the forum didn't prevent you from posting logs straight out of the application. You literally can't type "period p y" together without it blocking you.

It triggers only on new users like you.
It's against spammers, and triggers on anything that is a bit like an URL like blabla.py
Wokaround: pastebin . com / bjbjbjbj

[sander]

Have you pointed "Temporary Download Folder" also to your TrueNAS NFS? If so: why, and why not inside your docker? Faster, and guaranteed no rights problems.

[unsoldier]

So this turned out to be something related to sharing the TrueNAS dataset with both Samba and NFS. I know that's against best practice and I was just doing it since I'm migrating a working sabnzbd / *arr setup from a Windows server to a Ubuntu docker setup. It was just going to be temporary.

The solution was to create a new dataset in TrueNAS and shared it with only NFS. After that everything worked fine, set up exactly as I had previously but without Samba sharing on the dataset.

sander - Yes I have everything set up on the NAS all in the same mount tree per the TRaSH guide so that hard links work and it can do moves instead of copies. I'm sure the issue had to do with adding NFS to a pre-existing Samba share. I'm leaving Windows behind and was just trying to make the migration easier. Live and learn!

[sander]

Good it works.

Out of curiosity: what speed does SAB experience from the TrueNAS drive? Test via:

In SABnzbd's upper right corner, click on the wrench symbol ("Status and interface options"), then click on first tab Status, and there click on the Refresh Arrow. Post the values of the lower part here.

[unsoldier]

It's testing around 58 MB/s for both folders. Not sure why sabnzbd shows such a low value since I get 150MB/s on a regular file copy between the docker host and the share.

The virtualization hosts and TrueNAS are all connected to a 10GB network but the TrueNAS PC is absolutely ancient so it barely gets 50% over regular 1GB network speeds.

Doesn't really matter all that much since my internet speed is still well below all those values!

[Moaning1]

So this turned out to be something related to sharing the TrueNAS dataset with both Samba and NFS. I know that's against best practice and I was just doing it since I'm migrating a working sabnzbd / *arr setup from a Windows server to a Ubuntu docker setup. It was just going to be temporary.

I created an account just to thank you for this. I spent a lot of time debugging.
After removing one method of sharing, it worked.