4.5.2.0 ARmv7 on EDS14 - causing problems with NAS

[csimon 4]

I installed emby-server-synology-mono_4.5.2.0_armv7_legacy.spk on my EDS14. This is a fanless/diskless device. I have an SD card inserted for storage. I have no idea where DSM goes, Synology state that there is no internal storage, yet the system boots without the SD card. Emby *seems* to have caused problems and Sybology have stated that the folder Emby (Emby's data home it seems that it creates on isntallation) was created wrongly.  It's been put on /volume1, whereas it should have gopne to the SD card which is /volumeUSB1/usbshare1-1. Here is the output of df:

Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/root        1032088  766176    163512  83% /
none              250708       0    250708   0% /dev
/tmp              254888    1316    253572   1% /tmp
/run              254888    1452    253436   1% /run
/dev/shm          254888       4    254884   1% /dev/shm
/dev/sda3        2512656  851480   1558776  36% /volume1
/dev/sdq1       30676512 3619856  26954256  12% /volumeUSB1/usbshare1-1

/dev/sdq1 is the SD card. I have no idea what /dev/root or /dev/sda3 are, I'm trying to extract this info from Synology.

 

The symptoms I have were that Emby seemed to install correctly but whenever I tried make settings changes and saving them, it would hang. I then found out that I couldn't get into the Shared Folders app in DSM settings, it produces an error "The operation failed. Please log in to DSM again and retry.". I then uninstalled Emby and contacted Synology.  Here is a summary of the support case so far:

Synology: From information provided to us from our HQ team, they have noted that the Emby folder created on Volume1 appears to be causing this issue and may have been created in the wrong location. Can you confirm if this folder was created via the Control Panel menu for Shared Folders, or if this was created manually via SSH at some point? Can you also confirm if this folder is required or if this can be deleted?

 

Me: This folder would have been created last week when I installed the Emby server package from https://emby.tv/synology-server.html, I didn't create it manually myself.  It looks like it's the Emby home data folder. I know from having a desktop installation of Emby that it is possible to move this by manually copying it to a new location then altering the path to it in /etc/emby-server.conf, hopefully that would be the same on a Synology installation if it's in the wrong location. After installing he package it seemed to run OK but it was hanging when I tried to save any configuration changes. That's when I discovered this problem getting into shared folders ands also the problems with the hyper backup and DSM not saving settings. I uninstalled Emby. Yes, the folder can be deleted but I assume it would just appear again if I install the package again.  What is the problem with this folder, is it because it's not been created via Shared Folder that it's not been created "properly"?

 

Synology: The package itself isn't a supported package, so I am unsure what changes are made to the system, and the EDS14 isn't like other NAS devices we manufacture, in that it has no internal storage of its own for the volume, so as it relies on USB or SD card storage, it mounts differently than those which mount from internal hard drives. We recommend that the folder should be removed fully, however this may possibly work by moving it to /volumeUSB1/usbshare1-1 via SSH instead but cannot guarantee it.

 

Me: I have now removed /volume1/Emby completely via ssh, but I still can't get into Shared Folder in DSM, it produces the usual error. Can the team find out if there is anything else that is looking suspicious?  I can put out a case with Emby as well to see if they have any ideas.

 

Me:

Could you explain what exactly volume1 is and where it is? There must be internal storage in the EDS14 because it boots without the SD card in it. And I don't understand what filesystem exactly was full. You mentioned the system partition but as I've said this is < 40% full according to DSM.  The current output of df is:

Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/root        1032088  766176    163512  83% /
none              250708       0    250708   0% /dev
/tmp              254888    1316    253572   1% /tmp
/run              254888    1452    253436   1% /run
/dev/shm          254888       4    254884   1% /dev/shm
/dev/sda3        2512656  851480   1558776  36% /volume1
/dev/sdq1       30676512 3619856  26954256  12% /volumeUSB1/usbshare1-1
So where, physically, is /dev/root  - is it internal non-volatile storage, and how does it relate to /dev/sda3, is it an internal SD card?  If Emby is putting this directory in volume1, where exactly is that going, is it to the internal memory?

 

That was the latest, I'm waiting for areply. Who knows, the Emby installation might be a red herring, but I note that there have been other reports of problem with this release, and I don't know how to resolve this.

[Luke 37058]

Hi, so you've removed Emby Server completely at this point? I assume you've also tried rebooting the nas?

[csimon 4]

Yes, I uninstalled Emby and the NAS has been rebooted several times since I logged the case with Synology - they wanted me to eject and remove the SD card then reboot, then insert again and reboot...   I've just rebooted now again too.

Edited November 9, 2020 by csimon

[csimon 4]

Further to this, it seems that where Emby Server is creating its home directory by default on Synology devices, /volume1, is inappropriate for the EDS14.  It is a diskless device and volume1 is limited capacity internal storage for the operating system. It would be more appropriate to be put on any discovered SD card or USB storage attached to the device. The device is no longer available so I'm not sure how much effort Emby would put into fixing this problem, however similar devices are still available from Synology marketed as surveillance solutions: https://www.synology.com/en-uk/products/visual_station

Synology is suggesting creating the Emby shared folder in advance before installing the package.  This is because doing this manually via the Shared Folder utility in DSM allows the user to choose where to put it.  I am willing to experiment with this as I now have the means to fix it if it goes wrong again (see the conversation from Synology below). Does this sound a reasonable thing to do from your point of view? If I create a shared folder called Emby in advance, will the Emby Server installation find it and use it even if it's not on /volume1, and set the appropriate permissions on it etc?  Or the alternative solution if this doesn't work (see the final post in the conversation below) is to allow Emby Server to create the directory, then copy it to another location (as will work with the desktop installation by changing the path in /etc/emby-server.conf - where would the equivalent config file be found in a Synology installation?). I can then go the procedure to remove the incorrect folder.

 

 

Synology: From information provided to us from our HQ team, they have noted that the Emby folder created on Volume1 appears to be causing this issue and may have been created in the wrong location. Can you confirm if this folder was created via the Control Panel menu for Shared Folders, or if this was created manually via SSH at some point? Can you also confirm if this folder is required or if this can be deleted?
The package itself isn't a supported package, so I am unsure what changes are made to the system, and the EDS14 isn't like other NAS devices we manufacture, in that it has no internal storage of its own for the volume, so as it relies on USB or SD card storage, it mounts differently than those which mount from internal hard drives.
We recommend that the folder should be removed fully, however this may possibly work by moving it to /volumeUSB1/usbshare1-1 via SSH instead but cannot guarantee it.

Me: I have now removed /volume1/Emby completely via ssh, but I still can't get into Shared Folder in DSM, it produces the usual error. Can the team find out if there is anything else that is looking suspicious?  I can put out a case with Emby as well to see if they have any ideas.

Synology: I have received a response from our HQ team who have informed me that they have repaired the issue by removing the Emby folder. Please can you check this for me to confirm if this has now been resolved successfully.

Me: Hello - I removed the folder myself promptly when I received your last message. See update above. But this did not solve the problem. However, now that you've replied again I've had a look and I can now get into the Shared Folder settings.  Are you able to tell me exactly what in addition the HQ team did, so that if it happens again I can fix it myself? I have a query open with Emby, if indeed their package was the problem, so I may need to be installing it again to test.

Synology: I received a response from our HQ team who have provided the command for us to pass on and a set of recommended instructions should you try to reinstall Emby again.
They recommend to create a new Shared Folder first using Control Panel >> Shared Folder called Emby first and then reinstalling the package. If the package causes the same issue, this would be a design issue that Emby need to resolve specifically for the EDS14 environment. The command used to resolve the issue is provided below:
synosharee --del FALSE Emby
If the above command doesn't work, this may be due to a spelling error, as I believe the correct part should be synoshare without the second e.

Me: Oh, thank you, that is very helpful. I will go through this with Emby.
Just one more question - would you therefore say that for the EDS14, volume1 is the wrong place to create a package's data store because it is mounted on restricted capacity internal storage? And therefore the package should give the option and/or search for external storage instead such as an SD card or a USB drive? I think I understand from your reply that creating the folder beforehand would allow the user to choose where it is put.

Synology: Your understanding of the volume issue is correct, and that Emby is attempting to create the folder directly to Volume 1, where as the EDS14 does not use this location specifically. Whether you can customise the installation location of this is another question and one I am unable to answer, you would need to check this with Emby directly.
It would appear that Emby's package is designed specifically for other NAS models we sell which would use volume 1 specifically due to its use of internal drives. Creating the shared folder ahead of time may allow you to select this as an installation location, or to move/copy the contents to this location before removing the incorrect folder once more, though I am unsure if any links would be broken in this action.

Edited November 11, 2020 by csimon

[Luke 37058]

Hi, thanks for the info. So are you all set now?

[csimon 4]

5 minutes ago, Luke said:

Hi, thanks for the info. So are you all set now?

I was waiting for an indication from you as to whether the Emby Server installation is likely to find and use its home folder correctly if I create it in advance where I want it to be.  If the shared folder is simply called Emby, will the package find it regardless of what storage medium it's on and set permissions appropriately?

 

If not, I could let the package create the folder itself and I'll then move it, but where is the config file in which I'd need to update the path to it? In a Linux install, it is /etc/emby-server.conf but I don't know if this will be the same for a Sunology installation.

[Luke 37058]

Oh I'm not sure. You may just want to try it.

[csimon 4]

OK, well it has worked. I created the Emby folder in advance used the Shared Folder tool and put it onto the SD card. The Emby Server installation found it, changed the permsisions, and created the default hierarchy underneath it.

[Luke 37058]

Thanks for the feedback !