trurl

The specific user I had replied to says they are still having the problem on 6.6.5, and they haven't posted a diagnostic that I have seen. Or replied with a less vague description of their specific situation. So the more general point I was making is illustrated very well.

Unfortunately Nov 14 20:01:38 Tower kernel: BTRFS: error (device sdb1) in __btrfs_free_extent:6950: errno=-2 No such entry Nov 14 20:01:38 Tower kernel: BTRFS info (device sdb1): forced readonly

Has anybody actually posted their diagnostics on this? Many people aren't reporting this so it would be useful to know what is different about your configuration. Also, depending on the exact details of your symptoms, it is possible some problem with your configuration or other systems on your network is the actual cause and not some particular version of Unraid. For example, what do you mean exactly when you say your user shares are gone? Gone from the webUI, or gone from the network? If they are just not showing up in the webUI it is likely a browser issue. And if the user shares are not in the webUI or on the network, then it is possible some other issue with your disks is breaking user shares. As always, just because your vague description of your problem reminds you of another persons vague description of their problem doesn't mean the details of your problem is the same as theirs.

Upgrade to 6.6.5.

What I was trying to get at earlier about how a deluge plugin is installed. I don't know, am not inclined to research it since I don't use it, and you haven't told me. A docker container is a little OS designed to hold a single application. The question is whether or not the installed plugin resides in Unraid storage (appdata) or resides somewhere else in that little OS. If it isn't in appdata it won't persist since updating the container replaces that little OS. Maybe someone who uses this will be able to help you.

I guess it's not as bad as thinking someones nym is "Member". Constructor is a custom setting based on trurl.

"Member", your run command looks OK. Maybe you're having a symptom of a larger problem with your system. Next time it happens go to Tools - Diagnostics and attach the complete zip to your next post.

As Squid said then, seem reasonable.

So which is it, 46GB or 4.7GB?

This doesn't really tell me how you install a deluge plugin. As I said, I don't use it. Also, you should set appdata to cache-prefer not cache-only. See here for more details on how the cache settings work and ask if you need more explanation: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?page=2#comment-537383

If it works when you restart then I think it is likely you have something misconfigured. Post your docker run command as seen here: https://forums.unraid.net/topic/57181-real-docker-faq/#comment-564345

Could you elaborate on "unresponsive"? The Plex UI is unresponsive? Or Plex isn't serving media to your plex clients? Or ...

I don't use this docker and haven't use the application either. How is this plugin installed? Typically the only things that persist in a docker is things in appdata since container updates are basically a reinstall.

If you delete the docker and delete its appdata then there isn't anything else to delete. I question whether this is a solution to any problem though.

As I mentioned before this will depend on Minimum Free for cache in Global Share Settings. Unraid will only overflow if cache has less than Minimum Free. It decides when it begins to write the file which disk to use. If you fill up cache to 100% it is too late for it to decide. It isn't clear if he really understood my point or not since the reason he gives for not being concerned about it is not really relevant to the point I was making.

You are many versions behind. The current stable release is 6.6.5 There is no auto update for the OS, only plugins and dockers.

The most recent versions of Unraid make this very easy. Simply click on the icon for the container and select >_Console.

You might want to make that mapping RO to prevent the container from possibly overwriting something in the HOST OS. Also, maybe use a subfolder of /var on the container side to prevent HOST from overwriting something in the container OS.

These lines in the first script in the OP are where the backup happens. You could just duplicate these lines for each share you want to backup: logger Pictures share -t$PROG_NAME rsync -a -v /mnt/user/Pictures $MOUNTPOINT/ 2>&1 >> $LOGFILE To keep each share backed up to a separate folder, you would put a subfolder after $MOUNTPOINT/

Typically, if you have an incorrect Host path, the symptom would be RAM filling and data not surviving a reboot. This is because the Unraid OS (the Host) is in RAM, so any path that isn't mounted storage is in RAM. Filling docker image would be due to some setting within the application itself that causes something to be written to a path that isn't mapped to a container volume. This is because the OS within the container is in the docker image, and any path that isn't mapped gets stored in docker image.

Definitely the wrong idea. If you have things correctly configured it's unlikely you would need anywhere near 20G. As Squid said, you have some application(s) writing to a folder that isn't mapped. Common mistakes are not beginning a path with / or using the wrong upper/lower case. Each application must be configured so it is only writing into paths that are mapped to Unraid storage as specified in the volume mappings for each container. Do you understand docker volume mappings? Have you looked at the docker FAQ? There is a lot there about this problem as well as other good info. https://forums.unraid.net/topic/57181-real-docker-faq/ I recommend after you get things straightened out that you decrease the image back to 20G. That way you will know sooner rather than later if you still have a problem.

You might take a look at some of the rest of the Docker FAQ. Until you understand volume mapping you will always be wondering what to do and why it doesn't work.

This mapping will have created a /data directory in RAM, since /data (the HOST side of this mapping) isn't a path on actual Unraid storage, and so it gets created in the root of the OS folders, which is in RAM. You will have to reboot to get rid of that folder. If you didn't download anything to it then it probably isn't important for now, but if you did then it could be taking up a lot of memory.

I don't use this docker, but this seems like a basic question of your volume mappings. Do you understand docker volume mappings? Post your docker run command as shown in this first link from the Docker FAQ: https://forums.unraid.net/topic/57181-real-docker-faq/#comment-564345

@alael Syslog snippets are seldom sufficient. Go to Tools - Diagnostics and attach the complete zip to your next post.