(SOLVED) unRAID 6.8.3 Docker Containers not seeing files in Unassigned Devices

[Boomháuer]

(SOLVED) The issues was fixed by changing my Docker Container mount points from /mnt/disks/xxxx to /mnt/remotes/xxxx.

 

HELP! Power outage early this morning and the unRAID server didn't shutdown gracefully even with a UPS... which is a separate issue.  I've been working on this off and on all day but I can't get it working correctly. The issue at hand is complicated but here goes.

 

Unassigned Devices has 10 mounted SMB Shares, they have worked wonderfully for 250+ days of uptime until this morning. I can click on any of the Mount Points in Unassigned Devices and see all of the files that I expect to see.

 

However, when I go into a Docker Container, even though the path is there it doesn't see any files.  So for instance if I go into Krusader it's only seeing eight of the 10 shares and if I go into one of those shares it's not showing all of the directories that are supposed to be there and and inside of the directories that are there they are empty.  If I access them from my Windows 10 PC all of the files and directories are there as expected.

 

To try and fix this I have done the following:

- Stopped and Restarted the Array

- Rebooted the unRAID Server

- Recreated the shares under Unassigned Devices

- Removed and reinstalled Unassigned Devices

- Removed and reinstalled Krusader

- Deleted the whole Docker images and reinstalled all of the Containers... two of which I can't get reconfigured because I can't remember how to setup a different network name

 

Needless to say none of these things worked.  Any help or ideas would be GREATLY appreciated as I'm at the end of my rope with this.

unraid-diagnostics-20210108-1842.zip

Edited January 9, 2021 by Boomháuer
Marked as SOLVED

[trurl]

 

[Boomháuer]

@trurl, thank you for the reply however per my post I'm already using Unassigned Devices and like I said everything was working fine before the server lost power.  I also just went back to make sure that the paths were set to RW/Slave on all of the appropriate Containers and they are.

 

Any other ideas of what I could look at?

Edited January 9, 2021 by Boomháuer

[trurl]

 

[Boomháuer]

@trurl, so I went in and checked and turned on Legacy Mount Point Compatibility although I don't ever remember having to do that before but it did give me different results from what I was seeing before so progress I guess?

 

Now all 10 SMB Shares that show up in Unassigned Devices are showing up in Krusader BUT half of them are showing up as directories and half of them are showing up as files.  The ones that are showing up as directories are still empty and the ones that are files ask me what I want to use to open them when I click on them.

I've enclosed a PIC of what I'm seeing below.

[Boomháuer]

Okay, going along on this theme I decided to rename one of the Unassigned Devices Mount Point names.

 

I changed DROBO5N2_Music to DROBO_Music.  Krusader still showed it as a file and wouldn't do anything but pop up the dialogue box on what app to open it with however in the Terminal command line I was able to navigate to /mnt/disks and do a directory.  I could still see the DROBO5N2_Music which should have gone away I would have though and I also saw the new DROBO_Music@ with an "@" at the end of it.  However, I was still able to /mnt/disks/DROBO_Music, get a directory and see everything like I should.

So it's looking like the Unassigned Devices data has gotten corrupt maybe and I don't know where to go clear that out so that I can recreate these shares?

[Squid]

The "@" sign signifies that it's a symbolic link.  The actual directory is /mnt/remotes/DROBO_MUSIC

 

I've had the odd problem (read that as every container that I'm using with SMB shares) where if in the template I reference /mnt/disks/shareName it doesn't actually work within the container, but if I reference /mnt/remotes/shareName it does.

 

I don't have time until late February to really investigate what exactly is going on and if there is another flag you can use on the mapping to alleviate this.

[dlandon]

1 hour ago, Squid said:

The "@" sign signifies that it's a symbolic link.  The actual directory is /mnt/remotes/DROBO_MUSIC

 

I've had the odd problem (read that as every container that I'm using with SMB shares) where if in the template I reference /mnt/disks/shareName it doesn't actually work within the container, but if I reference /mnt/remotes/shareName it does.

 

I don't have time until late February to really investigate what exactly is going on and if there is another flag you can use on the mapping to alleviate this.

I think it's because the symbolic link needs a trailing '/' to indicate it's a directory.  i.e. /mnt/disks/shareName/

[Boomháuer]

Okay, I decided to not fight the system as it were and went in and updated everything to /mnt/remotes/shareName and now everything seems to be working fine with two exceptions.

• I still have five symbolic links in /mnt/disks and I misentered /mnt/remote instead of /mntremotes with an S in a couple of places and now have a couple of symbolic links there too.  Is there a way to get rid of these?
• I have an app I run in a Docker Container called taskcafe which had it's own taskcafe network listed under network instead of br0 or bridge.  I can't remember how I got that initially setup, I haven't gone looking for the solution yet but if you happen to know off the top of your head that would be great.

Regardless, thank you all for your help.  Linux is not my native OS and when things go sideways on me I can only go so far before way out in the weeds.

[dlandon]

18 minutes ago, Boomháuer said:

I still have five symbolic links in /mnt/disks and I misentered /mnt/remote instead of /mntremotes with an S in a couple of places and now have a couple of symbolic links there too.  Is there a way to get rid of these?

Turn off the legacy mount point compatibility and then unmount and re-mount your shares.  The /mnt/disks symlinks will disappear.

[Boomháuer]

@dlandon, I had already done that and the symbolic links were still there.  Just to be sure I made sure that Unassigned Devices had legacy mode turned off and I unmounted and remounted the shares.  The symbolic links are still showing up.

Maybe the unRAID 6.9.0 upgrade will come out soon and I can reboot the server then and see if that fixes the problem. 

Thanks again for your help.

[dlandon]

22 minutes ago, Boomháuer said:

@dlandon, I had already done that and the symbolic links were still there.  Just to be sure I made sure that Unassigned Devices had legacy mode turned off and I unmounted and remounted the shares.  The symbolic links are still showing up.

Maybe the unRAID 6.9.0 upgrade will come out soon and I can reboot the server then and see if that fixes the problem. 

Thanks again for your help.

The files left at /mnt/disks/ were probably created by your mistakes with setting up the paths.  There was an update of UD this morning if you care to update and reboot.

Edited January 9, 2021 by dlandon

[Boomháuer]

On 1/9/2021 at 6:43 PM, dlandon said:

The files left at /mnt/disks/ were probably created by your mistakes with setting up the paths.  There was an update of UD this morning if you care to update and reboot.

Updating UD and rebooting my server fixed the problem with the symbolic links.  Thanks again for your help.

Edited January 11, 2021 by Boomháuer

[DarkOneX2]

On 1/8/2021 at 5:46 PM, Boomháuer said:

(SOLVED) The issues was fixed by changing my Docker Container mount points from /mnt/disks/xxxx to /mnt/remotes/xxxx.

Dude thanks much for this, I just realized I had the same issue after I powered off my server last weekend to move it and I was looking through Crashplan and while it said my stuff was backing up and had the correct size, I couldn't browse the files.  Then I checked Krusader and same thing but found your fix and it worked!  Very weird, dunno why the change and what /remotes is but whatever, thanks again!