Directory Permissions

[mwadley]

I've run into the situation multiple times where apps did not have permission to write to folders. Specifically, I have run into this with Syncthing and Qbittorrent. For Syncthing I could not write to folders outside of the directory where it is installed due to lack of permission so all of my files are in the "/Docker/Syncthing/config/" directory. I recently installed Qbittorrent and a similar issue arose where I did not have permission to put things specifically where I wanted them like my Syncthing directory folders where I keep everything, but it did allow me to save things under the Downloads directory.

So my question is--is there a way to force permissions so that I can allow programs to store things in the directories that I choose?

[Nazar78]

Usually the docker apps you install from the apps central runs using user admin (999) and group admin (999). It also depends on the umask usually default 0022 (755) set by the apps environment for the new child paths or files being created. So if the child data created is lesser than permission 666, you should ensure the parent target path is owned by user and/or group admin.

Some other ways is to set the uid/gid of the container but you'll need to recreate the container. Or use another umask like 0000, this requires building a new image changing the entry point to call a script to change the umask before running the app.

[mwadley]

Thanks for the tips as it gave me some ideas. I was able to fix this, but I am not sure what exactly fixed it since I changed several things at once.

I uninstalled the Docker version of Qbittorrent and switched to the native version.
After logging into the terminal, I noticed that I was using the wrong directory where the actual directory should start with "volume1/..." which isn't obvious at first glance.

The permissions of the folders seemed to check out as well since the folders I was concerned with belonged to admin/administrators. It seems that others have had issues with Qbittorrent binding to the default directory as well, but it may have been fixed with newer versions. Now that I have fixed this, my current dilemma is whether or not I should trust syncing files 2 ways after the whole Deadbolt ordeal of 2022.