I have spent numerous hours on an issue that has left me puzzled. I am attempting to install Drupal on Linux Redhat using apache, but it will not allow me to pass step 3 due to the fact that sites/default/files is not writable.
I have followed the instructions on Drupal's site, in their install.txt file as well as the instructions of others who have had the same error with no success.
I have granted permissions access all different ways root:root 777, root:apache 777, I have verified that apache is the user running the apache process and I am still stuck.
Note: I was able to complete the install on windows.
Any new ideas?
Okay, so after following directions from both official and non-official web sources, the one thing that was never instructed to do or try was to reboot the application AFTER making permission changes to the files directory. I tried it, and this solved the issue.
This is weird because I've never had to reboot an OS after making permission changes on a directory. Additionally I did restart httpd after each change thinking that would be sufficient. Hopefully this can help anyone else running Redhat 7 with the same issue.
Thanks, TH
I solved this problem by changing the security context of the directory "sites".
My Drupal core files are in: /var/www/html/drupal
Then I applied the command:
chcon -R -t httpd_sys_content_rw_t /var/www/html/drupal/sites/
Related
I am following the instructions to configure hadoop-2.0.0 cluster for installing Impala. In hdfs-site.xml, I add two properties "dfs.client.read.shortcircuit" and "dfs.domain.socket.path" (/var/lib/hadoop-hdfs/dn_socket).
But when I start the Hadoop cluster by start-dfs.sh, it fails to start datanodes. The log in datanode says that "failed to stat a path component: '/var/lib/hadoop-hdfs'". Then I create /var/lib/hadoop-hdfs manually, and start Hadoop cluster again. It fails again and log says that it's the permission problem about that directory. OK, fine. I change the owner of hadoop-hdfs from root to ubuntu (ubuntu is the machine username). Now it finally works normally.
I am just confused. Am I doing in the right way? Do we really need to create /var/lib/hadoop-hdfs by ourselves and change the permission or the owner of that directory? Or I missed some configuration setting?
I was running into similar problems using Cloudera Manager. It was an issue of trying to run in 'single-user mode' instead of using root. I think you are doing something similar with user ubuntu. Is this a clean install or are you upgrading / did you have a failed install last time?
I'm guessing you sudo-ed somewhere you should have run something as 'ubuntu'.
If you can make it work by manually setting permissions, go for it. I have a feeling there are lots of other files owned by root that should be owned byubuntu lurking about in your system.
Anecdotally, if there is no critical data in the server, I have found it is easier to very thoroughly remove any and all files from the old install and then reinstall fresh.
I was facing a similar issue with starting the datanodes. Then, I came across this link https://github.com/cloudera/Impala/wiki/Build-prerequisites, where it states that we need to create the /var/lib/hadoop-hdfs manually and set the appropriate permissions. This has also fixed my problem.
Make certain directory /var/lib/hadoop-hdfs/present is OK.
I just installed Symfony CMF (standard edition 1.1) on a Linux VPS running Ubuntu 13. Everything is installed without errors but I always end up with a permission problem regarding the /app/cache & /app/logs folder.
As far as I know I installed the CMF as user root and the frontend is using user www-data, The only way to get it working without problems is by using these commands;
sudo chown -R :www-data app
sudo chmod g+s app
sudo setfacl -dR -m g::rwX app
chmod -R 777 app
After that it works perfectly but I am sure that from a security point of view this is not the correct way to do this.
So, I hope that anyone who has experienced this problem can provide me with a secure and correct method of solving the /app/ permission problem.
If I need to provide more information or show some configurations, I will gladly provide it as I need to solve this minor issue that is blocking the launch of my project.
This is explained in detail in the symfony documentation. Note that for images, we use the Imagine bundle, so you also need to set permissions on web/media/cache.
Usually you do not want to do things like deployments or git checkout as root, but with a non-privileged user. It is a good idea to have the webserver run under a different user, so that it can not just edit PHP files, to limit the potential damage in case there is a security issue in the webserver or your application.
I've been stuck on a problem for two days now where the software I'm trying to install will not proceed unless I make a separate user which is non-root.
Keep in mind I'm a big linux noob and not very experienced with the OS.
I make a user called "smrtanalysis" in a group called "smrtanalysis".
I put him in the sudoers file.
I made a folder called smrtanalysis in my home/nick/ directory
I downloaded the software from the PacBio website and put the .run files into this directory I noted above.
I used chmod 777 and chown (to user smrtanalysis) on the directory
noted above, and the .run file
I logged into smrtanalysis user by su smrtanalysis, password, and typed
./smrtanalyis-2.2.0.133377.run
the file runs, but then aborts with the following error message:
We recommend running this script as a designated SMRT Analysis user
(e.g. smrtanalysis) who will own all smrtpipe jobs and daemon
processes.
Current user is 'root' (primary group: root)
Installing as 'root' is currently not supported Switch to the desired
user and restart the install. Aborting installation...
Here is the install documentation:
https://github.com/PacificBiosciences/SMRT-Analysis/wiki/SMRT-Analysis-Software-Installation-v2.2.0
It seems pretty straightforward but I can't seem to get it working. If you guys look at the install docs, you'll probably be able to tell me what I'm doing wrong.
Thanks for any help!
Regards,
Nick
change
SMRT_ROOT=/opt/smrtanalysis
on
SMRT_ROOT=/home/nick/smrtanalysis
the rest should be easy.
Be very careful installing binaries from internet, make sure you're confident in the source.
Just don't use root for that, you ran the script as root by accident.
(update: pacbio team can help from the github page at https://github.com/PacificBiosciences/SMRT-Analysis/issues as well.)
I am developing with Xampp for Linux and Tomcat (similar to Xampp on Windows). Many programs like /IDEA, Tomcat and Xampp are recommended to be installed under /opt Now I have heard that it is not recommended to run services as root, but on Ubuntu (I am using this) unpacking any directory to /opt implies that it belongs to root owner and root group. This may be specific to Xampp as per the instructions on their Linux page:
Step 2: Installation After downloading simply type in the following commands:
Go to a Linux shell and login as the system administrator root:
su
Extract the downloaded archive file to /opt:
tar xvfz xampp-linux-1.8.1.tar.gz -C /opt
Warning: Please use only this command to install XAMPP. DON'T use any Microsoft Windows tools to extract the archive, it won't work.
Warning 2: already installed XAMPP versions get overwritten by this command.
That's all. XAMPP is now installed below the /opt/lampp directory.
* Step 3: Start To start XAMPP simply call this command:
/opt/lampp/lampp start
Placing it here implies that Apache must be run as root as one is only able to run it with sudo on Ubuntu.
This may be an issue specific to Ubuntu. Is it? Because Xampp is a development tool I posted this here as I am more likely to find an appropriate answer here from developers who use it on Ubuntu (and other Linux systems). I would appreciate any information on if the same problem occurs on other systems, I notice my production environment has Tomcat installed in /opt too, but belongs to tomcat: tomcat
The question here is how to get around this for all tools under /opt, because even though Xampp may not be the tool for my needs, I still want to place Tomcat under /opt to replicate my production environment and the same thing will surely happen unless this is just a Ubuntu issue?
Ubuntu and some other distributions differ to the general Linux principle where the account that you create upon install of the OS is added to specific groups that can be viewed with the following command:
groups username
You will notice that root is not amongst these. It is also not possible to log in or su to the root account. sudo is most likey a command that has been granted permission to be used from other accounts so I imagine the 'sudo' command has a file permission of 775 for user: root:root
Thus launching services from /opt' does not run them asroot`
Am currently working on a CouchDB project, and have recently decided to switch to a Linux environment for development as I plan to deploy on a Linux server.
I was hoping to copy over my .couch files straight from - Program Files/Apache Software Foundation/CouchDB-1-1-1/var/lib/couchdb - and paste them directly into what I guess should be - var/lib/couchdb - But I keep running into file/folder permission errors each time I try to access var/lib/couchdb.
Is it even possible to transfer .couch files in the way I envisage?
...
Update - Follwing up on Dominic's comments, I managed to apply the fix found in the answer below.
After some investigative work, I found it to be a permissions error, exactly as Dominic Barnes had suggested in the comments...
The issue is also discussed here - Staging setup with couchdb
To fix it, I first ran;
sudo chmod -R 755 var/lib/couchdb
I may have also changed the permissions on the relevant parent folders too. I was then able to copy my .couch files into var/lib/couchdb/COUCH-VERSION-NUMBER. After doing that, I then had to use chmod to set favourable write permissions on the newly copied files, but also had to run:
sudo chown couchdb var/lib/couchdb/COUCH-VERSION-NUMBER/
To open those files up to the user group (the "couchdb" group) that the couchdb installation sets up for internal use (I think...). After that, I restarted couchdb, forcing it to stop with:
ps -U couchdb -o pid= | xargs kill -9
and restarting with:
/etc/init.d/couchdb start
After that, everything seemed to work as expected.
Hope that helps anyone else running into the same problem.