Cannnot change permissions [TrueNAS ]

[iainfm]

Hi,

I upgraded sabnzb on my TrueNAS box last night (using the official iXsystems plugin) to 3.5. After doing that I was getting errors on downloads such as

2022-02-14 22:20:58,552::ERROR::[filesystem:611] Cannot change permissions of /media/Download/_UNPACK_<filename>

Enabling debug logging, the sabnzb.log file contains messages such as

2022-02-15 09:14:20,084::DEBUG::[filesystem:606] Applying permissions 0o100666 (octal) to /media/Download/_UNPACK_<filename>

After a quick google, the fix seemed to be to clear the permissions field in the settings, but it was already empty. Adding 777, then removing it didn't fix the issue.

I think the root of my problem is that the volume/pool where Sabnzb writes its files to has extended unix (Windows-y) permissions, so doing something simple from the command prompt like chmod 666 test gives an error "Operation not permitted".

At the moment I've 'fixed' the issue by changing line 611 of filesystem(dot)py from logging(dot)debug to logging(dot)info*, but it maybe needs either a global option to disable chmodding or an if statement around the preceeding os.chmod to not execute if the permissions setting is empty. Or something! ;D

Thanks,
Iain

* apologies for the formatting. Using the proper filename triggers the 'new users cannot post links' message.

[sander]

TrueNAS, so FreeBSD based? I don't know if relevant, just mentioning.

So that all happens here: https://github.com/sabnzbd/sabnzbd/blob ... #L603-L612

Some thoughts / remarks:
- I thought that with 3.5, if permissions were not filled out, that nothing happened. https://github.com/sabnzbd/sabnzbd/blob ... #L619-L650 seems to confirm that. So are you sure nothing is filled out?
- "extended unix (Windows-y) permissions" ... do you means ACL?
- what happens when you do a manual chmod on an ACL directory?
- why does SAB do a chmod on _UNPACK ? That is only for internal SAB usage ... /

[safihre]

If Permissions is left empty, we only apply Permissions if we find a file with execute-bits turned on. So that might be the case here..

[sander]

If Permissions is left empty, we only apply Permissions if we find a file with execute-bits turned on. So that might be the case here..

Interesting: my Linux, with a mounted exFAT-drive, has x-bits on on all directories and files:

Code: Select all

drwxrwxrwx 1 root root    4096 jan  7  2021  ./
drwxrwxrwx 1 root root  569344 feb 15 15:49  ../
-rwxrwxrwx 1 root root 7535370 jun 18  2018 jfjfjfjfjjffj

So that triggers does a chmod ?

However, because it is exFAT, no rights let ACL is possible, so no conflict there.

Code: Select all

sander@brixit:~$ cat .sabnzbd/sabnzbd.ini | grep -i permi
permissions = ""

... so permissions not set, but SAB does set permissions ... so because of the x-bit set on all files/directories on that exFAT-partition?

Code: Select all

2022-02-15 13:00:32,149::DEBUG::[filesystem:606] Applying permissions 0o100666 (octal) to /media/zeegat/_UNPACK_Spi
2022-02-15 13:00:32,149::DEBUG::[filesystem:606] Applying permissions 0o100666 (octal) to /media/zeegat/_UNPACK_Spi
2022-02-15 13:28:41,902::DEBUG::[filesystem:606] Applying permissions 0o100666 (octal) to /media/zeegat/incomplete/
2022-02-15 13:29:39,872::DEBUG::[filesystem:606] Applying permissions 0o100666 (octal) to /media/zeegat/incomplete/
2022-02-15 13:29:40,413::DEBUG::[filesystem:606] Applying permissions 0o100666 (octal) to /media/zeegat/_UNPACK_Jac
2022-02-15 13:29:40,413::DEBUG::[filesystem:606] Applying permissions 0o100666 (octal) to /media/zeegat/_UNPACK_Jac

Setting permissions on exFAT does not work, so it's useless. And, hypothesis: that triggers the problem for the OP???

[sander]

@iainfm

is this your post: https://www.reddit.com/r/SABnzbd/commen ... saying_it/

If so: is your SAB writing to an external drive?

[iainfm]

@iainfm

is this your post: [removed because I can't post links]

If so: is your SAB writing to an external drive?

Hi,

No, that's someone else's post. My drives are all internal. Somewhere (I can't remember where - I'm a bit of a truenas noob, sorry) I enabled Windows-like permissions to get something else to work. I suspect if I changed Sabnzb to use a volume with standard unix permissions I wouldn't see this problem.

Thanks for all the responsed - appreciated!

[iainfm]

TrueNAS, so FreeBSD based? I don't know if relevant, just mentioning.

So that all happens here: [snip]

Some thoughts remarks:
- I thought that with 3.5, if permissions were not filled out, that nothing happened.
[snip] seems to confirm that. So are you sure nothing is filled out?
- "extended unix (Windows-y) permissions" ... do you means ACL?
- what happens when you do a manual chmod on an ACL directory?
- why does SAB do a chmod on _UNPACK ? That is only for internal SAB usage ...

Hi, answers in order below:

Yes, I believe TrueNAS is based on FreeBSD.

Yep, the first link is the bit I've changed - logging(dot)error to logging(dot)info on the 'cannot change permissions' line.

I'm sure nothing is filled out in permissions, and sabnab.ini contains permissions=""

Yes, Windows-y = ACL

Manual chmod on anything gives "Operation not permitted". Any new folder created gets the permissions "drwxrwxrwx+" (according to ls -l).

No idea about the _UNPACK question, sorry! Suspect a combination of the execute bit chmod case, and new folders getting the execute bit set automatically.

Edit: Also suspect it's the removexbits() function that's causing this, which (by my reading) runs irrespective of whether custom_permissions are/is set.

Many thanks,
Iain

[safihre]

Will be updated in 3.5.1, it won't report errors anymore.

[iainfm]

Will be updated in 3.5.1, it won't report errors anymore.

That's great - thanks very much!

[LYZkN3]

Hi,

Prerequisites
- I'm quite new to SABnzb and a noob concerning these issues...
- I'm not sure, answering this post, which was opened over a year ago - is the correct way to raise this issue again. Let me know, if there is a better way...

Question: Is this behaviour back in?

What did I do?
- I freshly installed SABnzb (3.7.1 [479daf0]) within a TrueNAS jail (my NAS share ist Windows ACL based, too)
- I left the "Permissions for completed downloads" field (within the folder settings) empty
What was the result
- I get an error message instead of a downloaded file. The error message does not complain about the downloaded files, but about the backed up NZB file!
- When I empty the ".nzb Backup Folder" entry in the folder settings, then the error message disappears and everything - except the NZB Backup - works.