MyCloudEX2Ultra and EMBY

[sa2000 856]

Do you know what the .bin filenames were before - when it worked ?

The log from August suggests it was "emby-server-western_digital-mono-os5-western_digital_{version}_arm.bin" which is different from the current package.

 

[allxsan 5]

22 minutes ago, sa2000 said:

I can see a difference in package names between August 1 and now. I will discuss with the development team

what is in the new /tmp/embyserver.log

 

 

mv: can't rename '/mnt/HD/HD_a2/Nas_Prog/_install/embyserver': Directory not empty
2026-10-09 13:20:17 APKG_DEBUG: /mnt/HD/HD_a2/Nas_Prog/_install/embyserver/install.sh /mnt/HD/HD_a2/Nas_Prog/_install/embyserver /mnt/HD/HD_a2/Nas_Prog
mv: can't rename '/mnt/HD/HD_a2/Nas_Prog/_install/embyserver': Directory not empty

[allxsan 5]

14 minutes ago, sa2000 said:

Do you know what the .bin filenames were before - when it worked ?

The log from August suggests it was "emby-server-western_digital-mono-os5-western_digital_{version}_arm.bin" which is different from the current package.

 

I've tried again from the start ->

checked and removed files if present (but only "apkg.xml" was present, the /Nas_Prog/_install/ and the other folders was already empty), this time I also removed  the embyserver.log from /tmp

tried to install again the latest beta, now the completely new (surprisingly because I had done the same thing twice before but without removing the .log file from /tmp..) embyserver.log  contains:

2026-10-09 14:18:07 APKG_DEBUG: /mnt/HD/HD_a2/Nas_Prog/embyserver/init.sh /mnt/HD/HD_a2/Nas_Prog/embyserver
2026-10-09 14:18:07 APKG_DEBUG: /mnt/HD/HD_a2/Nas_Prog/embyserver/start.sh /mnt/HD/HD_a2/Nas_Prog/embyserver

not only ! The EMBY icon is reappeared in the WD webif ! 

This time the installation took several seconds, but only a little while ago it had been very quick, because it had always taken a long time even when it didn't work. I've been trying and trying since August 1st, I've even removed and reinstalled dozens and dozens of times from the WD interface. It got to the end, proceeding slowly as always... in the end it said "all ok", but no icon and the Emby setup page obviously didn't open! So now I don't understand, I could say that the problem was also due to the .xml file in /embyserver/... but even before I removed it, the installation went through very quickly and it didn't work! So this problem should be analyzed to prevent it from recurring.

Obviously the /mnt/HD/HD_a2/Nas_Prog/embyserver/start.sh /mnt/HD/HD_a2/Nas_Prog/embyserver now contain 10 files and 7 folders

So what happened on August 1, 2026, after installing the new beta?

[sa2000 856]

so it is working now?

I would not expect deleting /tmp/embyservr.log to have an impact - i will pass on the information

[allxsan 5]

1 hour ago, sa2000 said:

so it is working now?

I would not expect deleting /tmp/embyservr.log to have an impact - i will pass on the information

 

It should be noted that after uninstalling EMBY using WD's webIF, the previous configuration remained almost intact (sftp://sshd@192.168.1.125/mnt/HD/HD_a2/emby)

also almost all the metadata are still here, so seem that only the main banners/cover has been lost

 

[sa2000 856]

11 minutes ago, allxsan said:

only the main banners/cover has been lost

May be that is related to the Cover Art plugin that you have installed

I do see some errors in the log from 1st August relating to cover art

[allxsan 5]

But it remains to be seen why this happened immediately after installing/upgrading to another beta version and why the installation from that moment on no longer worked (two months ago I asked in the beta area exactly this question: what could be left of the previous configuration that prevents the installation even after removing the previous installation? But nobody answered me).

Unfortunately, I don't know the version or the exact release date, but it definitely happened at the end of July 2026. It's still very difficult to reconstruct exactly, because I have absolutely no memory of when I last used it before installing the latest beta. I could have used the Emby server a week or twenty days earlier, the only certainty is that I definitely intended to use it, because I always do this: if I've inserted new media and want to watch it, I always check on GitHub and if there's a new version, I update before using it (perhaps you can use the logs to figure out more).

Edited October 9 by allxsan

[sa2000 856]

what does the /tmp/embyserver.log look like now?

 

[sa2000 856]

38 minutes ago, allxsan said:

But it remains to be seen why this happened immediately after installing/upgrading to another beta version and why the installation from that moment on no longer worked (two months ago I asked in the beta area exactly this question: what could be left of the previous configuration that prevents the installation even after removing the previous installation? But nobody answered me).

The fact that today at 13:20:17 and later at 14:18:07 the /tmp/embyserver.log shows it went straight into logging install.sh rather than the normal pre-cursor scripts to clear out old files, indicates that the WD NAS though Emby Server was not already installed - but unfortunately for some reason there was a residual file in folder /mnt/HD/HD_a2/Nas_Prog/embyserver at 13:20:17 giving a failure and at 14:18:07 it was ok and no residual file

So the OS thought it was a new installation and went ahead as if a fresh install and failed on the "mv" command as the target directory was not empty

Between 13:20:17 and 14:18:07 you must have removed the directory  /mnt/HD/HD_a2/Nas_Prog/embyserver and allowed the next install attempt to work

The app data area is separate and is left in tact after the uninstall and it is here /mnt/HD/HD_a2/emby

The coverart issue could be a plugin compatibility issue with recent betas

 

 

Edited October 9 by sa2000

[allxsan 5]

36 minutes ago, sa2000 said:

what does the /tmp/embyserver.log look like now?

 

 

2026-10-09 14:18:07 APKG_DEBUG: /mnt/HD/HD_a2/Nas_Prog/embyserver/init.sh /mnt/HD/HD_a2/Nas_Prog/embyserver
2026-10-09 14:18:07 APKG_DEBUG: /mnt/HD/HD_a2/Nas_Prog/embyserver/start.sh /mnt/HD/HD_a2/Nas_Prog/embyserver
2026-10-09 18:01:27 APKG_DEBUG: /mnt/HD/HD_a2/Nas_Prog/embyserver/stop.sh /mnt/HD/HD_a2/Nas_Prog/embyserver
2026-10-09 18:01:33 APKG_DEBUG: /mnt/HD/HD_a2/Nas_Prog/embyserver/start.sh /mnt/HD/HD_a2/Nas_Prog/embyserver
2026-10-09 18:10:02 APKG_DEBUG: /mnt/HD/HD_a2/Nas_Prog/embyserver/stop.sh /mnt/HD/HD_a2/Nas_Prog/embyserver
2026-10-09 18:10:12 APKG_DEBUG: /mnt/HD/HD_a2/Nas_Prog/embyserver/start.sh /mnt/HD/HD_a2/Nas_Prog/embyserver

 

 

Edited October 9 by sa2000

[sa2000 856]

I see this in the old 1 august log

2026-08-01 17:42:28.366 Info App: Starting entry point CoverArt.ServerEntryPoint
2026-08-01 17:42:28.379 Info CoverArt: CoverArt plugin not supported on this system.
2026-08-01 17:42:28.470 Info App: Entry point completed: CoverArt.ServerEntryPoint. Duration: 0.10422 seconds

Suggest you check the new logs and refer to the developer of the plugin

[allxsan 5]

8 minutes ago, sa2000 said:

The fact that today at 13:20:17 and later at 14:18:07 the /tmp/embyserver.log shows it went straight into logging install.sh rather than the normal pre-cursor scripts to clear out old files, indicates that the WD NAS though Emby Server was not already installed - but unfortunately for some reason there was a residual file in folder /mnt/HD/HD_a2/Nas_Prog/embyserver at 13:20:17 giving a failure and at 14:18:07 it was ok and no residual file

So the OS thought it was a new installation and went ahead as if a fresh install and failed on the "mv" command as the target directory was not empty

Between 13:20:17 and 14:18:07 you must have removed the directory  /mnt/HD/HD_a2/Nas_Prog/embyserver and allowed the next install attempt to work

The app data area is separate and is left in tact after the uninstall and it is here /mnt/HD/HD_a2/emby

The coverart issue could be a plugin compatibility issue with recent betas

 

 

haven't removed the folder /mnt/HD/HD_a2/Nas_Prog/embyserver

I just deleted apkg.xml (the only file that was always there) for the second or third time. But for some reason I can't explain, the last time the installation worked and the folder filled up with folders and files. 

Perhaps we need to understand if and how the "apkg.xml" file has affected and is affecting.

We need to understand why it stopped working after installing a beta from late July 2026.

We need to understand whether the "apkg.xml" file should have been deleted when uninstalling from WD webIF or not.

Now it's rebuilding the metadata, deleting all the previous ones. When it's finished, I'll remove EMBY using WD's webIF... so I can check what's left in the "/mnt/HD/HD_a2/Nas_Prog/embyserver" folder.

It should leave the configuration intact and therefore work simply by reinstalling the beta from WD's webIF.

But is this normal? That the configuration remains intact even if I want to uninstall? Personally, I think that, at least in theory, this isn't exactly correct. Why? Because, for example, how is an unprepared user supposed to completely remove and reinstall from scratch? Even users who had previously used the Emby server remain configured. So without SSH, it becomes impossible to actually remove anything.

 

[allxsan 5]

I'm about to complete the metadata. As soon as it's finished, I'll send you the new contents of "/mnt/HD/HD_a2/emby/logs"
so you can look at it if you'd like. Thanks.

[sa2000 856]

2 hours ago, allxsan said:

But is this normal? That the configuration remains intact even if I want to uninstall?

I think it is good that it remains intact and would probably satisfy most users preference - but you are right that there is a need for an option to completely wipe out an installation. 

 

PS: The reason we do not have much history in the `/tmp/embyserver.log` file is because `/tmp` gets reset and cleared down on every reboot of the NAS 

[sa2000 856]

Linking to follow-up forum topic https://emby.media/community/topic/150122-mycloudex2ultra-and-emby/

[Luke 43374]

On 10/9/2026 at 12:58 PM, allxsan said:

I'm about to complete the metadata. As soon as it's finished, I'll send you the new contents of "/mnt/HD/HD_a2/emby/logs"
so you can look at it if you'd like. Thanks.

Hi, how has this gone?

[allxsan 5]

On 10/11/2026 at 9:11 PM, Luke said:

Hi, how has this gone?

at the moment it's still working.

But why had I tried twice to manually remove via ssh file apkg.xml (otherwise it would never work again except after reinstalling the WDMyCludUltraEx from scratch) which in my case is always the only file left in the folder "/mnt/HD/HD_a2/Nas_Prog/embyserver/start.sh /mnt/HD/HD_a2/Nas_Prog/embyserver" ? Why did it not work twice after manually removing via SSH and uninstalling Emby via WD interface but the third time it simply worked repeating exactly the same things? 

Edited Thursday at 10:27 AM by allxsan

[sa2000 856]

We don't know why the issue arose with an apkg.xml file being left and may be the same happened more than once

This is overview from a google search

We are going to make improvement to the install script to allow for this arising - but of couse why it arises in the first place is unknown