trurl

/boot is your flash drive and they aren't stored anywhere else except for the backup you make of your flash drive.

Do you have a backup of your flash drive? You should.

Looks like he was doing a search on MKV so I tried it and I can duplicate the issue.

You don't specifically mention Unraid or the docker this thread is about. Since this is your first post here I have to wonder if you didn't just come here to ask some question that has nothing at all to do with our forum. Are you using this docker? Are you interested in Unraid?

Answered in the first posts (and several other times) in the NVidia thread.

Probably you should have just posted in General Support. Here is a link to the Report Guidelines: https://forums.unraid.net/bug-reports/stable-releases/report-guidelines-r68/

No

Another possibility that I have seen in other situations, such as rsync, is that the application will create all the folders in advance, then copy the files to those already created folders. Since the disk has plenty of space for the empty folders, that is where they wind up.

The correct answer depends on what your other plex docker had. The Container Path is where the application will see the files. The existing metadata was created by your other plex docker and so that metadata expects to find the files wherever that other plex saw them.

I am beginning to think this would be a good addition, but for reasons not mentioned on this thread. It would allow us to prevent 2 surprising results when managing files in Krusader, Midnight Commander, command line, etc. If you mix user shares and disks when moving/copying files, you can actually lose data, because Linux doesn't realize that the source path and the destination path might actually be the same file, and so tries to overwrite what it is trying to read. This is often referred to as the User Share Copy Bug. The Linux command for Move and Rename are the same, mv. So when you try to move files from one user share to another, Linux will often simply rename the files so they have a different path on the same disk, in violation of any user share settings such as included disks. The workaround for this is to copy from source to destination, so that new files get created following the user share settings, then deleting from the source. If we had our own file manager, number 1 could be rejected, and number 2 could implement the mentioned workaround. Of course, this would be a very large undertaking. Maybe some existing source code could be customized.

What was that other docker anyway?

The blue text at the bottom of your latest screenshot, click on it.

The same way you had it in that other docker that created your metadata.

You also seem to have 2 different mappings for config. Do you understand docker volume mapping?

Not sure what you mean here since there isn't any way it would remove itself whether it crashed or not. The error you are getting makes me think that your precious metadata isn't correct. In addition to the artwork, for example, the metadata tells plex where to find the files. And it isn't finding them. According to the mappings in your screenshot, this docker will see files from the host path /mnt/user/Media at the container path /media. Unless your previous docker and its metadata had that exact same mapping then this plex will not find the files.

Linux sees all user shares mounted at /mnt/user. Move and Rename are the same command in Linux, mv. So if you move files between user shares, it will rename them with a different path on the same disk they are on, instead of copying them to another destination disk and then deleting them from the source. You will have to do the copy then delete yourself instead of a move. If you copy from source to destination, it will write a new file at the destination using the user share settings. Then you can delete from the source.

Apparently fixed itself according to the post just above yours.

Looks like several similar reports on @Squid's threads. He will probably be along soon to give us some insight.

Probably your server is having a problem reaching the internet. Can you ping github from your server?

Probably your server can't reach the internet for some reason. Can you ping github from your server?

Does it happen in SAFE mode?

The Console option gives you a bash command line inside the container, so that is all you need.,

Try booting from another USB port, preferably USB2.

Since that plugin installs a custom build of Unraid your report doesn't belong here. Try to reproduce on the actual Unraid release this report thread is about.

That problem is sort of the compliment of the other problem being mentioned earlier, mixing disks and user shares when moving/copying. If you move/copy from a user share to a disk, or from a disk to a user share, Linux doesn't realize that the source path and the destination path might actually be the same file. So it tries to overwrite the file it is trying to read.