External Storage: files & dirs created with wrong permissions

I’m facing a problem with Nextcloud.

I have mounted a local directory to all the users. The users can browse and upload stuff without any problem.

The issues is that the same folder is mounted to other services and the file permissions prevent the other users/services to modify the files uploaded via nextcloud.

For example, direcotories are created with 755 I would like to have a 775 permission so all the users in teh same group can write and modify that directory. Same for the files: I want that the whole group have the permission to edit that file.

Now, nextcloud is setting its user correctly and also the group the only issue is the restrictive mask for a shared folder.

Is there a way to specify a create mask for that specific external storages?


1 Like

What Operationg system?
What kind of external storage?

facing the same problem. Want my files added by nextcloud to have 777 permissions.
Anyone solved this ?

The host OS is Debian, Nextcloud is running under Docker.

Local storage is a simple local directory.

With Linux/unix systems you have to use the umask settings for the nextcloud/webserver user.
This will set the default behavior of setting file/directory permissions.

Yes, but this will change the mask of all the files/dirs created by Nextcloud.

I have to change this only for this specific External Storage

How do we fix this within the application? I am running nextcloud in a container and not really able to rebuild the whole container from scratch at this time.

nextcloud is a php application (as you know :grinning:) so one can use the functions fileperms and chmod of php to check and set file permissions. As this (as far as I know) is not already implemented, you have to do it yourself - maybe an addon?

An addon to an addon?

Addon to a base functionality (documents)?

How about to set Access Control Lists?

sudo setfacl -Rdm g:SomeGroup:rwx /your/folder/to/share/docker
sudo chmod -R 775 /your/folder/to/share/docker

The above command forces any new sub-folders within the /your/folder/to/share/docker folder to inherit permissions from the docker folder.

… and if the filesystem supports ACLs, and if the application honors these ACLs it could work… but usually not.

I was hoping this was something that could be fixed within the functionality of the core application or the add-on rather than use a work-around. It is something that is usually handled on an application level and should be addressed. Especially when dealing with shared access.

To be honest in this case helps cron with simple line:

find . ! -group foo -exec chown www-data:foo {} \;

All files and folders are set to the group foo and will be nice to added your www-data to this group also:

usermod -a -G foo www-data

You want me to create an entire new docker container to work around this one issue of changing the group access to +w by changing the owner of the folder? Would it not be better to just write this into the code so that when it writes a file it sets the group write access to +w or allows us to set what it sets in the options? This way people do not have to learn cron, or shell commands, or how to create a docker container (in my case) and start hacking the sh*t out of their system?

I also use a docker and expose shared folder e.g. under /var/docker/shared Then all containers has this folder mounted and (usually) use docker user and docker group to create and access files.

Simple cron with find command from above on a host machine will change group so that other applications from the Host machine can access files.

E.g. my nextcloud is on local machine with user www-data. Now I trying to access docker shared folder under /var/docker/shared from it. I set group to foo and added user www-data to this group. Now my Nextcloud from local host and docker containers has an access to the shared local folder. Also I can added to group foo my local user and access files without sudo.

… if your docker container has the same uids and gids matching the uids/gids of the server presenting the shared folder - if not -> mess!!

Its depends on particular container, if .yaml file will not use PUID/GUID as variables or from environments, but something that is ether hard coded or could not be changed without rebuild the container, then user could be even in numbers because does not exist in local host.
But this is not a big issue as soon as your container mounted folders are managed.

Why can we not just fix the options in the plugin so we can specify a file and folder create mask instead of jumping through all these hoops. And yeah, if the shared folder is big with lots of files then every five my minutes I have to have my server sorting through all that? Then if someone uploads a file for 5 minutes no one else can access it? This is all silly. Just fix the problem in the code. PLEASE??? Why is this so difficult?

1 Like

This is obviously a huge bug that prevents the app from being usable. So I am just going to sit here and politely BUMP THIS in hopes that the developer of it sees it and ads the few lines of coded needed to make this work.