Hi,

I'm seeking some general problem solving advice here.
First of all, I'm definitely not an unraid guru, but I'm not afraid to use terminal and I do have some basic linux knowledge.

That said, a couple of years ago I started out to set up my unraid box on fairly modest hardware. The push to get started was a stupid accident with a Synology 8 disk box, but I won't go into that.

My knowledge of Docker containers is sub-par.

What happened / happens?

• I mainly use my unraid server as filestorage and to do some qbittorrenting.

• I also recently discovered that my license had run out, so I set out to purchase a years worth of updates. I'm on 7.3.2 at the moment.

• I then gradually discovered that most of the docker containers that I was running had updates available, so I ran the updates.

Now what is my main problem:

• It seems that quite often all network connections to my smb shares are dropped or reset?

• Most importantly, my qbittorrent container (binhex) does not seem to download anymore?

• Admittedly, I have been trying to solve another problem, being that I would like to be able to use qbittorrent's auto filing capability, meaning that if e.g. I tag a file as music, that it will save the completed download to e.g. /media/music
  But as I have been following binhex youtube tutorial (thanks for those!) I have used the example /downloads/complete and /downloads/incomplete file structure.
  I'm not sure if this issue is due to the general behaviour or limitation of Docker containers, or due to erroneous settings. Main question is: Can a binhex-qbittorrent docker container save completed downloads to a media share?

• As a test, I have been running qbittorrent and transmission directly on my mac, and tried to save the downloads onto my unraid server. As a result, what happens is that regularly the smb shares are disconnected, breaking the local (non docker) qbittorrent and transmission downloads.
  
  So I'm at a loss on how or where to start debugging this problem?

• It seems most important to me to fix the inadvertent smb breakdowns and then the qbittorrent not downloading
  
  I realise that to help solve this issue, most probably more information from logs is required, but I prefer to await some idea's or instructions on what / where to look exactly to try to solve these issues.
  Here's a snippet of webterminal/syslog:
  Aug 23 17:55:01 Tower kernel: docker0: port 3(veth7ed4d3b) entered disabled state

  Aug 23 17:55:01 Tower kernel: veth6c37bf3: renamed from eth0

  Aug 23 17:55:01 Tower kernel: docker0: port 3(veth7ed4d3b) entered disabled state

  Aug 23 17:55:01 Tower kernel: veth7ed4d3b (unregistering): left allmulticast mode

  Aug 23 17:55:01 Tower kernel: veth7ed4d3b (unregistering): left promiscuous mode

  Aug 23 17:55:01 Tower kernel: docker0: port 3(veth7ed4d3b) entered disabled state

  Aug 23 17:55:02 Tower kernel: docker0: port 2(veth1baa129) entered disabled state

  Aug 23 17:55:02 Tower kernel: veth9f0d115: renamed from eth0

  Aug 23 17:55:02 Tower kernel: docker0: port 2(veth1baa129) entered disabled state

  Aug 23 17:55:02 Tower kernel: veth1baa129 (unregistering): left allmulticast mode

  Aug 23 17:55:02 Tower kernel: veth1baa129 (unregistering): left promiscuous mode

  Aug 23 17:55:02 Tower kernel: docker0: port 2(veth1baa129) entered disabled state

  Aug 23 17:55:03 Tower kernel: docker0: port 2(veth2ab31b9) entered blocking state

  Aug 23 17:55:03 Tower kernel: docker0: port 2(veth2ab31b9) entered disabled state

  Aug 23 17:55:03 Tower kernel: veth2ab31b9: entered allmulticast mode

  Aug 23 17:55:03 Tower kernel: veth2ab31b9: entered promiscuous mode

  Aug 23 17:55:03 Tower kernel: eth0: renamed from vethb779dd2

  Aug 23 17:55:03 Tower kernel: docker0: port 2(veth2ab31b9) entered blocking state

  Aug 23 17:55:03 Tower kernel: docker0: port 2(veth2ab31b9) entered forwarding state

  Aug 23 17:55:03 Tower kernel: docker0: port 3(vethc3ee6ab) entered blocking state

  Aug 23 17:55:03 Tower kernel: docker0: port 3(vethc3ee6ab) entered disabled state

  Aug 23 17:55:03 Tower kernel: vethc3ee6ab: entered allmulticast mode

  Aug 23 17:55:03 Tower kernel: vethc3ee6ab: entered promiscuous mode

  Aug 23 17:55:03 Tower kernel: eth0: renamed from veth710ba51

  Aug 23 17:55:03 Tower kernel: docker0: port 3(vethc3ee6ab) entered blocking state

  Aug 23 17:55:03 Tower kernel: docker0: port 3(vethc3ee6ab) entered forwarding state

Thanks for helping out!

Edited yesterday at 06:48 PM1 day by panini

You are likely to get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread.

It is always a good idea to do this to allow us to see the current state of your system and so we can see logs and configuration information.

If anyone spots anything and comes to a conclusion you can then ask where they spotted the information that lead them to a suggestion if you want to think about doing this for yourself in the future.

As requested, here's the diagnostics zip.

Thanks for pointing out this requirement!

tower-diagnostics-20260823-2118.zip

Probably not an explanation for some of your problems, but

Aug 23 19:18:51 Tower root: Fix Common Problems: Error: Same share (media) exists in a different case
Aug 23 19:18:51 Tower root: Fix Common Problems: Error: Same share (Media) exists in a different case

This will definitely cause you some problems accessing the share via SMB since SMB is not case-sensitive and will only access files from one of these.

Probably you have accidentally created one of these by specifying the wrong upper/lower case for a host path in one or more containers.

Thanks for spotting that!

How did you manage to spot that so quickly / easily? What tool did you use, if any?

Will check tomorrow, but that probably happened when I tried to redirect qbittorrent downloads!

Will post back the results!
Thanks for helping out!

Edited 14 hours ago14 hr by panini

Ok, so indeed it appears this misspelled Media share has been created.

I ssh'ed into my unraid server and searched for this share / folder, went in and noticed it indeed contains the two dirs completed and incomplete, and a whole bunch of downloaded files. So I guess at some point 'after' committing the error, qbittorrent has been working to re-download these files.

My first reflex was to see if I could try and move these files back to where they belong. But then I noticed that this Media share is not public, so I can not set the "Public" property.
I would prefer to use smb to move these files but I cannot approach them.

Is there maybe a way to fix this by manually editing some config file?

What would be the recommended way to proceed here?

Would it be an option to disable / stop the binhex-qbittorrent docker, then recreate a blank new binhex-qbittorrent instance (I've read that two of the same docker instances should be possible). Then first test this new docker instance and only after that gradually bring over each of the downloads?
Although that will be a cumbersome job...

Thanks for any further advice or help!

The system gets very confused if you have folders on the drives with the same name but different capitalization.

Make sue that any paths in docker volume mapping are as you want them to end up,

It would be easiest to Unraid's built-in File Manager to move files to the correct location. I would recommend that any docker containers that might use these paths are stopped while doing this.

After that check the /boot/config/shares folder and check if there is a .cfg file with the capitalization that corresponds to the actual share folders on the drives. That system uses FAT32 so you cannot simply rename one to the correct capitalisation in a single step. If there is one with the wrong capitalization then remove it and return to the shares tab and make sure the settings for that share are as you want them. When you hit 'Apply' a new .cfg file will be created with the correct capitalization.