I've got DOMPDF 0.5.1 running in a Drupal implementation on my localhost (xampp, windows 7) which generates my Pdf's just fine.
But when i commit this to the live server things go wrong. I get the error: "The font "Futura" contains a bad /BBox"
And all text is displayed as dots.
Any idea what might be going on?
The user who starts your webserver i.e. httpd or apache must have read/write access to the font folder as well, that might cause the problem.
Give your webserver write permission on the path specified in DOMPDF_FONT_DIR (lib/fonts by default). Under *nix, ideally you can make the webserver group the owner of this directory and give the directory group write permissions. For example, on Debian systems, Apache runs as the www-data user:
$ chgrp www-data lib/fonts
$ chmod g+w lib/fonts
If your user is not a member of the www-data group or you do not have root privileges, you can make the directory world writable and set the sticky bit:
$ chmod 1777 lib/fonts
http://code.google.com/p/dompdf/wiki/Installation
Related
Almost always, when I am starting a Codeigniter 4 project, I am getting the following error:
"CodeIgniter\Cache\Exceptions\CacheException Cache unable to write to "/path/to/codeigniter-project/writable/cache/."
SYSTEMPATH/Cache/Handlers/FileHandler.php at line 61
which points at the below line:
throw CacheException::forUnableToWrite($this->path);
What is the best way to solve this?
After doing a research, I've concluded into two options
Option 1:
The very quick way to just solve the above issue is to go to the command tool (e.g. terminal) and change the permissions of the folder to be writable and also to change the owner of the folder to be the one that is used from your server application. For example, I am using Apache and the user for apache is www-data:
chmod -R 755 writable/
chown -R www-data:www-data writable/
or for macOS:
chmod -R 755 writable/
chown -R _www:_www writable/
Pros:
A quick copy-paste solution
Those commands - most of the times - works out of the box
Even if you don't have access to command tool, you can change the permissions and ownership of the folder through FTP (e.g. through FileZilla UI interface)
Cons:
You always need to add those commands into a new project
You may experience issues on development when you are trying to access the folder with your username
Option 2 (suggested for local development):
Add the www-data or _www (for macOS) to be at the same group role as your user.
for Linux and Apache:
sudo usermod -aG www-data your_username
or for macOS and Apache:
sudo dseditgroup -o edit -a your_username -t user _www
If you are still getting the error also make sure that you have the folder as writable with the following command:
chmod -R 755 writable/
I don't know why but it may also need to do a restart of the Apache.
Pros:
It works for new projects with no extra effort
You don't need to change the owner of the folder so you can have access to the folder for development
Once this change is available to the server or locally, you don't need to use sudo anymore if the chmod command is required
Cons:
Not that safe for production environments (especially if you don't know what you are doing) since you would prefer to have specific users with specific roles rather than have users to have access everywhere
It requires more effort and it is not that straight forward for beginners
It needs more permissions to the server (e.g. sudo access)
The OP has a good answer. Though sometimes you don't have access to the terminal or a secure shell (ssh), especially in a shared hosting environment to be able to run those commands.
I got a similar issue while working on a new project. I noticed that this normally happened because my application failed to write session files in the writable/session folder of my root project directory because of permission restrictions. I was using the CodeIgniter\Session\Handlers\FileHandler as my configured "session storage driver".
I managed to solve it by instructing the application to write these temporary files in the server's tmp directory.
This is by default in the /tmp directory.
Excerpt from php-src/php.ini-production
; Directory where the temporary files should be placed.
; Defaults to the system default (see sys_get_temp_dir)
;sys_temp_dir = "/tmp"
Solution
I opened my .env file residing at the root of my project directory and added the line below.
app.sessionSavePath = '/tmp/my_project_name/ci4_session'
If you don't have this .env file, create one starting with this default file content:
Notice the dot (.) in front of the filename.
CodeIgniter4 env file
Addendum
Similarly, in your case, the application fails to write cache files in the writable/cache folder of your root project directory because of permission restrictions. You most certainly are using file as your cache handler.
Solution
Open your .env file residing at the root of your project directory and add the line below.
cache.storePath = '/tmp/my_project_name/ci4_cache'
TIP(S)
These and more configurations can be found/modified in your .env file using the rules below:
The configuration class file name, in lower case. I.e cache.
Followed by a dot(.).
Then the public configuration class's property name. I.e storePath.
Steps 1,2,3 combined makes, cache.storePath, which becomes your .env file's key declaration. Then an equals sign =. And lastly, the .env file's value ('/tmp/my_project_name/ci4_cache') declaration. Finally coming up with, cache.storePath = '/tmp/my_project_name/ci4_cache'.
The configuration classes can be found in the app/Config folder of your root project directory. I.e:
app/Config/Cache.php
app/Config/App.php
This worked for me, U should try this
Firstly cd into where your file is Example
cd /opt/lampp/htdocs/
This is where my file is
Secondly Write this command below in your command prompt
sudo chmod -R 777 file-name
I just create a folder inside "writable" folder with name "cache" and my project properly running.
I changed my server; the old one ran Centos 8, the new runs Ubuntu 20.4. Now my php scripts have a problem with permissions -- why?
Example:
current user: root
script was executed under user: nobody
Message: fopen(/tmp/RebuildCat_sequence.cnt): failed to open stream: Permission denied
Actually this file is owned by nobody, so I should not get this warning at all:
CS-1 01:47:22 :/tmp# ls -latr /tmp/RebuildCat_sequence.cnt
--wxrwxrwT+ 1 nobody nogroup 480 Oct 23 00:02 /tmp/RebuildCat_sequence.cnt
This php file is called by cron (root), as a rule, and as I noticed that some similar cron triggered files are owned by systemd-timesync, I issued
setfacl -m u:systemd-timesync:rwX /tmp
setfacl -m u:nobody:rwX /tmp
and even
setfacl -R -m u:nobody:rwX /tmp
setfacl -R -m u:systemd-timesync:rwX /tmp
to no avail. How do I understand this?
In my understanding both users systemd-timesync and nobody should be able to read and write files in /tmp without problem due to acl. I think someone has to educate me here.
/tmp resides on /dev/md2
CS-1 01:32:34 :/tmp# tune2fs -l /dev/md2 | grep "Default mount options:"
Default mount options: user_xattr acl
No problem here, I guess.
CS-1 01:46:09 :/tmp# getfacl /tmp
getfacl: Removing leading '/' from absolute path names
# file: tmp
# owner: root
# group: root
# flags: --t
user::rwx
user:systemd-timesync:rwx
user:nobody:rwx
group::rwx
mask::rwx
other::rwx
Looks OK to me, as well. Clueless.
Addendum
OK, I set chmod 777 /tmp, but still I get a PHP error fopen(/tmp/RebuildCat_sequence.cnt): failed to open stream: Permission denied, but file_put_contents works with 777 -- how do I understand this? Why does fopen throw an error, but file_put_contents does not?
Alas, chmod 777 /tmp in the console is not the answer. It is much more complicated than that. So I wasn't silly at all.
How to reproduce?
In my case, I have 2 docker PHP containers writing to a number of case specific log files, one of them using apache, the other nginx. Both have a mapping /tmp:/tmp, so we can look at a file from the host or from inside a container.
From inside the containers, the owner is apache:apache if created in the apache container or nginx:nginx in the nginx container, but from the host's perspective it is systemd-timesync:systemd-journal for the same file in both cases.
Of course, the apache container does not have a user nginx and vice versa (neither does the host). So if my PHP script wants to write to a file created by the other container, I have said permission problem.
Fix
The remedy is easy, if at creation time the owner is changed to nobody and permissions to 666.
If not, we cannot change the owner from the other container and get failed to open stream: Permission denied. See https://serverfault.com/questions/772227/chmod-not-working-correctly-in-docker (also see the discussion about changing permissions from host via system call below).
So I wrote a wrapper function str_to_file to add this manipulation:
function str_to_file($str, $filename= "/tmp/tmp.txt", $mode="a+") {
if (!file_exists($filename)){
touch($filename); # create file
chmod($filename, 0666); # the owner can chmod
chown($filename, 'nobody'); # the owner can chown
} # if (!file_exists($filename))
$mode = $mode == 'w'
? LOCK_EX
: FILE_APPEND | LOCK_EX;
file_put_contents($filename, $str . PHP_EOL, $mode);
} # str_to_file
This works for both the apache and nginx containers.
Explanation
How did I get into this mess anyway?
It looks like either I didn't mess it up when on CentOS, so in this case most probably it has nothing to do with my switch to Ubuntu. I cannot remember what I did but I don't remember I had this kind of permission problem on CentOS.
Or CentOS handles files created in a container differently than Ubuntu. I am sure I never saw a user systemd-timesync:systemd-journal on CentOS. Unfortunately I cannot investigate without too much effort what user CentOS would substitute from the host point of view and which consequences this has.
Oh wait, I remember I do have another server running PHP and nginx on CentOS. Creating a file in /tmp from within the container reveals that the owner from both inside the container and from the host is nobody. So there is a significant difference between both Linux versions.
What's more, this insight explains why I experienced this permission problem only after the switch from CentOS to Ubuntu, to which I was forced due to the fact that my provider does not offer CentOS anymore for obvious reasons.
By the way, I first tried the CentOS substitutes AlmaLinux and RockyLinux with bad results of different nature which finally forced me to use Ubuntu. This switch in turn revealed lots of problems, this one being the last, which cost me several weeks so far. I hope that this nightmare ends now.
Acting from cron, the apache version is and was used exclusively, so no problem here.
Testing from the browser lately, I switched by chance and for no particular reason from the apache version to the nginx version and vice versa, creating those described problems.
Actually I don't know why the containers write on behalf of those users. The user of the container is root in both cases, as is standard with docker. I guess it is the browser engine which introduces these users.
Interestingly, when trying to change permissions and ownership via system call after creation, I failed, if I remember correctly, although the user then should be root and root should be capable of doing that.
It turns out that on apache the system user [system('whoami')] is not root but apache, but the file owner is apache where as on nginx the system user is nobody and the file owner is nginx. So changing permissions with system should work on apache [system("chmod 0666 $filename"); system("chown nobody:nobody $filename");], but not on nginx. Alas, it does not work on apache either.
Quick check in apache container:
/tmp # whoami
root
/tmp # ls -la *6_0.ins
-rw-r--r-- 1 apache apache 494 Nov 14 18:25 tmp_test_t6_0.ins
/tmp # su apache chmod 0666 tmp_test_t6_0.ins
This account is not available
Sorry, I can't understand this. And no idea about ACL.
apache vs. nginx
Why do I use both web server versions in the first place?
Well, the process I invoke processes random data which may take a long time, so chances are that nginx times out. This is a well-known nginx feature.
Despite all my studies and obvious instructions, I could not manage nginx to behave. Geez!
Finally, as an appropriate workaround, I introduced apache, which does not have this problem. For decent runtimes it makes no difference, of course.
Well, it looks like I was kind of silly. I'm sure I double checked permissions on /tmp in WinSCP (1777), but I am unsure if I did it in the console.
Now I issued chmod 777 /tmp in the console and there it is! This problem is gone. chmod 666 /tmp reintroduces the problem. chmod 676 /tmp is OK as well.
I googled quite a bit to educate myself about this topic, but frankly I don't understand it. In particular why did I have the problem in the first place and why did ACL not solve the problem? I'd appreciate some enlightenment.
I'm attempting to setup a new webproject based off of the Open Source Point of sale system. I have followed the install steps as I usually do, but when I goto my localhost/webproj I get the following error:
Access forbidden!
You don't have permission to access the requested directory. There is
either no index document or the directory is read-protected.
If you think this is a server error, please contact the webmaster.
Error 403
localhost Apache/2.4.16 (Win32) OpenSSL/1.0.1p PHP/5.6.11
I have checked readonly flags on all files/folders, no problem there.
but there is this line in the readme which I'm having trouble verifying and wondering if that could be the cause.
PHP needs to have php-gd, php-bcmath, php-intl, php-sockets
and php-mcrypt installed and enabled.
how do I check these php 'things' are installed and enabled?
EDIT: Using windows 10. logged in locally as an admin user. Single machine no domain.
CD into your localhost directory using terminal / cmd prompt and check for ownership permissions firstly.
cd localhost (my assumption, you may need to tweak this to where your localhost files are stored) then run ls -ll which will display your permissions and ownership information.
If you find the ownership is wrong run:
chown -R yourUserName:staff webproj/*
You can then run a chmod to be sure:
chmod -R 755 webproj/*
To run a test you could simply chmod the files to 777 to see if this allows entry.
Are you sure there is an index.php in that folder; or whatever is your default directory index? Default permissions are usually good, but there are times you may have to chmod 777 on local dev to make things work. You can check modules with phpinfo(). Create a file, say phpinfo.php, and add just a single line like so: <?php phpinfo(); ?>
Oh, and XAMPP is usually owned by root, at least on nix, so chowning htdocs to your own account will fail.
OK it looks like this was caused by the new application having its index.html in a sub folder. If I launched directly from this sub folder it works. This was done to heighten security in the web application.
I am trying to install RackTables on a Ubuntu Server 13. I have followed all the steps on the documentation. When I get to the step after I connect to the database I cant seem to figure out the ownership settings.
I have set up the database as follows :
mysql -uroot -p
create database racktables;
grant all on racktables.* to root;
grant all on racktables.* to root#localhost;
grant all on racktables.* to rackuser;
grant all on racktables.* to rackuser#localhost;
set password for rackuser#localhost=password('rackpw');
exit
Here is the step that I am stuck on;
RackTables installation: step 4 of 7
Please set ownership (chown) and/or permissions (chmod) of /var/www/racktables/inc/secret.php on the server filesystem as
follows:
The file MUST NOT be writable by the httpd process.
The file MUST be readable by the httpd process.
The file should not be readable by anyone except the httpd process.
The file should not be writable by anyone.
For example, if httpd runs as user "nobody" and group "nogroup",
commands similar to the following may work (though not guaranteed to,
please consider only as an example):
chown nobody:nogroup secret.php; chmod 400 secret.php
I have tried the
chown root:rackuser /var/www/racktables/inc/secret.php
chmod 400 /var/www/racktables/inc/secret.php
I cant figure out how to set up the permissions so that they fall into this category
The file MUST NOT be writable by the httpd process.
The file MUST be readable by the httpd process.
The file should not be readable by anyone except the httpd process.
The file should not be writable by anyone.
Please help. Any suggestion is appreciated
Thank you
First you have to figure out which user and group your web server (Apache/nginx/etc) are running under.
If you're using Apache, you should be able to check by running:
grep -E '^(User|Group)' /etc/apache2/apache2.conf
In Ubuntu, it's common for both user and group to be www-data.
Once you know that, you should be able to change the file's ownership like:
chown [webserveruser]:[webservergroup] /var/www/racktables/inc/secret.php
Example:
chown www-data:www-data /var/www/racktables/inc/secret.php
Keep the chmod the same as you had before.
This should mean it's readable by the www-data user and only the www-data user, writable by nobody (including www-data), which should mean all four of your conditions.
I'm working on a PHP script that runs a Python script on the server. My server is running CentOS 5.4 with Apache 2.2.3 and PHP 5.1.6.
This is the PHP code:
chdir("/home/cjones/git/pywrapper");
$output = shell_exec("python /home/cjones/git/pywrapper/wrapper.py");
This give me this error:
Warning: chdir() [function.chdir]: Permission denied (errno 13) in /var/www/html/wrapper.php on line 20
In the shell_exec call, I've also tried using "cd /home/cjo... && python ...", but that doesn't work.
The script needs to be run from that directory or it starts throwing errors because it can't find the files it wants. If all else fails, I could just hardcode the paths into the python script instead of using relative paths.
This is the relevant output of ls -l for ~/git
drwxrwxr-x 5 cjones cjones 4096 Mar 23 08:45 pywrapper
I had also tried chmod 777 ~/git/pywrapper but that didn't work. The current setting is just 775.
My best guess is that the apache user for some reason doesn't have access to my user's home directory? But I don't know how to allow it to.
It's not enough to change permissions on just the 'git' and 'pywrapper' directories. Apache will need to be able to access 'cjones' as well. Most Linux boxes default to users' home directories being mode 0700. If you don't want to loosen the permissions to the 0777 level and grant global access, you could change the group ownership to a new group that you and apache share, and grant 0770 to /home/cjones, /home/cjones/git, and /home/cjones/pywrapper
It is a better idea to have your web site's directory not be in your home directory, but symlink it to e.g. /var/www/mysite.
That said, you can chmod o+x ~; chmod o+x ~/git; #etc. for the directories and chmod o+r ~/git/pywrapper/blablablabla for the files python needs to be able to read when running as Apache.