Wrong permissions after unrar on some NZBs

[Anuskuss]

I use unrar -ai and everything worked correctly until I found this one particular NZB:

1. Downloading with DirectUnpack

$ stat -c '%A %u %n' * _unpack/* | grep -v 'r0[1-9]\|r[1-6][0-9]'
-rw-r--r-- 1000 149539-0.mkv
-rw-r--r-- 1000 149539-1.jpg
-rw-r--r-- 1000 149539-2.nfo
-rw-r--r-- 1000 149539-2.r00
-rw-r--r-- 1000 149539-2.rar
drwxr-xr-x 1000 _unpack
-rw-r--r-- 1000 _unpack/censored.mkv

2. Download (and unrar) finished, PAR2 files come in

$ stat -c '%A %u %n' * _unpack/* | grep -v 'r0[1-9]\|r[1-6][0-9]'
-rw-r--r-- 1000 149539-0.mkv
-rw-r--r-- 1000 149539-0.par2
-rw-r--r-- 1000 149539-1.jpg
-rw-r--r-- 1000 149539-1.par2
-rw-r--r-- 1000 149539-2.nfo
-rw-r--r-- 1000 149539-2.par2
-rw-r--r-- 1000 149539-2.r00
-rw-r--r-- 1000 149539-2.rar
-rw-r--r-- 1000 149539-2.sfv
drwxr-xr-x 1000 _unpack
-rw-r--r-- 1000 _unpack/censored.mkv

3. Files get their canonical name, unpacking restarts
   [INFO] Found archive files not processed by direct unpack, unpacking all files again

$ stat -c "%A %u %n" * _unpack/* | grep -v 'r0[1-9]\|r[1-6][0-9]'
-rw-r--r-- 1000 149539-0.par2
-rw-r--r-- 1000 149539-1.par2
-rw-r--r-- 1000 149539-2.par2
-rw-r--r-- 1000 censored.nfo
-rw-r--r-- 1000 censored-proof.jpg
-rw-r--r-- 1000 censored.r00
-rw-r--r-- 1000 censored.rar
-rw-r--r-- 1000 censored-sample.mkv
-rw-r--r-- 1000 censored.sfv
drwxr-xr-x 1000 _unpack
-rwx------ 1000 _unpack/censored.mkv

4. Unpacking finished

$ stat -c "%A %u %n" * | grep -v 'r0[1-9]\|r[1-6][0-9]'
-rwx------ 1000 censored.mkv
-rw-r--r-- 1000 censored.nfo
-rw-r--r-- 1000 censored-proof.jpg
-rw-r--r-- 1000 censored-sample.mkv
-rw-r--r-- 1000 censored.sfv

Notice how in step 3 the file permissions get changed from the normal 644 (rw-r--r--) to 700 (rwx------) which leads to problems further down the line. I tried to combat this behaviour with ACLs but that only works for newly created files so it looks like it's being set deliberately. Those permissions do not come from the RAR file (-ai should ignore them anyway).

The file in question can be found on DS (4156a6cc26932bfe4faf54beb77875f7e8841e22). I can share the NZB if you don't have access to DS.

[parnic]

In my experience, this is caused by file permissions inside the archive having different permissions already set. Have you tried the suggestion on the Unpack page of the NZBget settings for "UnrarCmd"? I changed mine to unrar x -ai and this problem went away.

Full path to unrar executable.

Example: /usr/bin/unrar.

The option can also contain extra switches to pass to unrar. To the here defined command line NZBGet adds the following switches:
x -y -p- -o+ *.rar ./_unpack/
Switch "x" is added only if neither "x" nor "e" were defined in the option (this allows you to use switch "e" instead of "x"). switch "-o+" is added only if neither "-o+" nor "-o-" were defined in the command line. All other parameters are always added. Parameter "-p-" is replaced with "-ppassword" if a password is set for nzb-file.

Examples:

1. ignore file attributes (permissions):
   /usr/bin/unrar x -ai;
2. decrease priority of unrar-process:
   nice -n 19 unrar.

For other useful switches refer to unrar documentation.

[Anuskuss]

I use unrar -ai and everything worked correctly until I found this one particular NZB:

[parnic]

I use unrar -ai and everything worked correctly until I found this one particular NZB:

My bad.

[Anuskuss]

Not that it really matters but this whole thing could've been avoided by just using DirectRename (it's faster, too!).