I access my Google Drive via the terminal using gdfuse. There is a directory that exists, but I can't seem to access via the terminal:
I have a directory called 'papers'. Within that I want to access 'instructions'. When I do ls -ltr I see:
?????????? ? ? ? ? ? instructions
drwxrwxr-x 2 user user 4096 Jun 12 2017 my_docs
-rw-rw-r-- 1 user user 3923 Jul 25 2017 bs237-procedure.txt
with the word instructions appearing in red. And if I try to cd instructions I am told bash: cd: instructions: No such file or directory.
However if I use a browser to go into my Google Drive, I can access the directory 'instructions' and the files within it no problem.
I was searching and I reached this answer, hope it works for you!
To read a file, its read permission needs to be set. However, to read a directory and the listing of its files, both the read and the execute permissions need to be set. If they aren't, you get weird errors like the ones you're experiencing.
To set the read permission on files and the read and execute permissions on directories recursively, use this command:
chmod -R a+rX directoryname
and link to that page: https://askubuntu.com/questions/243999/why-do-question-mark-characters-appear-when-changing-the-permissions-of-director
edit : you can change the folder name, again I saw this on the internet and it seems to work!
Whenever I start my iterm terminal. I always get this message followed by prompt on my terminal.
Last login: Fri May 1 21:33:59 on ttys001
[oh-my-zsh] plugin 'zsh-syntax-highlighting' not found
[oh-my-zsh] plugin 'zsh-autosuggestions' not found
[oh-my-zsh] Insecure completion-dependent directories detected:
drwxrwxr-x 7 david admin 224 Apr 30 22:22 /usr/local/share/zsh
drwxrwxr-x 6 david admin 192 Apr 30 23:30 /usr/local/share/zsh/site-functions
[oh-my-zsh] For safety, we will not load completions from these directories until
[oh-my-zsh] you fix their permissions and ownership and restart zsh.
[oh-my-zsh] See the above list for directories with group or other writability.
[oh-my-zsh] To fix your permissions you can do so by disabling
[oh-my-zsh] the write permission of "group" and "others" and making sure that the
[oh-my-zsh] owner of these directories is either root or your current user.
[oh-my-zsh] The following command may help:
[oh-my-zsh] compaudit | xargs chmod g-w,o-w
[oh-my-zsh] If the above didn't help or you want to skip the verification of
[oh-my-zsh] insecure directories you can set the variable ZSH_DISABLE_COMPFIX to
[oh-my-zsh] "true" before oh-my-zsh is sourced in your zshrc file.
~
➜
What can I do so that it doesn't show all these above [oh-my-zsh] messages and I can go to direct prompt? Is there anything wrong I did while setting up [oh-my-zsh]?
It looks like you're trying to use plugins that are not installed. See the following documentation on how to install them:
zsh-syntax-highlighting
zsh-autosuggestions
(basically you want to clone the repos into $ZSH_CUSTOM/plugins and source them in your .zshrc, but see the documentation of each for actual commands to use. NOTE: zsh-syntax-highlighting must be the last plugin sourced.)
The other part of your question is answered in your terminal output:
To fix your permissions you can do so by disabling the write permission of "group" and "others" and making sure that the owner of these directories is either root or your current user.
It looks like the owner is already your current user, however your permissions are rwxrwxr-x, which are read, write, execute for users and group, and read, execute for others. From the warning message you should remove the write permission from group:
sudo chmod 755 zsh
now when you ls -l you should see rwxr-xr-x for that directory.
Do the same for the /usr/local/share/zsh/site-functions directory.
The warning message even gives you an alternative, suggesting you place the following in your ~/.zshrc file and restart zsh:
ZSH_DISABLE_COMPFIX="true"
Suggesting you place the following in your ~/.zshrc file and restart zsh:
ZSH_DISABLE_COMPFIX="true"
Put this on the top .zshrc file. It works for me.
ZSH_DISABLE_COMPFIX="true"
I was trying to move a RubyOnRails.txt file into a /RUBY directory, so for some reason I typed:
mv RubyOnRails.txt /Ruby"
And I got this error: mv: cannot move ‘Untitled Document’ to ‘/Ruby’: Permission denied
Obviously, I typed: sudo mv RubyOnRails.txt /Ruby
And then, I understood my error, the folder wasn't /Ruby, was /RUBY.
Now the file is gone, and I can't find it anywhere.
There is some way to find it or recover it?
The file isn't gone, it's just renamed to Ruby and it's in root directory of your system /
You can still move it where you want like that sudo mv /Ruby your_destination
I am attempting to install Drupal 7.34 on RHEL and I continue to run into issues with permissions on sites/default/files. I've searched all over for a solution, but nothing has helped.
Here are the steps I am taking (with root access):
In /var/www/html I execute: drush dl drupal to download Drupal.
I then follow Drupal's install instructions (from /var/www/html):
mv drupal-7.34/* ./
mv drupal-7.34/.htaccess ./
mv drupal-7.34/.gitignore ./
cp sites/default/default.settings.php sites/default/settings.php
chmod a+w sites/default/settings.php
chmod a+w sites/default
cd ..
chown -R apache:apache html
In the browser, I navigate to http://myhost/install.php. In the "Verify requirements" step of the install process I receive the following error:
The directory sites/default/files does not exist.
So, I take then take the following steps:
mkdir html/sites/default/files
chmod a+w html/sites/default/files
chown apache:apache html/sites/default/files
When I attempt the install process I now get the following error:
The directory sites/default/files is not writable.
What am I missing here? The sites/default/files directory exists and is writable. Any guidance is much appreciated.
The solution I applied was more of a work-around, but I ended up using Drush to handle the entire installation rather than using it to download Drupal and manually configuring it from there.
I still don't know the answer to this "simple" error but I do know that before adding users or granting full permissions to a group one must know the name of the user running (owning) httpd. This is not always www-data
Also - my sites/default/files -is- in fact writable as is the case for just about everyone who posts this question. There is something seriously wrong with Drupal's install that it has this issue, that it is so prevalent and not addressed adequately by the code maintainers. Searched about twenty responses to this "very simple" problem and still none of the suggestions work. Opened up permissions entirely, chown the drupal installation files to the httpd daemon (apache) and group (www in my case)
These fixed it for me:
chmod 777 sites/default
chmod 777 sites/default/setting.php
It turns out the 'chmod a+w...' commands in the docs were not enough - the 777 includes 'x', making the items executable as well as writable.
When attempting to run R, I get this error:
Fatal error: cannot mkdir R_TempDir
I found two possible fixes for this problem by googling around. The first was to ensure my tmp directory didn't contain a load of subdirectories - it doesn't and it's virtually empty. The second fix was to ensure that TMP, TMPDIR, and R_USER in my environment weren't set to non-existent paths - I didn't even have these set. Therefore, I created a tmp directory in my home directory and added it's path to TMP in my environment. I was able to run R once and then I got the fatal error again. Nothing was in the TMP directory that I set in my environment. Does anyone know what else I can try? Thanks.
Dirk is right, but misses a point: If /tmp is full, you can't create subdirectories there. Try
df /tmp
I just hit this on a shared server, where /tmp is mounted on it's own partition, and is shared by many users. In this particular case, you can't really see who's fault it is, because permissions restrict you seeing who is filling up the tmp partition. Basically have to ask the sys admins to figure it out.
Your default temporary directory appears to have the wrong permissions. Here I have
$ ls -ld /tmp
drwxrwxrwt 22 root root 4096 2011-06-10 09:17 /tmp
The key part is 'everybody' can read or write. You need that too. It certainly can contain subdirectories.
Are you running something like AppArmor or SE Linux?
Edit 2011-07-21: As someone just deemed it necessary to downvote this answer -- help(tempfile) is very clear on what values tmpdir (the default directory for temporary files or directories) tries:
By default, 'tmpdir' will be the directory given by 'tempdir()'. This
will be a subdirectory of the temporary directory found by the
following rule. The environment variables 'TMPDIR', 'TMP' and 'TEMP'
are checked in turn and the first found which points to a writable
directory is used: if none succeeds '/tmp' is used.
So my money is on checking those three environment variables. But AppArmor and SELinux have shown to be an issue too on some distributions.
Go to your user directory and create a file called .Renviron and add the following line, save it and reopen RStudio or Rgui or Rterm
TMP = '<path to folder where Everyone has full control>'
This worked with me on Windows 7
If you are running one of the rocker docker images (e.g., rocker/verse), you need to map a local directory to the /tmp directory in the container. For example,
docker run --rm -v ${PWD}/tmp:/tmp -p 8787:8787 -e PASSWORD=password rocker/verse:4.0.4
where ${PWD} for me is ~/devProjs/r, and I created a /tmp directory inside it, so that the container's /tmp is mapped to my ~/devProjs/r/tmp directory.
Just had this issue and finally solved it. Simply a windows permission issue. Go to environment variables and find the location of the temp folders. Then right click on the folder > properties > security > advanced > change everyone to full control > tick "replace all child object permission entries with inheritable permission entries from this object" > Ok > ok.
This will also happen when your computer is completely, utterly out of space. Currently, my Mac has 0 kb free and it's causing this error. Freeing up some space solved the problem.
Check for the user account with which you are launching the RStudio with. Now u check the TMP(System Environment variable) for its location. If the user who is launching RStudio has Write access for those directories you will not face this issue. Being said that you are facing this issue, all you have to do is to change the permissions for that user to have write access on those directories.
Running R on CentOS system and had the same issue. I had to remove all R folders from the tmp directory. Usually all R folders will be in the form of /tmp/Rtmp*****
so i tried to delete the folders from /tmp by running the below.
CD into /tmp directory and run rm -rf Rtmp*
R shell Worked for me afterwards
I had this issue, solution was slightly different. I run R on a linux server - it turned out for me R had made a whole load of tempdirs when running jobs with cron that had hung and not been cleaned up, clogging up the root /tmp directory with ~300 RtmpXXXXXX folders.
Using terminal access, I navigated to the /tmp folder did a recursive find/rm - deleting all of them using this command:
find . -type d -name 'Rtmp*' -exec rm -r -v {} \;
After this, Rstudio took a while to load up, but was once again happy and my scripts began to run again.
You will need the appropriate admin rights for this solution. And always be careful when running rm -r, especially with a find command, as it's easy to remove things unexpectedly.
When it comes to deleting tmp files, make sure that the tmp files are in the server or in local.
If its in the remote, 1st check for the df /tmp in the server or in the remote to see who uses more storage.
Then use rm(file_name)` to remove the files which cause the blocking.
If its in the remote, then use rm /tmp/(file_name)..
MOreover, you can also refer to https://support.rstudio.com/hc/en-us/articles/218730228-Resetting-a-user-s-state-on-RStudio-Server