trurl

Did you try the support thread for Community Applications? Looks like this has been discussed recently.

Just make sure they aren't too short. If a cable barely reaches then it is going to have forces acting on it which can affect the connection.

Doesn't look like you have a mapping for any of your media. You should have used Community Applications - Previous Apps to reinstall with the previous settings.

endiz: You should consider why you even want this though. If you get to a place where they are even, then most free is going to write one, then maybe write the other, then maybe write the first, etc., simply because each disk briefly has the most free. High-water is the default because it is a compromise between distributing the files, and constantly switching disks. Unless your first disk is really nearly full you might just let it alone. Rather than worrying about even distribution, you should make sure you set the Minimum Free for each user share. Minimum Free should be set larger than the largest file you expect to write. It has no way to know how large a write will become, so if it has more than Minimum Free, it can choose the disk and if the file is too large, it will fail. If a disk has less than Minimum Free, it will choose a different disk.

Now your unmount script is the same as your mount script.

Actually I was suggesting you try SMB instead of AFP since your syslog makes me think it is doing AFP.

Under Settings, Network Services, there is are global settings for each protocol, AFP, NFS, SMB. Each user share has its own security settings for each enabled protocol.

Have you tried using SMB instead of AFP?

New diagnostics? Collected after the behavior but before reboot.

What does USB have to do with this?

I don't use this docker, or even the LSIO one, since I use nzbget instead. According to your docker run command, /mnt/user/appdata/binhex-sabnzbd is mapped to /config. This seems correct. So, the /config folder the application sees is actually the /mnt/user/appdata/binhex-sabnzbd folder in unRAID. This is fairly typical of unRAID dockers generally. Unless the application actually has a config folder inside its config folder, there won't be a config folder in your binhex-sab appdata folder. So, where did you put that scripts folder you created? If you have a folder /mnt/user/appdata/binhex-sabnzbd/scripts, then the application will see that scripts folder at /config/scripts. Does that seem to make sense to your understanding of volume mappings? I can merge these posts into the binhex thread if you want to continue working with the binhex docker.

Some way to force this would save more people than the few with invalid server names.

Not just updates, reboots. The unRAID OS is loaded into RAMfs clean and fresh from the archives on the flash drive at each boot, then settings saved from the webUI are applied. Changes to any of the usual linux folders such as /usr do not persist after reboot. Only files on /boot (the flash drive) and things mounted in /mnt (actual storage) are persistent. To automatically reapply changes after reboot, see the User Scripts plugin.

Perfect example of something I wouldn't normally notice in the diagnostics, hence the other thread I started in the Bar.

If you automatically change it, the user is still going to wonder why they can't access the server with the old name. And it wouldn't necesarily be obvious since networking issues can have several causes. It was just a stroke of luck the user told us his login was for server (none) today.

Yes. If you have multiple dockers that need access to the same storage, you setup a common storage for them to use, and not put it all under the appdata for one of the apps.

That guide you followed doesn't really talk about the extra layer involved when you are using dockers. Dockers sort of make it where each of these applications is running on a different machine. Also, this isn't the thread for support of binhex-sab. This makes me question whether or not you understand volume mapping. You really should read the Docker FAQ. Post your docker run for the container. See here:

You will have to stop the docker to edit settings.json. You might have to use Config File Editor plugin since it will have root access and it will also make sure the saved file has linux line endings unlike some Windows editor like Notepad. To fix permissions on existing files use Docker Safe New Perms in Tools.

dmtalon, I have split your posts to their own thread here: https://lime-technology.com/forums/topic/70417-dmtalon-btrfs-errors-on-device-loop2/

This is the unRAID forum. LinuxServerIO has another forum to support their dockers on other platforms. From first post in this thread:

If you mean at the console, it isn't even necessary to go there, and not recommended for beginners. But the user name is 'root' with no password until you set one. You should just go to the webUI to set everything up.

Also, I wonder if there isn't something wrong with the way your browser is displaying that page in the screenshots that isn't showing the container paths. Do you have an adblocker or any incompatible or out-of-date plugins?

I would still like to see your docker run command, which is explained in the first link of the FAQ. Could you explain a little more exactly what you mean by "plex settings" that you say aren't saved?