41

I just updated to R (3.4.1 "Single Candle") on my Linux Mint 18.1 Cinnamon machine and I attempted to install a package. R returned the following:

> install.packages('ggplot2')
Installing package into ‘/usr/local/lib/R/site-library’
(as ‘lib’ is unspecified)
Warning in install.packages("ggplot2") :
  'lib = "/usr/local/lib/R/site-library"' is not writable
Would you like to use a personal library instead?  (y/n) y
Would you like to create a personal library
NA
to install packages into?  (y/n) y
Error in install.packages("ggplot2") : unable to create ‘NA’

I have encountered the 'lib not writable' output before but typically it offers a solution like this one:

Would you like to create a personal library
~/R/x86_64-pc-linux-gnu-library/3.4
to install packages into?  (y/n) y

Any ideas why the personal library is suggesting NA? Is there a way to manually override this?

JForsythe
  • 738
  • 1
  • 6
  • 12
  • 3
    See here: http://bugs.debian.org/866768 – Dirk Eddelbuettel Jul 01 '17 at 20:41
  • Same problem on Ubuntu 16.10. – Robert McDonald Jul 01 '17 at 20:54
  • Will there be an 'official' fix for this? – Kun Ren Jul 04 '17 at 01:57
  • See this mail thread as well https://stat.ethz.ch/pipermail/r-sig-debian/2017-July/002726.html – zeehio Jul 04 '17 at 07:28
  • 1
    Based on @DirkEddelbuettel 's comment the solution is to make `usr/local/lib/R` writable, *not* to reinstate a personal package library by uncommenting lines in `Renviron`. – Phil Jul 04 '17 at 10:19
  • 1
    Yes. Strictly speaking both work and are personal preferences; I like making `/usr/local/lib/R/site-library/` writeable better. But reinstating the user-local library may be easier for non-admin types. – Dirk Eddelbuettel Jul 04 '17 at 13:04
  • Still prefers default behavior where user library is independent from each other so that an upgrade of package from one user would not make others break – Kun Ren Jul 05 '17 at 06:49
  • The workaround requiring non-admin users to update .libPaths() e.g. in .Rprofile to be able to install packages without admin intervention might is a (small) annoyance in some contexts. At least compared to the previous default. – Torsti Jul 06 '17 at 10:21
  • See also: https://mobile.twitter.com/henrikbengtsson/status/882386074839924736 – Kun Ren Jul 07 '17 at 04:54
  • @DirkEddelbuettel can you please elaborate a bit on why is your preferred solution better than reinstating the user-local? For us, non-admin types. – jakub Jul 07 '17 at 21:35
  • 1
    I already explained that in a few other places. In any event, the R 3.4.1-2 package reverts to the old behaviour. – Dirk Eddelbuettel Jul 08 '17 at 03:35

6 Answers6

12

I don't know what's causing this problem (i'm also experiencing it on Ubuntu 16.04), but here's a quick workaround:

.libPaths(c("/home/your_username/R/x86_64-pc-linux-gnu-library/3.4/", .libPaths()))

Of course, you can replace "/home/your_username/..." for any another directory (that will store your personal library).

This solution makes install.packages() and library() work. Waiting for a full fix!

EDIT: I should note that this solution is not persistent. That is, it won't last after restarting R. You can fix this by adding the same line of code described above to the /home/your_username/.Rprofile file.

arcruz0
  • 153
  • 7
  • This lets me install packages and even load them and use them interactively, but when I try to build something, it shouts: `Error in loadNamespace(name) : there is no package called ‘devtools’` - even though I have it in the user library, and it is loaded while this command is run. – jakub Jul 02 '17 at 16:01
  • It's works temporary, when restart system, is needed do this again. – Marcus Jul 04 '17 at 15:12
  • Also, if that directory doesn't yet exist, you will have to create it first. – Erin LeDell Jul 28 '17 at 01:58
12

Looking at the details in @Dirk 's comment (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866768) this is a planned behaviour so that packages are installed once for all users of the system.

The solution is to make /usr/local/lib/R/ writable for all users, rather than to re-instate the old behaviour of having a personal package library for every individual user.

Open up a terminal and:

  • Navigate to /usr/local/lib/ with cd /usr/local/lib/
  • Change the owner:group so that all users can write to the folder. I happen to have a group on my computer that all users are a member of, so I used that, but see https://askubuntu.com/questions/66718/how-to-manage-users-and-groups for help with setting up a group if necessary
  • To change ownership use sudo chown owner:group -R R/. owner is an any user, it doesn't really matter. group is the key one; make sure anyone wanting to use R on your system is a member of this group. -R is recursive (i.e. do it to all files and folders in R/).
  • If you need to change group permissions, use chmod -R 775 R/. This gives the owner and group read, write, and execute permissions, and gives all others read and execute permissions.

Now restart R and you should be able to install packages to your this shared location.

zek19
  • 642
  • 6
  • 9
Phil
  • 3,936
  • 1
  • 20
  • 31
10

My solution was the following:

In the file /usr/lib/R/etc/Renviron there is a configuration of R.

In lines 43-45 there is:

# edd Jun 2017  Comment-out R_LIBS_USER
#R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/3.4'}
##R_LIBS_USER=${R_LIBS_USER-'~/Library/R/3.4/library'}

I have uncommented R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/3.4'}, restarted RStudio and now it works.

EDIT: Looking at the comments, it seems like a planned behaviour. Here is another solution.

potockan
  • 3,558
  • 3
  • 18
  • 32
3

After July 8, 2017 this will resolve all problems

sudo apt-get update
MYaseen208
  • 19,213
  • 32
  • 133
  • 260
0

May be this is a bug of R 3.4.1, and my solution is change the line of 

R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}

in /etc/R/Renviron file into 

R_LIBS_SITE=${R_LIBS_SITE-'~/R/x86_64-pc-linux-gnu-library/3.4.1:/usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library'}
luchonacho
  • 5,255
  • 3
  • 27
  • 41
zefeng wu
  • 1
0

The same happened to me while running the installation procedure for some Bioconductor packages.

Then I realized also I could write this (or similar) on the bash command line:

export R_LIBS_USER=$HOME/R/x86_64-pc-linux-gnu-library/3.4 && R

or

export R_LIBS_USER=$HOME/R/x86_64-pc-linux-gnu-library/3.4 && rstudio

and then run upgrade.packages() (or install.packages(), or biocLite()) inside R.

This way the change is temporary, and you don't have to update any config files.

This shell command is useless if subsequently a command in .Renvironor.Rprofile` sets R_USER_LIBS to a different location during R startup (-check your configuration).

Sticking with in $HOME/R/x86_64-pc-linux-gnu-library/3.X can be desirable if you have already lots of packages in this location, you want them upgraded/installed there. I have lots of Bioconductor packages in there, and I don't want them to download again, some of these packages download huge "Omics" datasets when used. Maybe the partition where /usr/local/lib/R resides has too little disk space or is on a slow drive.

knb
  • 8,442
  • 4
  • 54
  • 75