Yesterday I've installed a fresh CentOS 7 VM with Apache, MySQL and PHP 7.0.17.
After that, I installed composer and all other required php-packages.
Then I followed this guide to install Firefly-iii : https://firefly-iii.github.io/using-installing.html.
So far so good. The database is migrated and seeded from the php artisan migrate command.
Now the problem, when I try to access the application from the browser, a 500 error appears. No log rules, nothing.
Alright, this might be an permissions problem. I have changed the owner to apache:apache, no result. Set the storage and bootstrap/cache folder to 777 no result.
Alright... What now. Ah, maybe the user or usergroup is incorrect. I've copied my public/index.php and built in some try catch statement (still no log).
When I open the application in the browser finally some result is returned.
This try/catch:
try {
$response = $kernel->handle(
$request = Illuminate\Http\Request::capture()
);
} catch (Exception $e){
echo $e->getMessage();
echo '<br/>';
echo 'User: '.exec('whoami');
echo '<br/>';
echo 'Group: '.exec('groups');
echo '<br/>';
}
returns the following result:
The stream or file "/var/www/html/application-folder/storage/logs/application-name-2017-04-06.log" could not be opened: failed to open stream: Permission denied
User: apache
Group: apache
After this message I've created the /var/www/html/application-folder/storage/logs/application-name-2017-04-06.log file and changed the permissions to 777.
Here is a little piece of my bash history :
[user#16 logs]$ sudo chmod 777 firefly-iii-2017-04-06.log
[sudo] password for user:
[user#16 logs]$ ls -l
-rwxrwxrwx+ 1 apache apache 5 Apr 6 14:18 firefly-iii-2017-04-06.log
[user#16 logs]$ chmod 777 firefly-iii-2017-04-06.log
chmod: changing permissions of ‘firefly-iii-2017-04-06.log’: Operation not permitted
This error messages is still returning and at this moment I've no idea what else I can try to fix this problem.
Does anyone knows a solution or has anybody else expecting this strange behavior?
Please help me, I am completely stuck at this moment and don't know what to do now and how I can solve this problem.
After a little bit of search yesterday I've found this answer : https://stackoverflow.com/a/37258323/1805919
I've tried it on my own server, and at this moment the application is accessible trough the browser.
Prove this is the problem by turning off selinux with the command
setenforce 0
This should allow writing, but you've turned off added security
server-wide. That's bad. Turn SELinux back
setenforce 1
Then finally use SELinux to allow writing of the file by using this
command
chcon -R -t httpd_sys_rw_content_t storage
And you're off!
First of all your server has to be in owner group of application path.
Second you have to set permissions to storage folder. Here is an example how to set permissions on *nix systems:
sudo chmod -R ug+rwx storage bootstrap/cache
Have you tried setting a new application key? Have you also ran your migrations and created the database for the application?
Related
I have a Joomla site that the files is owner by root:root. But this way I can't update or install any plugins on Joomla. However when I set de folder's site to the apache owner the site downs return ERROR 500.
How could I fix it?
I've tried set apache owner end set the permissions like below:
chown apache:apache /var/www/html/site
chmod -R 755 /var/www/html/site
Ps.: The site was migrated from another server where the owner of the files is the apache.
Simply run apachectl -S as root or sudo (sudo apachectl -S) and look at the lines which tell User and Group owner.
Other solution, typing the command ps faux will tell you what you need at first column the owner of the process you want to know about.
Also, htop command could help you as same as before if it is installed.
EDIT :
you can also specify -R to do recursive with chown command
I found out the solution. Was just the permissions on files the problem. I don't know why, but when I moved the files of site to another server the folders change the permissions 755 to 655. Changed this permissions everything cames back to normal.
Thanks again!
I am pretty new at php and ubuntu. I have 2 servers set up, one for development and one for staging. On the dev machine I can use the at command without a problem, but on staging I get a permissions error. The at.deny (and at.allow) files are identical, so it must be another permissions issue.
Any clues?
I see that on the staging server I can only use at command as root. How can I fix this to be able to use the at command as www-data? Again... I checked the at.allow and at.deny files ... they are not the problem here.
1) Check if you have file /etc/at.allow.
If it exists - just add your user in new line.
If not exists - try to find your user in /etc/at.deny and remove/comment it.
2) Restart "at" daemon:
sudo atd restart
3) Check:
at -l
or
sudo -u myuser at -l
The error should not be output.
this is what I am doing:
Creating a new server on Linode. OS is centos 6.5
Logging in as root
running the following script to add a user called shortfellow which does not have a password.
The script is:
#!/bin/bash
yum -y update
adduser shortfellow
mkdir -p /home/shortfellow/.ssh
echo "ssh-rsa REALLYLONGSSHPUBLICKEY shortfellow#example.io" >> /home/shortfellow/.ssh/authorized_keys
chmod -R 700 /home/shortfellow/.ssh
chown -R shortfellow:shortfellow /home/shortfellow/.ssh
su - shortfellow
exit
The problem is that first time when I try to ssh into the system. It does not work at all. It simply asks for the password. I hit ctrl + c and try to ssh again as the same user, it works.
this behaviour is really annoying because I am writing code to create the server programmatically and it does not work because of this silly issue.
Does anyone have any idea why this might not be working as expected?
I did /sbin/mkhomedir_helper shortfellow in the script before the exit and it works correctly after that.
I guess the issue was really that the home directory for a user is created only at login and when I tried to programmatically create this user this would not happen for some reason.
I uploaded ajaxplorer "pydio-core-5.0.4.zip" to my server and after I extracted files into a folder in the server i request the folder to starting install but i get this message :
"Impossible write into the AJXP_DATA_PATH folder: Make sure to grant write access to this folder for your webserver!"
i made the folder : /data permissions to 777 and it did not make change ..
any solve ?
I'v got the same problem few hours ago.
The problem:
You put full permissions (777) to the data folder, but subfolders don't get it.
The solution:
sudo chmod -R 777 data
sudo chmod -R 777 data
or
sudo mkdir -m 777 your_pydio_path/data/tmp/sessions
I know this is old, but I was having the same issue with pydio-core-6.0.8. Also, I'm going to preface this by saying that I am a php noob. But I was able to resolve my issue without a chmod 777 command. Instead, I made the nginx user the owner of the data directory.
chown -R nginx /path/to/pydio-core-6.0.8/data
And then made sure that php-fpm was running as the nginx user with the two php-fpm.conf settings
listen.owner = nginx
user = nginx
After restarting php-fpm, I was able to load the pydio page which went into the startup wizard.
This command is so easy! But it's dangerous!
Go to /var/www/pydio for apache2 or /usr/share/nginx/html/pydio for nginx and try:
chmod ugo+x data
It's more protected!
I have set up a Linux Server and installed Apache and SVN and dav_svn on it. Now, when I try to upload to https://x.x.x.x:x/svn/repo with Tortoise SVN I get
Can't open file '/server/svn/repo/db/txn-current-lock': Permission denied
I have Set up my SSL correctly (I can checkout, no problems, even remotely due to Port Forwarding).
I'm guessing this has to do with the Linux Ownership of the Repository folders, How must I set this/ what are the commands?
This is a common problem. You're almost certainly running into permissions issues. To solve it, make sure that the apache user has read/write access to your entire repository. To do that, chown -R apache:apache *, chmod -R 664 * for everything under your svn repository.
Also, see here and here if you're still stuck.
Update to answer OP's additional question in comments:
The "664" string is an octal (base 8) representation of the permissions. There are three digits here, representing permissions for the owner, group, and everyone else (sometimes called "world"), respectively, for that file or directory.
Notice that each base 8 digit can be represented with 3 bits (000 for '0' through 111 for '7'). Each bit means something:
first bit: read permissions
second bit: write permissions
third bit: execute permissions
For example, 764 on a file would mean that:
the owner (first digit) has read/write/execute (7) permission
the group (second digit) has read/write (6) permission
everyone else (third digit) has read (4) permission
Hope that clears things up!
It's permission problem. It is not "classic" read/write permissions of apache user, but selinux one.
Apache cannot write to files labeled as httpd_sys_content_t they can be only read by apache.
You have 2 possibilities:
label svn repository files as httpd_sys_content_rw_t:
chcon -R -t httpd_sys_content_rw_t /path/to/your/svn/repo
set selinux boolean httpd_unified --> on
setsebool -P httpd_unified=1
I prefer 2nd possibility. You can play also with other selinux booleans connected with httpd:
getsebool -a | grep httpd
I also had this problem recently, and it was the SELinux which caused it.
I was trying to have the post-commit of subversion to notify Jenkins that the code has change so Jenkins would do a build and deploy to Nexus.
I had to do the following to get it to work.
1) First I checked if SELinux is enabled:
less /selinux/enforce
This will output 1 (for on) or 0 (for off)
2) Temporary disable SELinux:
echo 0 > /selinux/enforce
Now test see if it works now.
3) Enable SELinux:
echo 1 > /selinux/enforce
Change the policy for SELinux.
4) First view the current configuration:
/usr/sbin/getsebool -a | grep httpd
This will give you: httpd_can_network_connect --> off
5) Set this to on and your post-commit will work with SELinux:
/usr/sbin/setsebool -P httpd_can_network_connect on
Now it should be working again.
for example on debian
sudo gpasswd -a svn-admin www-data
sudo chgrp -R www-data svn/
sudo chmod -R g=rwsx svn/
I just had this problem
Having multiple user using the same repo caused the problem
Logout evey other user using the repo
Hope this helps
In addition to the repository permissions, the /tmp directory must also be writeable by all users.
3 Steps you can follow
chmod -R 775 <repo path>
---> change permissions of repository
chown -R apache:apache <repo path>
---> change owner of svn repository
chcon -R -t httpd_sys_content_t <repo path>
----> change SELinux security context of the svn repository
Try to disable SELinux by this command /usr/sbin/setenforce 0. In my case it solved the problem.