I can't access my files on the network via RStudio unless I'm connected via Ethernet cable at work.
I have this problem with the two latest versions of Rstudio: 2023.12.1+402 and 2023.12.0+369;
If I install one of the above mentioned versions of Rstudio while connected to my workplace Ethernet everything works fine and the standard Working Directory is set to "\storage.COMPANY.xx\Home$\USERNAME\My Documents" (like it is supposed to be) and I can access all my files from within RStudio no problem.
If however I instead at the company connect via their Wifi or am working from home RStudio only allows access to files on the C: harddrive and trying to open or save something to my network folders (where everything is located) I get an error saying "the system cannot find the file specified." or something similar depending on what you try to do.
The Working Directory is also set to "C:\Users\USERNAME\Documents" which is empty since we always work against the company network file system (\storage.COMPANY.xx...)
I've tried everything I can think of like using setwd() , changing the default working directory in Global Options, opening my Rproject files that are all on the network drive but RStudio still refuses to open or see anything that is not on the C: drive.
If I install the earlier version of RStuidio (2023.09.1) everything works as it always have done before.
Can anybody help me figure out how to get the newer versions of RStudio to work even when working without direct Ethernet connection to the company server. It should work without any connection at all (like all other programs do), everything then just gets synced with the server when there is a connection again.
Hi,
No that does not seem to work either for files or for folders; RStudio doesn't show the links so I can't use them. Even if I could get that to work I would have to link hundreds or thousands of files (precisely everything I work with since it is all in this synced network with my AD\ windows user on this company setup)
I don't think a linked folder to my normal network root could work either, I think it would break all paths in my code, both relative and explicit ones.
I think there might be a problem how these versions of RStudio handles '~' as root folder.
I just looked at a Rproject I had left open when I left work and I now get this error:
Warning message:
File monitoring failed for project at "~/Projekt/PROJECTNAME"
Error 2 (The system cannot find the file specified)
Features disabled: R source file indexing, Diagnostics
Where ~ clearly before meant My Documents on my network user but now it has changed to be My Documents on the C: drive.
Yes, It's the same. It is also the same if I work completely offline. I'm not sure how these Microsoft AD user accounts work but it all looks the same for me as a user (everything under my user, like Desktop and Documents, is always under "\Storage.COMPANY.XX$Home\USERNAME...." and then it is just synced to the real server when on the network.
The file system in RStudio is a bit funky. I'm on Linux, but I suspect it's the same on Windows. The default working directory, unless I change it or open a project, is my home directory. The Files tab can see all directories under my home, but by default it cannot see system directories. I can override that, though, as follows. Let say I want to work in my system's /tmp directory (which is initially not available in the Files tab). In the Console, I execute setwd("/tmp"). In the Files tab, I click "More" and click "Go to working directory". The Files tab now shows the /tmp directory.
If you run setwd("\Storage.COMPANY.XX$Home\USERNAME....") in the Console, can you access your work files?
I found a hack on Linux that will let me set any directory as the default starting directory. There's a decent chance it will work on Windows too. The straightforward approach (Tools > Global Options ... > General > Basic > R Sessions) does not work, as the browse button will not look out side the tree rooted at ~. What works for me is to go to the configuration directory (~/.config/rstudio on Linux and OS X, %appdata%\RStudio on Windows), open rstudio-prefs.json in a text editor, and change the value of the "initial_working_directory" entry.
Unfortunately this doesn't work for me; RStudio still says that the starting working directory is under C:\Users... and I'm not allowed to open* any files under My Documents or Desktop, just files on C:.
*What I can do is run setwd("\Storage.COMPANY.XX$Home\USERNAME....") in a script or the console and run R-code with these paths, i.e. R works but RStudio wont allow me to open any scrips/files or projects outside of the C: drive, nor can I via RStudios file explorer navigate to \Storage.COMPANY.XX$Home\USERNAME....
Well actually that wasn't quite true, I've just tried and apparantly I'm allowed to access other network drives just fine but cannot access my user documents/file system so it is not really locked to C: but won't recognize this AD user home directory at all.
Just to be clear, if you run setwd("\Storage.COMPANY...") in the console pane of RStudio, the command succeeds (no error message, getwd() yields the expected result)? If yes, what happens when you go to the Files pane and click "More > Go To Working Directory"? Does the Files pane show the contents of the correct directory?
Yes, if I run setwd("//Storage.../...") I get no error messages.
Then running getwd() it has changed the initial two '//' to four '\\\\' which is apparantly how it wants it formatted (and twice as many because of the whole '\ ' being an escape character in a string) [Edit: had to add extra '\' here again because of the same reason ]
It clearly seems to work as it should here because if I while standing inside read.file("") press tab it will start listing the files/folders under the set wd.
Clicking the "Go To Working Directory" in the file pane gives me the following error:
Error navigating to //storage.(full path here) :
The system cannot find the path specified
Again everything works fine if I install the older version of RStudio, I was really hoping that there was some sort of new setting or something that could just be adjusted to make it work in the newer versions but so far nothing. Perhaps it's a bug of some sort..?
Edit:
Also works for traditional file servers within our network like setwd("//gis.COMPANY/data") and I can then press "Go To Working Directory" and it gets listed without a problem. It is just my Windows AD user account that I cannot access so there must still be some sort of conflict in '~ ' being different things for RStudio and for my WIndows AD user somehow(?).
The fact that setwd() works (and list.files() and read.file() confirm the files are accessible) does suggest that the failure of the RStudio file pane to let you see and load the files is a bug. I doubt it's caused by any problem with the ~ shortcut. I would suggest filing a bug report.
You could try invoking setwd() in the console using the Microsoft version of the path, with the plethora of backslashes (\) rather than forward slashes (/). Then try "Go To Working Directory". It will likely fail, but who knows?
We discussed a symlink before, but it might be worth trying one more time. Specifically, I would start by creating a link C:\Users\USERNAME\Documents\companydrive connected to \storage.COMPANY.xx\Home$\USERNAME\My Documents (or whatever the correct path is to the remote documents directory. By making the link to the parent directory rather than to individual documents, you won't have to change the link when changing documents. With the link in place, run `setwd("C:\Users\USERNAME\Documents\companydrive") in the RStudio console and, if that works, try "Go To Working Directory". Since the working directory path looks like a local directory, maybe, possibly, RStudio will be able to digest it.
Yeah, I've tried all combinations of backslashes and forward slashes in the paths, the ones that get accepted all end up looking the same when I run getwd() (and all dont't work for RStudio).
I'll try filing a bug report, possibly waiting to see if the error still remains in the new version that I think(?) should be released soon.
I will also try a bit more with symlinks as you suggested when I get a bit more time, possibly next week.
]