Is possible to restrict or limit the access to the Files App?


We are evaluating the usage of open ondemand in a restricted environment where we would like to control and restrict who can transfer files in and out.

Is it possible to disable the Files App by default and only allow some users to access it? Or disable the Files App completely for every user?

Thanks for any help or advice.

a colleague pointed me to the option of limiting the transfers as described in Customization — Open OnDemand 2.0.20 documentation .

The official docs suggest to edit /etc/ood/config/apps/shell/env and this link suggests to edit /etc/ood/config/apps/files/env

I have tried to edit both files:

$> cat /etc/ood/config/apps/files/env

$> cat /etc/ood/config/apps/shell/env

And then I did systemctl try-restart httpd24-httpd.service httpd24-htcacheclean.service but I can still upload files using the Files app. Am I doing something wrong?

I am using ondemand-2.0.23-1.el7.x86_64 installed using RPMs on Centos7.9

Hi Pablo. I am testing those docs and will get back to you. I’ve found the similar problem.


1 Like

The docs are wrong, sadly. It’s the wrong file, should be the dashboard’s environment file - /etc/ood/config/apps/dashboard/env.

I have edited the suggested file but it didn’t work.

[root@demo-open-ondemand ~]# cat /etc/ood/config/apps/{dashboard,files,shell}/env

As this is a test environment I did a complete reboot of the server to make sure the new settings are being applied but still no luck. I can upload files using the Files app.

My memory is those limits apply to the per-user side of things, so you would need to restart your account’s service using the ood web page by clocking on the “?” icon in the upper right, and selecting “restart web services”. That will restart all the processes running as “you”, which should cause the new settings to be picked up.



I would expect this to happen if I do a complete reboot of the server isn’t it? In any case I tried what you suggested and I can still upload files.

Thanks for the pointer. I am new to ondemand and I didn’t know this option to restart the web services. Very useful to know.

First - noone welcomed you, so let me do that now. Welcome!

Secondly - I think you actually want to take a look here and disable the file app altogether for some users by use of file access control lists on the Files app. This means that entire app is disabled for those users (upload, download and browse).

Or here where you can limit what directories are shown/available.

That said - you should know that Open OnDemand (OOD) respects the underlying file permissions. That is users using OOD who can’t see restricted files in a shell due to permissions and so on, won’t be able to view the files in the web through OOD either. OOD does not give privilege to the users they don’t already have. Indeed it runs as the user with their UID and GID(s). So if they for example can’t write to a directory through a shell - they won’t be able to upload the file through OOD.

So the whole issue may be moot if the files you’re restricting are indeed restricted to those users.

We at OSC have protected data locations (for HIPPA data and so on) and they’re access limited through group permissions along with being monitored for access & modification.

An ood server reboot will restart everything. The “restart services” restarts your account’s nginx instance which is handy when you’re testing but don’t want to do a server reboot… Depending on limits you’re trying to achieve, the /etc/ood/nginx.yml file may offer other settings. For example, see the block for “nginx_file_upload_max” in that file.



Thanks for the warm welcome @jeff.ohrstrom :slight_smile: I really like the application and also the great support I found in these forums

@azric I tried to set the variable you suggested but still no luck. Its seems the max upload size is not being applied. This is what I tried:

[root@demo-open-ondemand ~]# grep nginx_file_upload_max /etc/ood/config/nginx_stage.yml
nginx_file_upload_max: '0'

@jeff.ohrstrom Your suggestion is perfect for our use case. After doing chmod 700 /var/www/ood/apps/sys/files/ the Files app is no longer visible in the webui which is exactly what I needed. Actually I can adjust permissions so only members of group of “data-managers” can access the Files app in the webui, which is perfect for our use case.

Try ‘1’; it wouldn’t be the first time a value of 0 meant infinity to an application…

If that doesn’t work, I’m out of ideas…


Hi, I’m Iñaki, Pablo’s coworker,

@azric the option to set the value to 1 works as it limits the upload to 1B

@escobar @jeff.ohrstrom I did a check on the apps filtering and although changing the permissions to say 700 for the /var/www/ood/apps/files and /var/www/ood/apps/file-editor folders, ood will hide the apps from the dashboard however you can still access those by directly entering their url: works as expected and I don’t see the option for Files, but if I edit the url to I end up in the Files app:<path/to/my/home>, I can then even edit files.

Is there something else that should be configured? or maybe this does not work for the main apps? I can imagine disabling the files app might break the myjobs app at least?


Hi and welcome @i-mtz

We should not be making the routes at all if you can’t read these files. This should be all you need to do. You may have uncovered a bug.

Ah you are right, if I also change the permissions of manifest.yml then the url leads to a Not Found message. So it seems that the issue is with:

So the check bypases the folder permissions and just checks the target file I think, I did a quick test by changing the line to: && app_dir.readable? && app_dir.join('manifest.yml').readable?

And it seems to do the trick, but I’m not sure if this is the proper fix…

Yea that’s what I’d do. I’ll put the same fix upstream, thanks!

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.