I have a SQLite database that I am using for a website. The problem is that when I try to INSERT INTO it, I get a PDOException
SQLSTATE[HY000]: General error: 8 attempt to write a readonly database
I SSH'd into the server and checked permissions, and the database has the permissions
-rw-rw-r--
I'm not that familiar with *nix permissions, but I'm pretty sure this means
Not a directory
Owner has read/write permissions (that's me, according to ls -l)
Group has read/write permissions
Everyone else only has read permissions
I also looked everywhere I knew to using the sqlite3 program, and found nothing relevant.
Because I didn't know with what permissions PDO is trying to open the database, I did
chmod o+w supplies.db
Now, I get another PDOException:
SQLSTATE[HY000]: General error: 14 unable to open database file
But it ONLY occurs when I try to execute an INSERT query after the database is open.
Any ideas on what is going on?
The problem, as it turns out, is that the PDO SQLite driver requires that if you are going to do a write operation (INSERT,UPDATE,DELETE,DROP, etc), then the folder the database resides in must have write permissions, as well as the actual database file.
I found this information in a comment at the very bottom of the PDO SQLite driver manual page.
This can happen when the owner of the SQLite file itself is not the same as the user running the script. Similar errors can occur if the entire directory path (meaning each directory along the way) can't be written to.
Who owns the SQLite file? You?
Who is the script running as? Apache or Nobody?
For me the issue was SELinux enforcement rather than permissions. The "read only database" error went away once I disabled enforcement, following the suggestion made by Steve V. in a comment on the accepted answer.
echo 0 >/selinux/enforce
Upon running this command, everything worked as intended (CentOS 6.3).
The specific issue I had encountered was during setup of Graphite. I had triple-checked that the apache user owned and could write to both my graphite.db and its parent directory. But until I "fixed" SELinux, all I got was a stack trace to the effect of: DatabaseError: attempt to write a readonly database
This can be caused by SELinux. If you don't want to disable SELinux completely, you need to set the db directory fcontext to httpd_sys_rw_content_t.
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/railsapp/db(/.*)?"
restorecon -v /var/www/railsapp/db
I got this error when I tried to write to a database on an Android system.
Apparently sqlite3 not only needs write permissions to the database file and the containing directory (as #austin-hyde already said in his answer) but also the environment variable TMPDIR has to point to a (possibly writable) directory.
On my Android system I set it to TMPDIR="/data/local/tmp" and now my script runs as expected :)
Edit:
If you can't set environment variables you can use one of the other methods listed here: https://www.sqlite.org/tempfiles.html#temporary_file_storage_locations
like PRAGMA temp_store_directory = 'directory-name';
In summary, I've fixed the problem by putting the database file (* .db) in a subfolder.
The subfolder and the database file within it must be a member of the
www-data group.
In the www-data group, you must have the right to write to the
subfolder and the database file.
####### Additional Notes For Similar Problem #####
I gave write permissions to my sqlite database file to other users and groups but it still didn't work.
File is in my web root directory for my .NET Core WebApi.
It looked like this:
-rw-rw-rw- 1 root root 24576 Jan 28 16:03 librestore.db
Even if I ran the service as root, I kept getting the error :
Error: SQLite Error 8: 'attempt to write a readonly database'.
I also did a chown to www-data on the librestore.db and I still received the same error.
Finally I moved up above my webroot directory and gave others write access to that directory (LibreStore - the root of my WebApi) also and then it worked.
I'm not sure why I had to give the directory write access if the specific file already had write access, but this is the only thing that worked.
But once I made that change www-data user could access the .db file and inserts succeeded.
I got the same error from IIS under windows 7. To fix this error i had to add full control permissions to IUSR account for sqlite database file. You don't need to change permissions if you use sqlite under webmatrix instead of IIS.
I used:
echo exec('whoami');
to find out who is running the script (say username), and then gave the user permissions to the entire application directory, like:
sudo chown -R :username /var/www/html/myapp
(For followers looking for an answer to a similar question)
I'm building a C# .Net Core 6.0 WPF app. I put the Sqlite.db3 on the c:\ drive for convenience while developing. To write to the database I must open Visual Studio 2019 as Administrator.
#Charles in a comment pointed out the solution to this (or at least, a botch solution). This is merely me spelling it out more clearly. Put file_put_contents('./nameofyourdb.sqlite', null); (or .db, whichever you fancy) in a .php file in the root directory of your app (or wherever you want the db to be created), then load that page which renders the php code. Now you have an sqlite db created by whichever user runs your php code, meaning your php code can write to it. Just don't forget to use sudo when interacting with this db in the console.
A good clean solution to this is to allow the file of your main user account to be written to by (in my case) the http user but this worked for me and its simple.
None of these solutions worked for me and I suppose I had a very rare case that can still happen. Had a power shortage so even with 777 permissions on folder and db file, without SELinux, I would get this error.
Turns out there was a jellyfin.pid file (not sure if it's named after the service or user as they have the same name) locking it after the power shortage. Deleted it, restarted the service and everything worked.
I got this in my browser when I changed from using http://localhost to http://145.900.50.20 (where 145.900.50.20 is my local IP address) and then changed back to localhost -- it was necessary to stay with the IP address once I had changed to that once
Related
Today I have encountered a strange behaviour which I do not understand.
I am trying to create a directory on the local disk using a PHP 7.0 script using mkdir() function but it produces a "permission denied" error.
In my experience (although very little) this always meant that the user which is executing the PHP script is not authorized to write to the directory. This makes sense to me and is usually not a problem when developing web applications. The default PHP user when using Apache is www-data and I don't encounter problems with it.
In this case though I am using Zend Framework 2 and in particular I am using it's console routes so I am not going through Apache (correct me if I am wrong). I am calling my script as:
php index.php route name [--options]
with my user (which is not root but is a sudoer). The problems start if I output the result of PHP's get_current_user() function because I get 'root' instead of my expected user name. Not only this, but I get 'permission denied' when using mkdir() in the following directory:
drwxr-xr-x 2 www-data www-data 4096 Aug 19 21:21 logs
What I understand from this is that I probably am not the root user as PHP seems to suggest. If I then run the script with 'sudo' in front I am able to create the desired folders but the permissions do not match the ones I specify in my mkdir() function. If I write mkdir('path', 0777) I then get:
drwxr-xr-x 3 root root
This I do not understand. So, if someone could help me figure out what I am doing wrong I would be very thankful. Keep in mind that the fact that I am going through Zend Framework 2 might influence this behaviour (although I am not keen on thinking so).
Thank you in advance for your time.
Edit.
I just realized I didn't tell you what my final goal is so I will now put things in context, sorry.
What I am trying to do is to use this script (run either from root or from my user, preferably from my user) to create these folders inside
/var/www
and to then be able to read and write files (and possibly other folders) to those directories whith the standard PHP user which in my case is www-data
your php runned as apache extension, and using apache permissions.
If you need to create folder as root, you can create cron script for it, which will monitor change in some file, and create directory as root.
Another way to do it, using suid extension, but it a bit complicated.
I used to have a working Joomla 3 site, but when upgrading Ubuntu from 12.10 to 13.10, I lost the OS. I've copied everything from /var/www and /var/lib/mysql and have the contents available.
I've placed the contents of /var/www onto my new system's Apache2 DocumentRoot, and can access the files. I've gone through and checked the configurations, but am stuck at the point of restoring my old MySQL database using the /var/lib/mysql files.
I've wrecked one system simply by 'scp /old_server/mysql root#roboserver.local:/var/lib' in which the mysql server failed every attempt to access. So instead I created a new database with the same name and copied everything 'var/lib/mysql/robo/.' over to that new server's database in that same location.
I need to know how to bring back an old Joomla database exactly as I had it. The current error I am getting is:
Error displaying the error page: Application Instantiation Error: Can't find file: './robo/robo_session.frm' (errno: 13) SQL=DELETE FROM `robo_session` WHERE `time` < '1399079287'
I'm 15yrs old, just started using SSH a month ago, so if you could give a step-by-step fix I'd appreciate it! I have complete physical and root access to every machine.
I've found the solution and am documenting it for anyone else with this specific problem.
When Joomla returned the error from the MySQL Database, it attempted to find the file by reading it. Running 'chown -R mysql:mysql /var/lib/mysql' set all the permissions back to normal, allowing the database to be read.
In my attempts to repair the databases, I neglected to check ownership of the files. (As I was logged in through SSH as root, yes, shame on me.)
I'm trying to use this Dagon Design PHP form to help a local non-profit publication enable their readers to submit photos. I've got the "mailer" part working -- the notifications work fine -- but the "saving a file to a folder" part isn't functioning.
On the form page, the author says "the directory must have write permissions," but I'm not sure "who" is writing to that folder -- is this PHP script considered "Owner" when it saves something on my site? Or do I need to allow save permissions for Owner, Group and Others?
I'm not sure why the script isn't saving the photos, but this seems like a good place to start. I've tried looking around on Stack for answers, but most questions seem to have to do with folder creation/permissions.
The page I'm clumsily trying to build is here, if that helps.
As Jon has said already, you don't want to allow write access to everyone.
It's also possible (depending on the hosting) that something like suEXEC is being employed - which will cause your PHP script to run as a user other than the webserver's (as reported by Dunhamzzz).
Probably your best approach, in my opinion, is a script calling whoami:
passthru('whoami');
Or alternatively you could try:
var_dump(posix_getpwuid(posix_geteuid()));
Bear in mind, this does give system information away to the world - so delete the script once you've used it!
Then, as you've correctly asserted in your question, it'll likely be the file permissions.
If you do have CLI access, you can update the permissions safely as so (first command gets the group)
id -n -g <username>
chmod 770 <directory>
chown <username>:<group> <directory>
(You may have to pre-pend "sudo" to the "chown" command above, or find other means to run it as "root"..., reply back if you get stuck.)
If you've not got access to run command-line, you'll presumably be doing this via a (S)FTP client or the alike. I'm afraid the options get a little to broad at that point, you'll have to figure it out (or reply back with the client you're using!)
As always, YMMV.
Finally, bear in mind if this is your own code, people will at some point try uploading PHP scripts (or worse). If that directory is accessible via a public URL ... you're opening the hugest of security holes! (.htaccess, or non-document root locations are your friend.)
If you are not sure how is your server configured (and this would influence who's the final file owner) then add write permission to anyone (chmod a+w folder), upload one file and ls -l to see the owner. Then you can adjust permissions to allow write access to certain users only
The PHP script that saves the files is running with the privileges of some user account on the server; the specific account depends on your OS and the web server configuration. On Linux and when PHP is running as an Apache module this user is the same user that Apache runs as.
Solving your problem reduces to determining which user account we are talking about and then ensuring that this user has permission to write to the save directory (either as owner or as a member of the group; giving write access to everyone is not the best idea).
You'll need to set the permissions of the directory to that of the webserver (probably Apache, nginx or similiar), as that's what is executing the PHP.
You can quickly find out the apache user with ps aux | grep apache, then you want to set the permssions of the upload directory to that user, something like this:
chown -R www-data:www-data images/uploads
I am trying to save a PHP file in TextWrangler and it keeps giving me the error:
You do not have sufficient privileges to perform this operation (MacOS Error code: -5000)
I've also tried to enable PHP by opening the file:
Macintosh HD:private:etc:apache2:httpd.conf
and editing the appropriate file but I get the same error message. Why would I be prevented from making these changes on my computer? I was assuming it would prompt me for a password but it just gave me the error. Thanks.
I found out what the answer is.
I purchased TextWrangler from the Mac App Store and the version from the App Store does not allow authenticated saves in order to meet the App Store submission guidelines (I don't know the specifics exactly).
The one that should be download is:
http://www.barebones.com/products/textwrangler/
Thanks for the help guys!
Read up on unix file permissions if you really want to understand this, and do an ls -al from terminal in the directory you're editing.
Essentially, your user just doesn't have privileges, either because it isn't the owner or because writing is disabled. Try using 'sudo' before your commands. Your password should be your user password.
You can change permissions like this:
sudo chmod 777 filename (makes globally writable)
sudo chown myuser filename (makes a new owner for file)
when I uploaded the script to the server I got this error
Warning: Unknown: open(/tmp/sess_58f54ee6a828f04116c2ed97664497b2, O_RDWR) failed: Permission denied (13) in Unknown on line 0
Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0
The error appeared when I call session_start(), although I set the permission of /tmp folder to 777.
Change session path where you can write data or contact server administrator about /tmp problem
http://php.net/manual/en/function.session-save-path.php
you will need to change your session.save_path php.ini directive
You can do that using session_save_path
If you have SSH access, here is how to correct the permission and ownership
sudo chown -R NAME_OF_USER /tmp
Replace NAME_OF_USER by the user under which runs php. You can find it by simply putting these lines in a php file:
$processUser = posix_getpwuid(posix_geteuid());
print $processUser['name'];
exit;
Check that you're not running into diskspace issues. If all the permissions are correct (and 777 ought to do it for you), then you might still get this error (for some versions of PHP and Apache) if there isn't enough space to write to the disk.
I had this problem in the following situation:
I filled some session vars with PHP
While the session was still active, I changed from PHP 5.4 to 5.3 on my host.
Reloading the page gave the error, described above.
Reset the PHP version to 5.4 again.
Used session_unset(); and session_destroy(); to clean the current session.
Changed the PHP version back to 5.3.
Now it works again.
Conclusion: For an irrelevant reason I had to change my PHP version, and while switching with sessions alive, the sessions get corrupted.
I realize that this is an old post, however I just ran into this problem, and found an easy solution.
For me, the issue was happening with one of my websites deployed locally. I hadn't tried accessing the websites using other browsers, but it was happening every time I tried to access this site via Chrome. I decided to go into the Chrome developer tools, under the application tab -- and clicking "Clear Storage". Voila -- everything is working like magic again.
Hope this helps someone else!
Additionally, you may want to use ini_set('session.save_path', '/dir/here'); assuming you have access to this function. The other ways suggested are valid.
I've just had exactly the same problem with one of my PHP scripts and I was like what did I break 'cos it worked perfectly the day before and I'm running it from my own local Puppy Linux machine so it's not even a host or anything.
The only thing I'd been doing before that was trying to get Java to work in the web browser, so some how I'd managed to get Java to work but broke PHP - oops!
Anyway I did remember that whilst trying to get Java to work I had deleted the contents of the /tmp folder to wipe anything out that may be causing a problem (it actually turned out with Java I was using the old plugin oij with the new Firefox)
To solve this problem I opened up Rox File Manager, went to the / folder and right clicked on the tmp folder -> Mount Point 'tmp' and clicked properties.
I noticed the permissions were set as Owner - Read, Write, Exec, but Group and World were only set at Read and Exec and not Write. I put a tick in Write for both Group and World and now PHP works fine again.
I don't know at what point the permissions for tmp must have changed but for PHP to use them it must be set to have Write permissions.
Add following line
ini_set('session.save_path', getcwd() . '/tmp');
before
session_start();
if you are using Apache web server, the quick fix is to go to your command line and type:
open /etc/apache2/
then from the window opened, open the file called httpd.conf and search for User or Group change these 2 lines to:
User _www
Group _www
This is because you want your server to have permission to your systems directories, especially you want to change the User or you can leave your Group to either staff or admin.
I had the same problem of permission, but on /var/lib/php/session/.
To fix it, I deleted the file and restarted php-fpm.
rm -rf /var/lib/php/session/sess_p930fh0ejjkeeiaes3l4395q96
sudo service php5.6-fpm restart
Now all works well.
For me the problem seems to be a WHM bug!
I have a bunch of add on domains and all work fine but with a subdomain it brings this error.
Strange thing but if I use the full URL with the main domain it works fine:
main-domain.com/my.subdomain.com
If I use the subdomain directly it brings "Permission denied (13)":
my.subdomain.com
The thing is all addon domains root is:
/home/xx/
But for my subdomain, don't know why, the root is: (I shouldn't have access to that dir)
/
So it´s really trying to reach: /tmp instead of /home/xx/tmp
Which also exists but don't have the right permissions
To clarify this are examples of the whole path:
/home/my-account/public_html
/home/my-account/tmp
/tmp
The workaround I used was:
session_save_path('/home/my-account/tmp');
session_start();
Using PHP 5.6 I had already used session_save_path() to point to a directory within the domain's structure. It worked fine until I upgraded to PHP 7.0, at which time I received the noted error. At PHP.net I found several comments that indicated assigning a direct path didn't always work, so I used their suggestion.
session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../session'));
worked perfectly. Remember to change /../session to the relative location of your actual session directory.
If :
session.gc_probability > 0
session files are created by different user(s) (e.g. root and apache).
session files are all stored in the same place (e.g. /var/lib/php/session)
Then you'll see this error when e.g. the Apache PHP process attempts to run garbage collection on the session files.
Fixes :
Reconfigure PHP so gc_probability is 0, and have a cron job removing the old/stale file(s).
Have each different user save their session files in separate place(s) (session_save_path() etc).
I initially had this issue due to nginx owning the /tmp location and php-fpm was running under 'apache' user and group due to the www.conf. I swapped out the user/group in that file and then it worked ok. You may want to check <?php echo exec('whoami'); ?> to verify.
In my case the problem was SELINUX not allowing this.
A helpful command to get suggestions on how to fix this:
sealert -a /var/log/audit/audit.log
If you want to rule out SELINUX, try disabling it for a moment. If that fixes the issue then that is the problem.