Mount points within docker containers

[jj_uk]

So i'm here from FreeNAS because its a PITA to use, I'm finding unRAID easy, so i'm moving over to unRAID (slowly).

 

I'm new to Docker, and I wondered why docker template authors don't mount external ( unraid array) storage into the docker in the docker's /mnt/ folder?

 

In FreeNAS (jails), when adding storage, the path inside the container(jail) is always /mnt/<path>/.

But in unRAID, the docker container paths are just anywhere in the container, e.g. /data/, /media/ etc.

 

Having them all mount into /mnt/ makes the paths easier to find when selecting from within a docker application's gui, or on the console, as all storage in the docker will be in the docker's /mnt/ folder, so just need to look there...

 

Think about the SAB template, it mounts several paths in to the docker container.

(from memory)

/data/

/recyclebin/

/completed/

/incomplete/

... etc,

 

If they were all in /mnt/ in the docker, they'd be easier to find: 

 

/mnt/data/

/mnt/completed/

/mnt/incomplete/

/mnt/recyclebin/

 

..etc

 

Just wondered!

 

[Squid]

You can change any of the container paths on pretty much any particular app to your hearts content, and adjust the settings within the app to suit.

 

As to why the convention of not having them all in /mnt, who knows.

[trurl]

4 hours ago, jj_uk said:

If they were all in /mnt/ in the docker, they'd be easier to find: 

 

/mnt/data/

/mnt/completed/

/mnt/incomplete/

/mnt/recyclebin/

 

..etc

 

I think this would only compound the confusion users have about mapping, since on the Host these would be /mnt/user/data, etc.

[jj_uk]

All the mounts in the mnt folder makes sense. All in one place.

 

Anyway...... If i change my docker mount locations, when i update the docker containers later, will they remain or be changed back to the default template locations?

 

 

[Squid]

They'll stay the same

[Squid]

3 hours ago, trurl said:

 

I think this would only compound the confusion users have about mapping, since on the Host these would be /mnt/user/data, etc.

Or you can always map /mnt to /mnt (although I disagree with doing that)

[ken-ji]

One core security tenet is principle of least privilege.

As the dockers are made by a third person, or contain binaries made by 3rd parties, it make absolute sense not to give the container complete access to you entire array of data via the /mnt location. Even containers for backing up data (here I'd rather they have read-only access to everything they will be backing up).

Some docker images are made for general (non-unRAID) consumption, so the idea that everything is under /mnt is just not correct.

 

Please remember that when the docker container accesses data from /data, the user just needs to remember that whatever I mapped to /data is whatever the container can access, without worrying about vulnerabilities in the app allowing access to other unnecessary stuff.

 

This however can cause difficulties when trying to get apps that talk to each other directly; passing the file paths as each container finishes processing

[trurl]

4 hours ago, Squid said:

Or you can always map /mnt to /mnt (although I disagree with doing that)

 

That would also allow a docker to create folders and files that are not actually in mounted storage.

[Squid]

10 hours ago, trurl said:

 

That would also allow a docker to create folders and files that are not actually in mounted storage.

I did say that I didn't agree with it