SABnzbd 4.2.2 creates files with incorrect permissions (600 instead of 666) when using 7za to unpack #6009
Comments
|
@Safihre, could this maybe be an upstream issue? @JustAndreww, can you indicate if this unpack function had the correct permissions in previous versions? It would be helpful in understanding if there was a specific version where it did work correctly. |
|
I would love to, but I have only recently installed Sabnzbd and never used it before, so I can't really compare. |
JustAndreww
changed the title
|
Is is a bug in p7zip. Unfortunately the version used by SynoCommunity is 16.02, where the 16 stands for 2016. |
|
Just used pre-compiled x86_64 linux binary from 7zip website ( Maybe some additional arguments needs to be passed to Also I think this issue would be quite easy to fix with post-unpack-script that will simply do |
|
SABnzbd can do that (Config > Folders (enable Advanced Settings) > Permissions), however, this breaks Synology persmission system so that's why it's disabled by default. If you can find which command line argument it is, I can always add it. |
|
Thank you for the hint! I will stick to that solution at the moment. 755 permissions looks OK to my use-case and as a temporary workaround. |
I can have a look at that in the coming days if it helps. |
|
Unfortunately it seems the new one also doesn't have any special flags (like unrar) to not set permissions.. |
|
As far as I know does 7zip not set any permission at all. If you need other permissions then you should make sure the location of the file is on a "shared folder" and the "system internal user" that sabnzbd is using must have read/write access there. And the user from your Windows client should also have permissions there to be able to access them.. |
|
@BenjV this is not true for 7zip. |
|
You can only test this on a Synology and with SabNzbd, any other test will be useless. Within a zip there is no permission information so 7zip cannot set any meaninfull permissions. And on a Synology that will only result in a workable way if you put that files on a location where another user can access them as I explained. |
|
@BenjV seriously, did you test it on your Synology? Because it does not work. |
|
@Safihre, I've done a few tests with the test nzb you provided. It normally downloads and extracts to If I download only I get the folder with a file A manual extraction looks like this: As you can see the permissions are defaulting to the running user only. I can however override this forcibly like this: It's not the best method but I couldn't see any permissions setting options for |
|
Permissions would then follow the umask directive from the user shell environment... |
|
So how would we choose the umask? |
|
In my opinion, if |
|
I thought so indeed.. Too bad 7zip doesn't have a parameter for it. Unrar does have a specific parameter to not set permissions (which we use). |
|
@Safihre, based on my understanding, it seems that this issue is not exclusive to Synology but rather could potentially affect any Linux implementation. Would you concur with this assessment? If so, it implies that the problem lies upstream but is not inherently a flaw within SABnzbd itself. It is due to a dependency constraint preventing a straightforward resolution, though there exists a workaround to mitigate the issue. Would you agree with this interpretation? |
|
Agreed. Not Synology specific. The complicating factor here is that if Permissions is set in SABnzbd Config Folders, it uses chmod and breaks the Synology permissions. But that's all we can do about it. |
|
From Wikipedia on 7z:
|
Mode is Now what about umask you ask... well umask runs in octal mode where you mask certain bits. For instance, a normal So using this principle:
and so on... Now, going back to |
|
You are all forgetting that Synology has implemented its own permission system based on the ACL's and not on the default Linux permissions. |
|
We are very well aware. |
|
I already explained it. The target where 7zip will place the files must be on a "shared folder" and that shared folder must be granted read/write privs for the "system internal user" which is running 7zip so in the case 7zip is spawned by SabNzbd the system intenal user of SabNzbd. And if you need access to those files by a user from the network, that user must be granted privs also. |
|
@BenjV, isn't that the same advice we already provide in the Permission Management wiki? If so, then there is nothing to address in the package or the upstream software. If not, then I am unclear on how that addresses the issue raised by the user. |
|
And if i may add, i played with 7zip to replace p7zip and wow ... Cross-compiling this isn't easy. I wasn't able to get far, even following arch linux recipe. |
hey @th0ma7, interesting findings. When you mean the startup script do you mean a modification to this line? spksrc/spk/sabnzbd/src/service-setup.sh Line 14 in e5836de |
|
Yes. But testing is needed considering both acl and how p7zip works. |
|
Considering this is the first report of this problem even though the problem has existed for years, should we really be adding that? |
|
Sorry, I wasn't advocating a proposed change, I stand by my original recommendation that this is well handled by the existing post-processing. I was just clarifying in case I wanted to do some private testing (no commitment to so do). |
I could say the same of you. And as @mreid-tt said, this is already explained in the wiki. If 7zip actualy sets the permission itself and by that messes-up the DSM permissions it can only be fixed upstreams, but I very much doubt that this is the case. |
What more proof do you need that 7zip sets permissions? |
|
Did you read the results of the test @mreid-tt did?????
This is proof that 7zip does not set the permissions on a zip file just like a rar file. What maybe is happening is that the zip file contatins ntfs permissions and 7zip support this. The process is:
|
|
Folks, let's dial it back a bit. Both of you raise valid points, but I propose that instead of further speculation, we invest our time in conducting actual tests to validate our hypotheses. Here are a few points to consider: @Safihre, as far as I can tell, 7zip does not set permissions for the archive in question. If this were the case the @BenjV, the zip file in question does not contain any relevant NTFS permissions given the attributes that are set in the file were (as stated above): Based on my observations, the attributes "archived and compressed" do not have any bearing on user permissions. Additionally, I tested using the I am skeptical that permissions are solely inherited from the user and location. For instance, the parent folder of the zip file, created by 7zip, does not share the same permissions as its containing folder, as illustrated previously. My suspicion is that inheritance might be overridden, resulting in the absence of ACL+ attributes. Before delving deeper into this discussion, I urge you to replicate the test I conducted and examine the folder permissions along with the ACL+ attributes. Further discourse without concrete evidence would be speculative. |
|
It probably only happens when the zip file contains ntfs permissions so the zip has to be created on a Windows system also with the -sni argument. When I find time (tomorrow maybe) I will perform some test. |
|
Tested with a file containing ntfs permissions but on the Nas 7zip could not extract such a file, so that is not the problem. |
|
hey @Safihre, a bit off topic but I was testing a recent download of an NZB file which contained a RAR archive and I was surprised to find the extracted files with the following permissions: There were no ACLs set by default as this command shows: Digging further I realised that while it was a RAR archive, on extraction it had another layer which was a ZIP file as shown below: As such, when the files were extracted with The ACL details are the same: I believe this is a reasonable workaround which doesn't seem to cause any issues on Synology as far as I can see. |
Is this a new Bug?
Package Name
SABnzbd
Package Version
4.2.2
Device Model
DS920+
Device Architecture
x86_64
Firmware Version
DSM 7.2.1-69057 Update 4
What happened?
When unpacking 7Z downloads resulted file will have 600 permissions instead of 666. So I can't open it in Windows in mounted network drive. Doesn't happen with RAR downloads.
Permissions are set as follows for the downloading folder:
Reproduction steps
Download some NZB with 7z inside. Unpack will finish OK, resulted file cannot be opened in the mounted Windows drive folder due to lack of access rights.
No errors or whatsoever in logs, everything seems to be fine.
Install Log
ls -l output
Sabnzbd log with 7za arguments call
Log file
The text was updated successfully, but these errors were encountered: