Filling up the home directory with RStudio Server



Your home directory can fill up as a result of large amounts of session or project data being written to file. The home directory is part of your server’s file system or it is mounted to it from a network file system. The home directory is essential in managing user configuration files and maintaining a consistent experience across the network. When the home directories fill up the system ceases to function properly.


RStudio Server uses the home directory as the default location for configuration files and project files. There are typically two causes for filling up the home. The first is when users write large project files to home. The second is when large sessions timeout and RStudio Server automatically writes sessions to home.

  • Project files written to home. Most analytic projects require temporary scratch space and on-going project space. One feature in R is to save your workspace as an .RData file so that you can restore your workspace at some later date. RStudio Server gives you the option set the default (always/never/ask) when saving and restoring your workspace. By default new projects are started in home and thus .RData files are often written to home.
  • Suspended sessions. RStudio Server comes with a feature to save suspended sessions by default. When a session exceeds the timeout it is automatically written into the .rstudio directory which is stored in home.

The .rstudio directory

All of the information pertaining to the configuration and management for a specific user is contained in the .rstudio directory. This directory contains a lot of useful information, such as your global settings, your code history, addins, etc. It also contains all your session information including the number of sessions and active state. Session information also includes suspended data.

The .rstudio file has two essential types of information. The first is settings and configurations. These are used for the operation of RStudio Server. The second is suspended data which includes live data from your analysis that is written to file when a session is suspended.

Recommended solutions

We recommend minimizing the amount of data written to home and maximizing the amount of home space available.

Turn off the session time out

You can turn off the session timeout by setting session-timeout-minutes to zero minutes in the /etc/rstudio/rsession.conf file.


Turning off the session timeout will prevent RStudio Server from automatically writing the session data to the home directory. If you are dealing with large amounts of data or a large number of sessions, turning off the session timeout could save a lot of space in your home directory. The session timeout setting can optionally be specified at the user or group level by adding session-timeout-minutes to the /etc/rstudio/profiles file.

Automatically delete unused sessions

As an administrator, you have the ability to automatically suspend sessions to disk after a certain period of inactivity by specifying the session-timeout-minutes option in /etc/rstudio/rsession.conf. RStudio Server Pro v1.1 adds the ability to also kill and delete these sessions entirely after a certain amount of hours, freeing up valuable system resources. Simply add the following line to /etc/rstudio/rsession.conf.


This setting will kill and delete any inactive sessions that have not been used for the specified hours. You should set a long timeout period to ensure that only sessions users have forgotten about or no longer need are deleted, as the session’s data is lost forever. Again, for more information, see the RStudio Server Pro Administration Guide.

Turn off the default save action

Be default, R asks you whether to save workspace to file. Admins can turn off the default save action for projects in the /etc/rstudio/rsession.conf file.


Start new projects outside of home

You may want to start new projects in some other location outside of home. This can be done by specifying the project path in the new projects dialog box. Server administrators can select a default location for new projects by configuring the /etc/rstudio/rsession.conf file. 


Use the system library [optional]

You might consider putting commonly used packages into the system library in order to dissuade users from duplicating package installations in home. However, this approach requires additional admins to reinstall updated packages into the system library every time a new version of R is installed on the server. The extra effort in administration might not justify the amount of space saved. 

Increase the available space in home

RStudio Server Pro relies heavily on the home directory for its regular operation. If there are relatively few R users, then getting a little more space for these users makes a huge difference. Getting more space on home is the easiest way to ensure a good user and admin experience on RStudio Server Pro.

Other solutions

Moving the .rstudio directory

Warning: The following solution is not supported. If you move .rstudio to a new location it could potentially produce unexpected results. We recommend storing .rstudio in your home directory.

If you are filling up the home directory because of suspended sessions and you do not wish to turn off the session timeout, you can manually move the .rstudio directory to some other location. You first create a new target location and then move the .rstudio under the target. Then create a symlink between the old and new locations.

$ TARGET=/tmp
$ mv ~/.rstudio/ $TARGET/.
$ ln -s $TARGET/.rstudio/ ~/.rstudio

You will have to move each user's .rstudio directory separately or create a process to do so. When a new user logs in make sure to relocate that user's .rstudio directory also. Logins may fail if users do not have access to the correct directory.

Using local home

Alternatively, you can use the local home on the server itself (not mounted). There is typically plenty of space on local home for user files. The downside to this approach doesn't support load balancing or high availability. It also means that user profiles are unique to the individual server. This approach is really only useful for on server, and even then the user experience is compromised, therefore we don't recommend this setup.