Docker created folder now has read only permissions for smb user

Hey,

this is probably a very simple issue but I don't get how it came to be.

I setup a containter that contained the following volume:

- /MEDIA/downloads:/downloads

That worked fine, volume got created and the container has no issue writing in the folder.

The issue that my SMB account now has only read access to the downloads and sub directory.

This is the output for

ls -lr /MEDIA/

$ ls -al /MEDIA/
total 60
drwxrwsr-x  1 root    users   118 May 13 11:50 .
drwxr-xr-x  1 root    root     18 May  6 10:14 ..
drwxr-sr-x  1 appuser users   104 May 13 11:48 downloads
drwxrwsr-x  1 root    users    36 May  9 22:07 entertainment
$

As you can see, the owner of downloads as wanted is appuser, but write access for users seems missing. I can figure out how to re-add that permission even without reset permissions, but I don't get why it was setup that way to beginn with.

What did I screw up?

Greetings.

Quote from chente

Not knowing which container did this, I assume that container created that folder, and by default it will do so with read-only permissions.

If you want to make sure that doesn't happen you can create the folder before launching the container.

To fix it simply change the permissions of that folder. The container will continue to function without issue.

Was a bitorrent container. Assumed that wasn't relevant.

If I create the folders beforehand it will be owned by my ssh account - could that pose a problem for any containers? I've tried avoiding this since I'm uncertain on the effects of that.

Quote from chente

Creating the folder ahead of time shouldn't be a problem, as long as you create that folder with access permissions for the user defined in the container.

One way to ensure that is to create the folder with read and write permissions for the users group and that user is in the users group. There are other ways to do it.

Okay. That I can do easily.

But I just noticed that my beginning issue is not fixxed.

As is the nature of a downloads folder, the container will create frequently subfolders in there.

And as I just noticed - those, just as well as the top folder are read only for my SMB user.

I can (and have) changed the permissions of the /MEDIA/downloads parent folder, but it seems a big hassle to manually do this for every sub folder that will be created there.

So how can I shut that behaviour down?

Quote from chente

Sorry I don't use that container. You can do a search on the forum. I think I've read that problem before. You will probably find solutions for that bittorrent behavior.

Since I have no good reason to use qbittorrent other than just .. well ...

You mind sharing your way? Always curious for input and it's probably very clear I just started setting up

All in all, thanks for all the help so far from you and everyone

aaaand you edited an answer to the problem .. you guys are great :s thanks

So, sadly this is still relevant.
I also tried to use Deluge instead but I still have the same issue. Every folder that gets created within /MEDIA/downloads will have 741 (should be correct? As in drwxr-sr-x)

I removed the downloads folder completely and had it be recreated by the containers, to no avail.

I found about umask in the qbittorrent documentary and (while honeslty not exactly understanding what it does?) tried to add umask=000 and umask=022 into the yml file. That seemed to put the proper permissions on the folder as to "ls -al" command but weirdly I then still was not able to move the folder because then I would get the error prompt that the file was in use, no idea by what though.

At this point I am at a loss for ideas. Of course I could just access my SMH Folders with the appdata user and everyhing would be fine but I kind of refuse to let the system dictate how I structure my setup :s

Quote from chente

I think gderf uses bittorrent. Maybe he can help you.

Well said

It's not an exclusive qbittorrent issue at this point - like the very same problem occurs when using deluge too.

So it shouldn't be a container issue at this point. Both containers doing that seems werid to me.

Me setting things up wrong seems way more likely.

But simplicitys sake let me just post my yml files for people to look through:

qbittorrrent:

services:

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    network_mode: container:gluetun-gluetun-1
    environment:
      - PUID=1002
      - PGID=100
      - TZ=Europe/Berlin
      - WEBUI_PORT=8586
    volumes:
      - /SSD/appdata/qbittorrent/config:/config
      - /MEDIA/downloads:/downloads
    restart: always

And deluge:

---
version: "2.1"
services:
  deluge:
    image: lscr.io/linuxserver/deluge:latest
    container_name: deluge
    network_mode: container:gluetun-gluetun-1
    environment:
      - PUID=1002
      - PGID=100
      - TZ=Europe/Berlin
      - WEBUI_PORT=8112
      - DELUGE_LOGLEVEL=error #optional
    volumes:
      - /SSD/appdata/deluge/config:/config
      - /MEDIA/downloads:/downloads
    #ports:
    #  - 8112:8112
    #  - 6881:6881
    #  - 6881:6881/udp
    restart: unless-stopped

Okay this is confusing af to me.

I decided to just see what happens when I change the folder structure, only handing over new subdirectorys in the downloads category.

So I updated the volumes of qbit to look like this:

volumes:
- /SSD/appdata/qbittorrent/config:/config
- /MEDIA/downloads/unfinished:/unfinished
- /MEDIA/downloads/finished:/finished

The /MEDIA/downloads/ directory was pre created and had the correct permissions set as:

drwxrwsr-x 1 root users   0 May 14 08:25 downloads

So after putting up the container I got this:

dh_user@dh-sv:/$ ls -al /MEDIA/downloads/
total 0
drwxrwsr-x 1 root users 36 May 14 08:28 .
drwxrwsr-x 1 root users 60 May 14 08:25 ..
drwxr-sr-x 1 root root   0 May 14 08:28 finished
drwxr-sr-x 1 root root   0 May 14 08:28 unfinished

And now I am totally lost how the frick the owner and group is now set as root when I have defined:

      - PUID=1002
      - PGID=100

With appuser being:

dh_user@dh-sv:/$ id appuser
uid=1002(appuser) gid=100(users) groups=100(users),992(docker)

Issue solved.

Tried to put UMASK=002 into the yml another time and this time it worked. I have no idea what caused issues when I tried it before but since my default UMASK is set to 022 it lines up with my issue so that apprently was it.

Gonna look into changing the system default one to 002 since I don't see any logic in having it as 022 for my usecase but will do that another time.

Anyway, marking thread as solved, thanks for the input enjoy your sunday