It has been asked a lot of times here, and none of the answers have worked so far for me.
I'm getting the folowing error on apache error_log
could not begin a transaction [500, #13]
Can't open file '/var/www/svn/repo/db/txn-current-lock': Permission denied [500, #13]
when trying to do
svn import -m "Initial" /mnt/logs/ http://localhost/svn/repo/
Info on that file:
ls -l /var/www/repo/db/txn-current-lock
-rwxrwxrwx. 1 apache apache 0 abr 20 12:37 /var/www/svn/repo/db/txn-current-lock
I'm running on CentOS 7.2 and I can access http://localhost/svn/repo tho there's only this there:
repo - Revision 0: /
After fighting with permissions, I decided to just look again at the "howto" and solved the issue. I basically forgot to type:
chcon -R -t httpd_sys_content_t /var/www/svn/repo
chcon -R -t httpd_sys_rw_content_t /var/www/svn/repo
Hope it helps someone else.
Related
I am attempting to run a laravel app on a local server in https mode in a Fedora 36 OS, but I am given this message
The stream or file "/var/www/compagnon-be/storage/logs/laravel.log"
could not be opened in append mode: Failed to open stream: Permission
denied The exception occurred while attempting to log
It seems to me that my permissions are correct
My DocumentRoot is /var/www/compagnon-be/public
I used these commands from /var/www
sudo chown -R $USER:apache compagnon-be
and
sudo chmod -R 775 compagnon-be
ls -l returns this (muser being my user)
[jaaf#localhost www]$ ls -l
total 12
drwxr-xr-x. 2 root root 4096 17 juin 13:13 cgi-bin
drwxrwxr-x. 14 muser apache 4096 2 déc. 06:32 compagnon-be
drwxr-xr-x. 4 root root 4096 1 déc. 06:52 html
[jaaf#localhost www]$
What is wrong ?
The trouble was coming from selinux.
I tried
sudo restorecon -R -v /var/www/compagnon-be
After that the message changed to
file_put_contents(/var/www/compagnon-be/storage/framework/views/dc2fe5ffc0c4db448244e2a441f79c65b3812ff5.php):
Failed to open stream: Permission denied
Then I decided to install setroubleshoot package in my Fedora distribution and launched sealert
Refreshing the page triggered an alert and sealert gave me the commands to use
It was:
Vous devez modifier l'étiquette sur (You must change label on) « /var/www/compagnon-be/storage/framework/views »
# semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/compagnon-be/storage/framework/views'
# restorecon -v '/var/www/compagnon-be/storage/framework/views'
I had tried a change the permission as the permission as the error body says it's a permission issue but when i applied the solution still got the same error.
Prestashop installation needs to write critical files in the folder var/cache.
please review the permissions on your server.
I tried:
https://stackoverflow.com/a/59981507/12717902
chown -R apache:apache /var/www/html/prestashop
But this didn't work for me
environment : Centos 7 | prestashop 1.7.7.1 | php 8.1.8 | mysql
this is a solution i've been looking for everywhere on the net i wanted to post the solution i found somewhere on Stackoverflow here which wasn't voted enough hope this will help more people.
The solution is:
sudo setsebool -P httpd_enable_cgi on
sudo setsebool -P httpd_unified on
sudo setsebool -P httpd_builtin_scripting on
this is the link for the question i took from the solution : https://stackoverflow.com/a/29139124/12717902
i'm facing the next error in a centos 7 server
I take a look to similar questions saying that is because SELinux doesn't allow to httpd to write in my /home folder, i've tried changing the owner of the folder without success; try changing the context (chcon) to httpd_sys_rw_content_t of my /home with the same error; try disabling SELinux and the error persists; and in the file httpd.conf change the User and Group from apache to test this didn't work either. My server is:
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.4.1708 (Core)
Release: 7.4.1708
Codename: Core
and
Linux localhost 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
When I execute move_uploaded_file() from php -a as user test it works normally, i see that the issue is with the user apache
TLDR:
Do not run setenforce 0 command, this will disable SELinux! You should not disable SELinux for security reasons.
The solution:
You should update policy to make SELinux allow read and write on specific directories:
To allow apcahe to read and write.
chcon -R -t httpd_sys_rw_content_t /path/your_writabl_dir
For read only directories:
chcon -R -t httpd_sys_content_t /path/yourdir
For example you can make your public (document root) directory read only and only allow write on directories that you allow you app to write on:
# Make all read only
chcon -R -t httpd_sys_content_t /var/www/myapp
# Only allow write on uploads dir for example
chcon -R -t httpd_sys_rw_content_t /var/www/myapp/public/uploads
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?
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.