General NAS-Central Forums

Hi,
I've got the Medion Life P89636 aka NSA-212 with MetaRepository and the Application pyload installed.
Pyload runs fine, just the automatic extraction "ExtractArchive" doesn't work.
Here's the log from pyload:

I think there are two points,
- first 'Permission denied', but pyload is running with user 'admin' and the owner of the folder /i-data/md0/public is 'admin', group 'nobody', permissions '0777'. Pyload can create folders in the directory for the packages downloaded, but the packages couldn't be extracted from the plugin/addon 'ExtractArchive' in the same folder?!?

- second, as already described by Mijzelf here: http://zyxel.nas-central.org/wiki/Using_ZyXEL_packages_(NSA-212) the NSA-212 needs another version of '/usr/lib/libstdc++.so.6' for some packages.
Are they available for NSA-212?
If no, I have no clue how to fix this, a quick search brings me here:
https://rpmfind.net/linux/rpm2html/search.php?query=libstdc%2B%2B.so.6. I would pick an 'arm' package, but which exactly? And how to proceed?

If you need some more information, just give me a note.


Before installing pyload via MetaRepository I was using pyload via optware via ffp (fonz fun plug), that was running good.
Maybe it's some help, I followed these instructions (in German - but an online-translator might be useful ):
1. HDD-Installation of ffp (fonz fun plug): https://wolf-u.li/4523/hdd-installation-des-fun_plug-auf-nas-geraeten/
2. Installation of additional packages: https://wolf-u.li/4531/installation-zusaetzlicher-pakete-auf-dem-fonz-fun_plug-0-7/
3. Installation of optware: https://wolf-u.li/3869/installation-von-optware-auf-dem-d-link-dns-320-dns-325-dns-343-und-conceptronic-ch3mnas/
4. Installation of pyload: https://wolf-u.li/3921/installation-von-pyload-unter-optware-auf-dem-nas/

With this configuration it's downloading and auto-extracting, but you have to set the parameter in 'Extract Archive' for 'Move to trash instead delete' (from ON to OFF, because NSA-212 isn't moving things to trash) again after every restart of the NSA-212.
Issue is known: https://github.com/pyload/pyload/issues/1122 merged with https://github.com/pyload/pyload/issues/1157.
That's a little bit annoying and that's why I gave the MetaRepository a try.


Best regards,
Pollux

You can use the libstdc++ extracted from NSA310 rootfs, as provided here. But of course there is no easy universal way to add it to your box, else I would have provided it with MR.

Normally a library file is searched for in /lib and /usr/lib, and maybe some other places dependent on the way the executable and /lib/ld-linux.so are build. As /lib is volatile, and /usr/lib is read-only, these directories are not suitable for installing extra libs needed by installable packages. For that reason they are installed in /usr/local/zy-pkgs/lib, and to tell /lib/ld-linux.so where to find them, an environment variable LD_LIBRARY_PATH=/usr/local/zy-pkgs/lib/ is set.
When this environment variable is set, ld-linux.so first searches the directory(ies) specified here, and then the default paths. So the naive way to install the libstdc++ libraries is to put them in /usr/local/zy-pkgs/lib/, as they will be used rather than the versions in /usr/lib/.

However

The firmware has set that variable globally, which means that the firmware binaries using that library also get the NSA310 ones. And unfortunately the incompatibility is 2 ways. So the naive solution will break other parts of the firmware.

If unrar is the only binary in pyload which needs libstdc++.so, you can solve the problem with a wrapper script. Locate unrar (probably in /usr/local/zy-pkgs/bin) and rename it to unrar.bin.
Then create an (executable) shell script unrar instead, containing:This way unrar gets it's private LD_LIBRARY_PATH, and other binaries are not affected.

If other parts of pyload also need this library, you'll have to edit the pyload startscript, to provide a private LD_LIBRARY_PATH to the daemon, on startup.

Hi Mijzelf,
Thank you very much for your very quick reply.

Here's what I did: (I'm describing it as detailed as possible, maybe it's sounding a little bit like a instruction for a DAU - just to exclude EIFOK )
1. Downloaded file 'libstdc++.tar.gz' with Windows and extracted it with WinRAR to temporary folder, moved the extracted files with WinSCP to 'i-data/md0/admin/libstdc++/', gave the folder 'i-data/md0/admin/libstdc++/' the permission '0755' and the files in it also permission '0755'
2. In '/usr/local/zy-pkgs/bin': renamed 'unrar' to 'unrar.bin'
3. In '/usr/local/zy-pkgs/bin': created script 'unrar' containing:

4. In '/usr/local/zy-pkgs/bin': Gave 'unrar' Permision '0755'
5. Restarted the NSA-212 via SSH with 'reboot'

Pyload is still giving this error in the log:


The erorr still states the path is '/usr/lib/'?!? Did I something wrong?
Is Pyload maybe using some 'daemonised' unrar from another source?!?


By the way, is it normal to have in the directory '/usr/local/zy-pkgs/bin' 'unrar' and 'unrar-5.4.5'? Is the one the standard and the other from the MR?


I also renamed 'unrar-5.4.5' to 'unrar.bin' and tried, but the same error occurs in the log. It seems as it doesn't take the private LD_LIBRARY_PATH. Where's the pyload startscript located? Should I run pyload with this private LD_LIBRARY_PATH?


Best regards,
Pollux

You installed RandomTools, which also provides an unrar (It seems that the unrar provided with (the previous version of?) nzbget isn't suitable to extract recent rar files. So I provided the latest.).
The startscript of RandomTools generates a symlink /bin/unrar which points to unrar-5.4.5. If /bin is first in the search path, this unrar will be used.

If you created an unrar-5.4.5.bin and a unrar-5.4.5 script, this should also work, of course.

Have you tried to run unrar manually? '/usr/local/zy-pkgs/bin/unrar' should show it's manual. (And of course also just 'unrar', invoking the RT version.)

If you have RT, you also have ldd. should show where it finds it's libraries.

In /usr/locals/zy=pkgs/etc/init.d/patched/. Normally the startscripts are in /usr/locals/zy=pkgs/etc/init.d/, but because the Zyxel packages handle webinterface urls differently from the Medion one's, the MR startscript is put in between, to do some translation.

Yes, I've installed MetaRepository (MR), MidnightCommander, MuninLite, RandomTools (RT), SMART, Tweaks, ffp and pyload.
If I'm starting the '/usr/local/zy-pkgs/bin/unrar' it shows UNRAR 5.40:
But if I'm just using 'unrar' I got the same error as in the pyload log.
If I'm using '/bin/unrar' I'm getting the same error: The check of the link '/bin/unrar' shows to 'unrar-5.4.5'. Is 'unrar-5.4.5' broken?


That's the output from ldd:
How should I proceed? Deinstall RT and reinstall it? What do you think?

I added the full path for unrar.bin (copied 'unrar-5.4.5') to the wrapper-script:
Then it's working, I'm getting this by entering 'unrar':

And if I change the pointing to the original 'unrar' (which I renamed to 'unrar.bck'):
It's also working and giving UNRAR 4.00:

No, it just has the same problem as the stock unrar.
So your problem is solved now?

After a short test with a .txt in a .rar it seems to download an extract. The .txt is readable.
Yes, now unrar is working without error. Jippie!


But in the pyload log it still states a "permission denied" error from ExtractArchive.
It's extracting to the same folder in which the downloaded parts are saved. Do you have any clue why the error 'Permission denied' occurs?

No. Maybe add some logging:
Now you will know how exactly unrar is invoked, as which user, and maybe that will make it clear.

Hi Mijzelf,

I've added the logging to the scripts and downloaded my '000test.txt' paket in '000test.rar'. Here's the log:What I can read out of this is, unrar is executed as user 'admin'.
Folder public has the permission '0777', group 'nobody [99]', owner 'admin [501]' and the pyload/ExtractArchive created folder '000test' has the same ones.
I think I can live with this error. Pyload is extracting and the extracted files are ok.
Thank you very much!

The only thing of which I have to be aware is an update of 'unrar' in the RandomTools from the MetaRepository, or?

Best regards,
Pollux

Oh, did the extraction succeed? In that case the 'permission denied' can have a totally other source. For instance an attempt to move the rar file to a recyclebin, which doesn't exist.

What do you mean?

This option is set to 'off' for Extract Archive. Here are the parameters of the plugin ExtractArchive in pyload:
Do I have to make the running script / program of ExtractArchive (I think it's named 'ExtractArchive.py') writeable?!? So it could be overwritten?!?


I've renamed the 'unrar-5.4.5' to 'unrar-5.4.5.bin' and I've the wrapper script named 'unrar-5.4.5' in the directory '/usr/local/zy-pkgs/bin/'. I think this is the directory in which the RandomTools are saved.
If there's an update of the RandomTools to e.g. 'unrar-8.8.8' then
- the old unrar-5.4.5 will be deleted, which is the wrapper script and
- the new link for 'unrar' will point from '/bin/' to '/usr/local/zy-pkgs/bin/unrar-8.8.8'. And this 'unrar-8.8.8' wouldn't work because it has no wrapper script.

Hopefully this isn't written too crazy.

No. You are right. After updating (or re-installing) RT you'll have to re-apply the patch.