trurl

yes, it's from the transmission docker it says "/downloads" If your mappings are indeed what you say (are you sure you don't have them backwards?), then the container doesn't know about the path "/mnt/cache/downloads/incoming", unless you told it about that path through its user interface (or possibly .json though it isn't clear how that would get involved for this specific case). When you first add a torrent, the user interface lets you override the default download location. When you added the torrent, did you perhaps tell it to download it to "/mnt/cache/downloads/incoming"? I see from your post history that you used to use PhAzE plugins. Is it possible that somehow you have resumed a torrent that was originally added from a plugin version of Transmission and you are reusing the Transmission appdata from that plugin? Probably should have asked this long ago. Post your docker run command.

It was 10GB originally and I raised it to 20GB. Go to Tools - Diagnostics and post the complete diagnostics zip

Which log is this? If it is the log from the transmission docker itself then that just further illustrates what I have been saying. The container doesn't know anything about the path "/mnt/cache/downloads/incoming". It is going to refer to that host path as "/downloads". If you click on the wrench button at the bottom of the Transmission webUI, what does it say for "Dowload to"?

Next time you try to follow any instructions, you should read them all and see if you can understand what they are doing. Then ask for further clarification.

How large is your docker.img? If you have tried to fix this by making it larger you are probably doing something wrong. 20GB should be plenty.

What exactly do you mean by "docker configurations"? The appdata? The settings from the webUI that create the docker? The docker.img? (easily recreated) Something else? How exactly did you add your dockers back? If you used Community Applications to add your Previous Apps, they should have found your appdata, assuming you didn't lose it or misplace it when you were doing the steps. Or you could have selected the "my-whatever" from the Add Container dropdown (which is basically what CA Previous Apps does). Did you lose your appdata? Or did you just misplace it? If you followed all of those steps it should have worked since it would have moved your appdata off cache before replacing (formatting) it, then moved it back when you were done.

What exactly do you mean by "docker configurations"? The appdata? The settings from the webUI that create the docker? The docker.img? (easily recreated) Something else?

Then why did you say With those mappings, when you double click the finished torrent it should say the location is /downloads.

I misunderstood your question. I assumed you wanted to know what that share should be set to when you have finished fixing your cache disk. The point of that particular step in those instructions is to move everything off of the cache disk so you can replace (or in your case, format) it. Then later it has another step that will move it all back. Reread all of the steps and see if it makes sense as a whole.

If you go to the settings page for a user share and turn on Help it will explain the various settings including the use cache setting. The Help button is a toggle and will stay on until you turn it off. If it is turned on the webUI will show you help for any of its pages. Try that and let me know if you don't understand why Yes is the wrong answer.

What exactly do you mean by "double click the finished torrent"? In the Transmission webUI? Transmission doesn't understand the folder path /mnt/cache/downloads/incoming, according to the mappings you said you have. It would refer to that unRAID host folder as /downloads. You have something misconfigured, either in the container settings, or within the Transmission application.

Another thing that can happen is you let it use most of the UPS battery and then power comes back so it doesn't need to shutdown. Then a little later power goes out again and your UPS hasn't had time to recharge so it doesn't have enough power left to let it shutdown.

If you expect to add additional cache drives in the future then btrfs is the only choice. If you will only use a single cache drive then many people here think XFS is more reliable.

You can just use the replace cache drive procedure from the FAQ: How do I replace/upgrade my single cache device? (unRAID v6.2 and above only) except instead of replacing the drive you can change its filesystem to get it formatted.

Your previous diagnostics was showing lots of cache drive full messages in syslog. Also df was showing it 100% used. You may have to reformat it.

Tools - Diagnostics Here is the diagnostics file. Check_Disk_Filesystems-Drives_formatted_with_BTRFS

Tools - Diagnostics

Thanks, trurl. Would freeing up space on the drives help with this DFI issue? Since, as I read it in the OP, the hashes are being added to the files, I can see where the additional disk space requirement might be exceeding what's physically available and thus preventing the hashes from being added. I can see where DFI would then think there were significantly fewer files on the disk since only a few have hashes added to them. The hashes, even exported to a separate file, don't take a lot of space. On the other hand, it is probably a good idea to not let your drives get too full, especially if they are ReiserFS. It doesn't perform well when a disk begins to run out of space and it's possible filesystem performance might impact this.

Link in his sig.

My trackers don't even allow rar files. What's the point? The media are already compressed, and the torrent itself is already an archive.

Anything you do from the command line within a docker only affects the current installation of that docker. Thank you. Now just to figure out how to get gcc installed on the docker lol Note I said the "current installation". If you ever have to reinstall for any reason anything you did from docker exec would have to be reapplied. Making your own docker with the changes already applied is the way to make them stick for a reinstall. Oh got it It's very strange that I'm the first one that encounters problems with https trackers on this container I don't use this docker, and I didn't even research your problem. Just telling you how dockers work in general.

Minimum free doesn't keep a disk from filling up. It just keeps unRAID from writing to a disk unless it has the minimum free. If you set it to 1GB, and it has 1.5GB free, then it will write to the disk regardless of how large the file will be because it doesn't know how large the file will be. If you have minimum set to 1GB, and you have 1.5GB free, and you try to write a 2GB file, it will fail due to not enough space. If you have minimum set to 1GB, and you have 1.5GB free, and you try to write a 1.4GB file, it will succeed because there is enough space, but then it won't write any other files because it no longer has 1GB free. So, you must set minimum free to be larger than the largest file you ever expect to write.

Anything you do from the command line within a docker only affects the current installation of that docker. Thank you. Now just to figure out how to get gcc installed on the docker lol Note I said the "current installation". If you ever have to reinstall for any reason anything you did from docker exec would have to be reapplied. Making your own docker with the changes already applied is the way to make them stick for a reinstall.

Anything you do from the command line within a docker only affects the current installation of that docker.

I merged his new thread with the rutorrent thread. Not crossposting has been a rule of internet etiquette since before the World Wide Web. Among other things if you post the same question in several different threads then people will waste their time giving answers that someone else already gave in another thread. Better to keep the discussion in one place.