Posts by gderf

SnapRAID has no effect on filesystem or system performance unless an actual SnapRAID job is running on otherwise inadequate hardware.

You can rule out unionfs as a source of the problem if you temporarily create a new library in Plex that doesn't use the union as a media source. Just add individual drives instead. If the buffering remains, look somewhere else.

I have 40TB in a mergerfs union spanning eight drives and Plex has no problems with it. The CPU is a four core Intel Atom 2550, rather meager by today's standards.

Edit:

I just now saw that you are on Emby, not Plex. But that doesn't alter my suggestion about using drives instead of the union as a test.

Quote from coffinbearer

You can also disable the "Allow media deletion" option in your Plex Server Library Settings

Since only the Plex Admin user can delete media, disabling this setting is pointless if others have admin access - they can just reenable it at will. The correct way to solve this problem is to create unprivileged Plex users who have no access at all to the Plex settings section and no ability to delete anything.

Yes, that will work. But if you ever do want to be able to delete media from within Plex, such as managing duplicate content, you won't be able to.

Giving anyone other than yourself access to Plex using the Admin credentials is a bad idea. The solution you arrived at doesn't solve that problem. Those users might not be able to delete media from your filesystem, but they will be able to delete libraries from Plex and make other changes that you will surely not appreciate.

That error indicates that you are using the wrong docker image. You should try this one:

linuxserver/plex:bionic

If the Plex Admin user does not need the capability to delete media from within the Plex apps, then disable this feature.

Don't give the Plex Admin credentials to other users. Create new users who will not have this feature available to them if it is enabled.

Quote from peglegtv

what can I do for the permissions issues? sorry, I'm not as familiar with Linux as I am windows so I'm not sure where this leaves me

You are going to have to learn about these things.

https://www.linux.com/training…g-linux-file-permissions/

It would seem to me that if upon every restart all the containers start from scratch it's because their data is not being stored into a volume outside the containers. This could be because such volumes were never configured or they are in a location the containers can't write to.

Permissions are one of the most frequently misconfigured things when getting started with docker.

You have to be able to check these.

apt-tool will not find emby-server because it isn't in any of the stock OMV repos.

Quote from Omvben

Is there somewhere i can remove this entry?

Look in /etc/apt/sources.list.d/omvextras.list

I have no idea how many spare sectors are available. I started looking into replacing a disk here when the reallocated sectors reached 8. I got a replacement disk in three days and by that time the count rose to more than 780. I was able to replace the disk without losing any data.

The longer you wait to replace the disk, the higher likelihood that it might completely fail.

Look in Storage | S.M.A.R.T. | Information | Extended Information for that device.

If you see non-zero Raw Values for ID#s 5, 197, and 198 I would suggest planning on replacing the disk ASAP.

Quote from peglegtv

should I hit abort on the error?

Yes.

Even disabling media deletion within Plex will not 100% protect user media files from deletion by Plex if they are improperly placed in the filesystem.

A recent post in the Plex forum detailed what happened when a user placed all his media files in directories below /var/lib/plexmediaserver

Plex did a routine recursive chown plex:plex on that directory and apparently decided that those media files didn't belong there and since it had now owned them and had internal to the program permission to delete them all.............poof.

See: https://forums.plex.tv/t/plex-media-deleted-media-without-authorization/680577

You may be running into a possible unintended consequence of the system switching from mounting drives by label to mounting by UUID.

Post your /etc/fstab file

Post a listing of /srv:

ls -al /srv

I would recursively set /srv/dev-disk-by-label-8TB1/Appdata/docker to 0755

Try rebooting the machine.

One way unexpected file errors can appear during a SnapRAID sync is if new files are added into the array while the sync is running.

Quote from peglegtv

they are stored on one of my HDD

srv/dev-disk-by-label-8TB1/Appdata

Do the containers have permission to write there?

mi-hol If you are going to quote from a post of mine, please don't alter the content of the quote.

If I can get an LSI SAS HBA card that is the same price per port as a no name SATA card, why would I choose the no name card?