trurl

Your sig says you are still on a very old v5rc, which of course is wrong since you were having docker issues before upgrading to 6.3.3. So, what version of unRAID did you just update from? Did you read the release notes for 6.3.3? I have not looked at your syslog. For v6, unless we specifically ask for just a syslog, you should always go to Tools - Diagnostics and post the complete diagnostics zip, which contains syslog(s) and many other things which might help diagnose your problem.

Or even better void f(*b) { (*b)++; } main() { int a = 1; f(*a); } Even though f doesn't know anything named a, it is still able to change its value.

Maybe a better C analogy would be like you passed a pointer in a function call. int function f(int *b) { return *b + 2; } main() { int a = 3; a = f(*a); } main doesn't know anything named b, f doesn't know anything named a. unRAID doesn't know anything named /books, LL doesn't know anything named /mnt/user/Books.

The mapping happens at the level of the docker engine. The docker container has the mapping between container volumes and host volumes. The application living inside the container only knows about things inside the container, such as the container volume. It doesn't know anything at all about the host volume, or even that it exists.

Sounds like you don't really "get" dockers. As I said The application has no way of knowing anything about how the docker container it is living in is configured. That is just a cheap and easy (and insecure) way of getting things figured out. It shouldn't be considered a permanent solution. You have basically given those docker applications complete access to all of your files, even the files that it doesn't need to work with. And it makes it easier for you to misconfigure one of the applications so it does something to some file or folder that it shouldn't have access to.

Since I don't use this application I have no way of knowing how it is getting Books. The application itself doesn't actually know anything about volume mappings. Indeed, it doesn't even know that it is running in a docker. I had already seen your docker mappings and that is why I said What you haven't shown us is anything from the application itself that tells it what folder to use. The log seems to indicate it is using /Books instead of /books.

Looks like you have configured it within the application to use the folder /Books, but your docker has it mapped to /books.

From the first post in this thread: There are different operations in various active areas (especially the disk serial number) based on whether or not the disk drive is mounted. If the disk is not mounted, click on the serial number, click on the partition name, then you can type a new mount point name. Press Enter for the name change to be applied. This will now become the mount point and the share name when the disk is shared.

Map to the remote folders you mounted in Unassigned Devices and change the mappings Access Mode to slave.

Generally, you can assume that the term volume mapping is referring to dockers. Do you have any working dockers?

Have you set your volume mappings to "slave"?

I prefer to keep the terminology clearer. When you add a disk to the array, unRAID clears it if it is not already clear. You can also preclear a disk, which makes it clear before (pre) adding it. I haven't done either recently. So, which of these end up in the parity log, clear, or preclear, or both (or neither)?

No, they have to do with disk I/O.

In general you should always check for updates before asking for plugin support. Looks like you are running a pretty old version of unRAID also.

Are you sure you are using the current version of the plugin?

This question has an answer. Sorry, see Docker FAQ in Docker Engine subforum. More specifically, But, if you look up just one post from yours you will see the zoneminder docker isn't getting much support.

I don't use this, but in general the syslog will often not help with diagnosing dockers since dockers are isolated from the system. Have you read the Docker FAQ at the top of this subforum?

This means you have accidentally created a user share named "cache". Any top level folder from cache or array disks is automatically a user share named for the folder with default settings. If you have the Fix Common Problems plugin installed it will give you a warning about this. This is not generally a good idea because you will see it over the network and think it is referring to the cache disk when really it is a user share that happens to be named "cache".

When you say it is empty, is that based on the command I asked you to enter, or is it based on some other view you have of the folder? How are you trying to delete the folder? You can't delete a User Share from WIndows, for example. That would be true whether you are working with unRAID or some other network share on some other computer. But you should be able to delete it from mc or the unRAID webUI.

OK, that indicates you have a folder named "disk3" on disk3, which is what we thought, but I wanted to make sure it was a folder and not a file named "disk3". And none of your other disks have a folder named "disk3" on them. The "disk3" folder in user and user0 are just a reflection of the "disk3" folder on your disks. So, what was the issue you had trying to get into that folder in mc? What do you get at the command line with this? ls -lah /mnt/disk3/disk3

Did you already give us this?

Do you have linuxserver plex installed now? DId it ever work for you? Do you have any other working dockers?

OK, let's try this: tree /mnt -n -F -L 2 -o /boot/tree.txt Then, go to your flash share and get the tree.txt file and post it.

You aren't running the plugin and docker at the same time are you?

Does your server have internet access?