This is on a private server. I have one outstanding issue from the install, my guess has been I need to fix that. It's the "Large File Storage Not Configured". However, I've changed all the parameters it asks for. I have:
nginx:
client_max_body_size 32
php.ini:
post_max_size = 32
memory_limit = -1 (disabled)
max_input_vars = 200000
upload_max_filesize = 32
I want it to use the default, to store things in MySQL, so I also have storage.mysql-engine.max-size at 8M.
But I also found this, that does not seem to be right:
PhabricatorChunkedFileStorageEngine writable: No
I have no idea how to change it though, or if I should.
The actual error message I get when I try to upload files (no matter what size) is:
Upload Failure
Exception: No configured storage engine can store this file. See "Configuring File Storage" in the documentation for information on configuring storage engines.
I got help from a Phacility staff member. It was just an error of mine, but they will update the documentation now to prevent more people from making that mistake - ´silverlining! :) https://secure.phabricator.com/D17037
I had storage.mysql-engine.max-size 8, as I thought that would give me 8MB. I've changed it to 8388608 now, which works, as it is supposed to be in bytes.
This might be helpful for anyone else.
In my case I am using, Engine: Local Disk, to store files but after configured it still gives error as mentioned below:
Unhandled Exception ("PhutilAggregateException")
All storage engines failed to write file:
- PhabricatorLocalDiskFileStorageEngine: CommandException: Command failed with error #1!
COMMAND
mkdir -p /var/files/64/66
STDOUT
(empty)
STDERR
mkdir: cannot create directory '/var/files/64': Permission denied
As the error states that permission is denied so I got it working by assigning user to the dir and updating permissions.
sudo chown -R ubuntu:ubuntu /var/files/
sudo chmod 777 /var/files/
Related
I know there are similar other questions here, but none of them solved my problem.
The problem: I'm setting data into $_SESSION, but in upcoming calls it is appearing as empty.
What I did to try solving it?
Make sure to run an up-to-date version of PHP
Make sure to know which php.ini is used
Log status of $_SESSION before and after setting it
Set various variables as suggested in other questions and forums
Here below I provide all the info I could supply, and hoping somebody will be able to suggest a solution!
I have installed PHP on my Mac using brew install php
I am running it locally for software development using this command:
php -S localhost:8099 -d display_errors=on -t .
[Tue Nov 17 23:12:55 2020] PHP 7.4.11 Development Server (http://localhost:8099) started
I'm calling session_start(); at the beginning of my script.
I am setting values into $_SESSION, but it is always empty when I am testing it in the following calls:
$ses = json_encode($_SESSION);
site_log("before: {$ses}");
session_regenerate_id();
$_SESSION["upath"] = 'XXXXXX';
$ses = json_encode($_SESSION);
site_log("after: {$ses}");
The result is always the same (while I'm expecting to see it on first call but not for the following calls):
20201118_040124_484 before: []
20201118_040124_485 after: {"upath":"XXXXXX"}
I was trying to follow many ideas from web forums:
Verify which is the INI file:
php -i | grep 'Configuration File'
>Configuration File (php.ini) Path => /usr/local/etc/php/7.4
>Loaded Configuration File => /usr/local/etc/php/7.4/php.ini
I was setting various INI file variables:
session.save_path = "/Users/myuser/Prog/MyApp/sessions"
+
chmod 777 /Users/myuser/Prog/MyApp/sessions
+
session.use_cookies = 1
+
session.cookie_secure = 0
But the result is still the same. Any idea please?
The following link points to the result of calling phpinfo(): link
So finally I have found a solution.
It is based on information provided here: Session cookie not being set
As #deceze was commenting correctly to my question, the first steps to debug such problem are these:
Check whether session files are created in the save_path folder (in my case: yes)
Use the dev-tools of the browser to see if cookies are set for the site (in my case: no)
So the actual problem is: why cookies are not set?
The solution:
Add an entry to alias 127.0.0.1 as a 'dot com' name. This is what I did:
# for Mac! see linked answer for other platforms
sudo vi /private/etc/hosts
# add this line:
127.0.0.1 mylocal.com
Activate the local php server for this domain (from the site root folder):
php -S mylocal.com:8099 -d display_errors=on -t .
Load the site from the php server. I'm using Brackets, and I had to open the menu: File -> Project Settings and set the live preview base URL to be:
http://mylocal.com:8099/
Some variables in the INI file might need to be set too, as already detailed in the question above
Hoping this info will help to others!
For some reason my production DB decided to spew out this message. All application calls fail to the DB with the error:
PreparedStatementCallback; SQL [ /*long sql statement here*/ ];
Can't create/write to file '/tmp/#sql_3c6_0.MYI' (Errcode: 2);
nested exception is java.sql.SQLException: Can't create/write to file '/tmp/#sql_3c6_0.MYI' (Errcode: 2)
I have no idea, what this even means. There is no file #sql_3c6_0.MYI in /tmp and I can't create one with a # character for some reason. Has anyone heard about it or seen this error? What could be wrong and some possible things to look at?
The MySQL DB seems to be up and running and can be queried via the console but the application can't seem to get through to it. There was no change to the application code/files. It just happened out the blue. So I'm not even sure where to start look or what resolution tactics to apply. Any ideas?
I meet this error too when I run a wordpress on my Fedora system.
I googled it, and find a way to fix this.
Maybe this will help you too.
check mysql config : my.cnf
cat /etc/my.cnf | grep tmpdir
I can't see anything in my my.cnf
add tmpdir=/tmp to my.cnf under [mysqld]
restart web/app and mysql server
/etc/init.d/mysqld restart
Often this means your /tmp partition has run out of space and the file can't be created, or for whatever reason the mysqld process cannot write to that directory because of permission problems. Sometimes this is the case when selinux rains on your parade.
Any operation that requites a "temp file" will go into the /tmp directory by default. The name you're seeing is just some internal random name.
On Fedora with systemd MySQL gets private /tmp directory. In /proc/PID_of_MySQL/mountinfo you will find the line like:
156 129 8:1 /tmp/systemd-namespace-AN7vo9/private /tmp rw,relatime -
ext4 /dev/sda1 rw,seclabel,data=ordered
This means a temporary folder /tmp/systemd-namespace-AN7vo9/private is mounted as /tmp in private namespace of MySQL process. Unfortunately this folder is deleted by tmpwatch if not used frequently.
I modified /etc/cron.daily/tmpwatch and inserted the exclude pattern -X '/tmp/systemd-namespace*' like this:
/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
-x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
-X '/tmp/systemd-namespace*' \
-X '/tmp/hsperfdata_*' 10d /tmp
The side effect is that unused private namespace folders will not be deleted automatically.
The filename looks like a temporary table created by a query in MySQL. These files are often very short-lived, they're created during one specific query and cleaned up immediately afterwards.
Yet they can get very large, depending on the amount of data the query needs to process in a temp table. Or you may have multiple concurrent queries creating temp tables, and if enough of these queries run at the same time, they can exhaust disk space.
I do MySQL consulting, and I helped a customer who had intermittent disk full errors on his root partition, even though every time he looked, he had about 6GB free. After we examined his query logs, we discovered that he sometimes had four or more queries running concurrently, each creating a 1.5GB temp table in /tmp, which was on his root partition. Boom!
Solutions I gave him:
Increase the MySQL config variables tmp_table_size and max_heap_table_size so MySQL can create really large temp tables in memory. But it's not a good idea to allow MySQL to create 1.5GB temp tables in memory, because there's no way to limit how many of these are created concurrently. You can exhaust your memory pretty quickly this way.
Set the MySQL config variable tmpdir to a directory on another disk partition with more space.
Figure out which of your queries is creating such big temp tables, and optimize the query. For example, use indexes to help that query reduce its scan to a smaller slice of the table. Or else archive some of the data in the tale so the query doesn't have so many rows to scan.
Tremendous thanks to ArturZ for pointing me in the right direction on this. I don't have tmpwatch installed on my system so that isn't the cause of the problem in my case. But the end result is the same: The private /tmp that systemd creates is getting removed. Here's what happens:
systemd creates a new process via clone() with the CLONE_NEWNS
flag to obtain a private namespace. Or maybe it calls unshare()
with CLONE_NEWNS. Same thing.
systemd creates a subdirectory in /tmp (e.g.
/tmp/systemd-namespace-XRiWad/private) and mounts it on /tmp.
Because CLONE_NEWNS was set in #1, this mountpoint is invisible to
all other processes.
systemd then invokes mysqld in this private namespace.
Some specific database operations (e.g. "describe ;") create
& remove temporary files, which has the side effect of updating the
timestamp on /tmp/systemd-namespace-XRiWad/private. Other database
operations execute without using /tmp at all.
Eventually 10 days go by where even though the database itself
remains active, no operations occur that update the timestamp on
/tmp/systemd-namespace-XRiWad/private.
/bin/systemd-tmpfiles comes along and removes the "old"
/tmp/systemd-namespace-XRiWad/private directory, effectively
rendering the private /tmp unusable for mysqld while the public /tmp
remains available for everything else on the system.
Restarting mysqld works because this starts everything over again at step #1, with a brand new private /tmp directory. However, the problem eventually comes back again. And again.
The simple solution is to configure /bin/systemd-tmpfiles so that it preserves anything in /tmp with the name /tmp/systemd-namespace-*. I did this by creating /etc/tmpfiles.d/privatetmp.conf with the following contents:
x /tmp/systemd-namespace-*
x /tmp/systemd-namespace-*/private
Problem solved.
For me this issue came after a long period of not using mysql nor the webserver. So I was sure that my settings where correct; Simply restarting the service fixes this issue; The weird part about the issue is that one can still connect to the database, and even query/add tables using the mysql tool. for example :
mysql -u root -p
I restarted using :
systemctl start mysqld.service
or
service mysqld restart
or
/etc/init.d/mysqld restart
Note : depending on the machine/environment on of these commands should restart the service.
A better way worked for me.
chown root:root /tmp
chmod 1777 /tmp
/etc/init.d/mysqld restart
That is it.
See here :http://nixcraft.com/databases-servers/14260-error-1-hy000-cant-create-write-file-tmp-sql_9f3_0-myi-errcode-13-a.html
http://smashingweb.info/solved-mysql-tmp-error-cant-createwrite-to-file-tmpmykbo3bl-errcode-13/
it's very easy, you just grant the /tmp folder as 777 permission.
just type:
chmod -R 777 /tmp
On an Ubuntu box, I started getting this error after moving /tmp to a different volume (symlink). Even after setting the required permission 1777, the issue was not resolved.
MySQL is protected by AppArmor, which was disallowing writes to the new tmp location /mnt/tmp.
I had to add the following lines to /etc/apparmor.d/abstractions/user-tmp to fix this
owner /mnt/tmp/** rwkl,
/mnt/tmp/ rw,
On debian 7.5 I got the same error. I realized the /tmp folder owner and permissions were off. As another answer suggested I did as follows (must be root):
chown root:root /tmp && chmod 1777 /tmp
I did not even have to restart mysql daemon.
I'm using mariadb. When I try to put this line at /etc/my.cnf:
[mysqld]
tmpdir=/tmp
It solved the error generated from website frontend related to /tmp.
But, it has backend problem with /tmp. Example, when I try to rebuild mariadb from the backend, it couldn't read the /tmp dir, and then generated the similar error.
mysqldump: Couldn't execute 'show fields from `wp_autoupdate`': Can't create/write to file '/tmp/#sql_1680_0.MAI' (Errcode: 2 "No such file or directory") (1)
So this one work for both front end and back end:
1. mkdir /var/lib/mysql/tmp
2. chown mysql:mysql /var/lib/mysql/tmp
3. Add the following line into the [mysqld] section:
tmpdir = /var/lib/mysql/tmp
4. Restart mysqld (eg. Centos7: systemctl restart mysqld)
Its due to access control security policies specifically when SELinux is enabled it won't allow external executables to create temporary files in the system locations.
Disable SELinux by issuing below command:
echo 0 >/selinux/enforce
You can now start mysql it wont give any permission related errror while reading/writing to /tmp or system directories.
In case you wish to enable the SELinux security back change 0 to 1 in above command.
Check permission issues, mysql config.
Also check if you haven't reached disk space, quota limits.
Note: Some systems are limiting number of files (not just space), deleting some old session files helped fixed the issue in my case.
For those using VPS / virtual hosting.
I was using a VPS, getting errors with MySQL not being able to write to /tmp, and everything looked correct.
I had enough free space, enough free inodes, correct permissions. Turned out the problem was outside my VPS, it was the machine hosting the VPS that was full. I only had "virtual space" in my file system, but the machine in the background which hosted the VPS had no "physical space" left. I had to contact the VPS company any they fixed it.
If you think this might be your problem, you could test writing a larger file to /tmp (1GB):
dd if=/dev/zero of=/tmp/file.txt count=1024 bs=1048576
I got a No space left on device error message, which was a giveaway that it was a disk/volume in the background that was full.
I had the same issue and it was caused because our DB server run out of space. Clearing up some disk space solved the issue.
Currently, when I visit localhost/phpmyadmin, I am seeing the following error:
ERROR: Token Mismatch (In tooltip)
Incorrect format parameter
I will explain the changes I did step by step:
I had xampp of version 1.7.1 installed.
To upgrade it to latest, I renamed Xampp folder in c:// to "xampp_1" and took the group database backup in .sql format.
From this link, I downloaded php_oauth-1.2.3-5.6-ts-vc11-x86.zip and copied the php_oauth.dll to c://xampp/php/ext/ and then in php.ini, I mentioned extension=php_oauth.dll.
After this, I ran Apache server and Mysql through Xampp.
then tried to import the sql backup file through CLI as follows:
mysql -u root < localhost.sql
I got some error in command prompt. (I will update this soon)
Then later when I visited localhost/phpmyadmin, I am seeing this page:
In my case this worked:
logout
clear url (remove all after ?, wspecially token=blablabla must be removed)
remove all cookies
refresh
login
This can't fix the problem basically as the same error may appear in any time
Find php.ini in the xampp
1- post_max_size: 128M (give a size for example 128)
2- upload_max_filesize : 64M (for example 64)
post_max_size must be larger than upload_max_filesize to fix the problem.
Reason: You are getting this error because size of your filename.sql is greater than maximum upload limit. (By default you can import upto Max:2,048KiB)
Solution:
Navigate to xampp\php\php.ini
Find upload_max_filesize and increase it to desired upload side (e.g. upload_max_filesize=128M) and save
Restart xampp
Adding solution as a answer text so that the question drops from the Unanswered Questions list. Original answer is provided by the question author in a reply/comment on his original question text:
I uninstalled both 1.7.1 and 5.6.3 and then re-installed 5.6.3. That
did the trick.
The problem is with the Post Maximum size, open the PHP.ini file and find the
post_max_size=8M and increase it up to post_max_size=128M,
1.PHP.ini ->increase the post_max_size parameter from 8M up to 128M,
that's it.
I found a perfect solution in the following tool:
BigDump: Staggered MySQL Dump Importer
which allowed me to change the connection charset to match that of the dumpfile. Works fine without any installs/re-installs.
set this database and ini file
SET GLOBAL max_allowed_packet=1073741824;
max_allowed_packet = 64M
then: use CLI (cmd)
goto ->xamp->mysql->bin
copy the path n set in Cmd
use below command to dumb db
mysql.exe -u root -p db_name< "C:\Users\path\file.sql"
Everytime I try to modify a file, I get this error and I don't know what it means:
A PHP Error was encountered
Severity: Warning
Message: file_put_contents() [function.file-put-contents]: Only 0 of 19463 bytes written, possibly out of free disk space
Filename: Template/String.php
Line Number: 369
I tried looking for solutions and so far none of them made sense, well, in my opinion.
Any thoughts? A little help here please. Thank you very much.
This is an old question but it comes up when Googling for the error message. Here is another possible cause for this error message.
The ext2/3/4 filesystems can reserve disk space for root. Often it is 5% of the drive. df shows the drive is not entirely used. Root can write to the drive. Non-root users will only be able to create files but not write any data to them. See dumpe2fs and tune2fs for more details.
This probably means that PHP is able to get a valid file descriptor, but is hitting a wall (such as a quota, sticky bit, etc) when actually trying to write the data.
It is also conceivable that you are writing (perhaps unwittingly) to a network file system that is having a problem with its peer.
More information regarding your platform would help (I've seen SELinux do strange things when improperly configured), but I think you get the gist of what to check.
It's just a permission to where you wanted to save the content, e.g. readonly or just like the error itself, no disk space.
You may need to increase the quota for that user on the server. You can confirm this by deleting a file and seeing if it will let you re-upload that file, but nothing further.
If you have Webmin, go to System > Disk Quota. (For a detailed explanation, see this wiki.)
If you do not have Webmin or a similar interface, you will need to look up how to manually edit the user quota settings depending on which Linux distro you are using.
If you do not have access to the server you will need to contact the person who does and ask what your disk quota is and if it can be increased.
For me I was also having the same set of errors on my login page. While exploring I found that the storage/logs/laravel.log file has grown up to the size of 24G. And clearing it solved the issue. To find out the size of directory use linux command du -sh * or du -sh <filename> . To clear up the log file using truncate command is the best option. Because oping with vim and deleting could be difficult because of Heavy size of the file. For truncating use the command truncate -s 0 <filename>
I went to the root directory
cd /
and searched for the folder that had the biggest space usage with
du -sh *
from there I was able to trace the file giving the headache, pluto.log in /var/log. this could be any file.
Maybe you have a previous lock on your target file, try to:
$fp = fopen('yourfile.etc', 'r+');
if (!flock($fp, LOCK_EX | LOCK_NB)) {
//this file is actually being used from another script / user, that's the problem.
} else {
//ok, there wasn't lock on it, must be something else
fclose($fp);
}
<?PHP
print "hello";
?>
I write this code and save as "1.php";
Then I upload this PHP script to my
server.
I have 8 diffrent free hosting server's accounts.
And I noticed that there are 2 types of
server settings.
(1)
"type A"
for exapmle, sqweebs.
We need to set the PHP file permission as 640.
This means that sqweebs server requires us
to give group permission for PHP script running.
If I set 604,then the server generate such a
errors.like,
Warning: Unknown:
failed to open stream:
Permission denied in Unknown on line 0
Fatal error: Unknown:
Failed opening required
'/www/sqweebs.com/1.php'
(include_path='.:/blahblah')
in Unknown on line 0
(2)
On the other hand ,there are other type
servers on this world.
"Type B",
for example, izfree.
On this server, I found that
I can make PHP script work if I give it
604 as the permission.
So I want to know why there are many server settings,
and what is the reason, and some other related
opinions.
like which server should I use ,or etc,etc.
The problem is probably with using the free hosts. They add server limitations, and most likely, disable/enable certain restrictions that they feel are fit for administering how you can behave on their site.
It probably depends on the permissions and under which group/user the apache is running. If it's running with your rights, you will be fine with 600, if the apache is not even in the same group as you are you probably need something like 604. All I'm saying is, it depends on the server configuration AND the file permissions. This is a wild guess, but if you really need something like 604, it could be a sign that there is potentially something wrong and other users maybe able to look into your home directory...
it is expected, by the webserver, that the file has to have the permission for the user that the webserver runs as, to open and run it.
So, if the webserver (say Apache) runs as www, then www should have read access to the file. (some run apache as www, and some run it as apache, or nobody).
When you upload the file, depending on how the umask is set, the file permission is set so. (so, on one host, the file could have permission 655 or other could be 600, when permission is not set explicitly).
It always helps if you know a bit about the OS you normally deploy your applications on. Mostly, PHP is deployed on *nix system, and permission scheme is nearly (almost always) same across all the *nix systems.
Try getting hold of "Unix system Administration Handbook" (by Evi Nemeth & Co). Its quite fun to read and easy to understand (it is an old edition .. but unix permissions have not changed)