I have a folder on my websites calld /administrator/cron - in it I place php files and then in the cron tab I have something like:
* * * * * php -f "/home/cpm394/public_html/administrator/cron/mailqueue.php"
which USED TO WORK a few months ago.
(BTW this is on a dedicated Linux server with Hostgator)
in the website I have some symbolic links as follows:
ln -s /home/phplib/public_html/functions functions
SO... here's the problem:
the script in mailqueue.php requires a file as follows:
require('/home/cpm394/public_html/functions/config.php');
In response, I get a message that the file does not exist (and it does, I have checked it).
Is this a permission problem? I would normally expect to get "permission denied" vs. "file does not exist"
Cronjobs are often sensitive to relative paths. If you are using them anywhere, try using the full absolute paths instead.
Related
From time to time I run into this error when trying to get a Let's Encrypt certificate via the acme.sh script.
Sometimes it's the first time trying to get a Let's Encrypt certificate, and sometimes it worked previously but now suddenly doesn't work.
The error message is similar to:
domain.com:Verify error:Invalid response from https://example.com/.well-known/acme-challenge/1kSTnls6_vcku98gwLEUMQNnbl1cSY1pdBrPi7sJdos
Please add '--debug' or '--log' to check more details.
See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
Adding the --debug option, reveals some log entries similar to:
Changing owner/group of .well-known to username:nobody
chown: changing ownership of /home/path/to/example.com: Operation not permitted
What's the solution?
Hopefully this will save others some time googling, or poring over the documentation, or reading through the closed GitHub issues.
First thing to check: does the website folder have an .htaccess file in it?
(By "website folder" we mean where the actual website files are stored, such as /home/youruser/public_html/path_to_your_domain.com
(Note that dot files like .htaccess are hidden by default in CPANEL file manager, so you might need to use an FTP app to check - or enable showing hidden files in the CPANEL file manager (there is a Settings button at top right))
If so:
a) Rename the .htaccess file (to .xxxhtaccess or etc)
b) re-run the acme.sh script
c) When successful, rename the .htaccess file back again
Some References:
acme.sh GitHub Issues
acme.sh Documentation
Got an odd Serverpilot query not specifically Craft related
My client wants FTP access to a subfolder on the site - loathe to let them have full access so created a user with access to /home/FTPUSER and symlink to this from my /srv/users/serverpilot/apps/APPNAME/public/ folder so that they cannot access the site's core system files, etc from a script.
PHP files from this folder are working fine but the client now wants to be able to run CGI/Perl scripts from this folder. I have tried following instructions at https://serverpilot.io/community/articles/how-to-create-a-cgi-bin-directory.html (updating the document root) but can't get CGI or Perl scripts to run, instead being returned as plain text.
Any thoughts?
On a mac in terminal when executing:
chown apache uploads/
I get the error:
chown: apache: Invalid argument
The foder is on a shared web server. I need to change the owner of the folder because otherwise my PHP script for creating simple text files will return a permission denied error. Please don't suggest chmodding the folder to 777 (which does work), since almost all advice against it.
Is it possible that the server doesn't run scripts as the user 'apache'? How can I find this out?
"Invalid argument" makes me think this directory is on an HFS+ volume with owners disabled; you won't be able to change it in that case. You may be able to switch owners on, although it's possible that requires reformatting.
(The advice to check /etc/passwd is wrong, or at least inaccurate, on OS X; you need dscl . list /Users.)
There are two things you might want to check:
1) Is there a user called apache? Maybe it's httpd. You can search /etc/passwd. (Or whatever your platform uses to store user names, you didn't mention your operating system.)
2) What user do scripts run as? You can check this by running a test script. For example:
#/bin/bash
echo Content-Type: text/plain
echo
id -a
If you save this as test.cgi and put it in a CGI directory, you should be able to run it and get it to tell you what user it's running as.
I have to sync some folders from a linux server, to another.
We have created the RSA-Key and the authentication goes well.
When we launch an rsync command, some of the files gave birth to errors like:
rsync: readlink "/var/www/sestantemultimedia.it/xxecommerce/pub/.htaccess" failed: Permission denied (13)
Now, the directory /var/ (as well as other subdirectory) have the permits set to 755.
The files into the last directories have permits set like 644.
So, theoretically, permits as set right and I can read from the other server and copy my files.
What I am missing?
Ok, I just figured it out.
Someone (because we work together as a team) had done a change on the "final folder" so that "apache" user's group can't execute (so can't traverse) the folder itself.
In that way, although it is possibile for "other group" to execute, the sum of permits that we receive (we were into "apache" group) isn't enough for "execute" the folder and retrive the file.
We just change that scenario and now it works properly!
Trying to setup a Cron task that gets a file via FTP however seems to fail due to file permissions.
Code runs perfect in the browser, ie when apache is the owner, however fails when Cron runs the same page.
I'm assuming this is a directory/file permission error, if so who should I set the directory owner too for Cron jobs?
Most likely Dan's thought is going to be your problem. However if it works from a browser you can also call the page like this:
wget -q "http://www.domain.com/path/to/script/script.whatever" >/dev/null 2>&1
if you still get errors you can remove the >/dev/null 2>&1 part & [if your email address is in the domain administrator account correctly] output, including errors should get emailed to you.
As for the correct permissions, don't change the default plesk ones or you will get issues with normal ftp.
Defaults are:
everything under httpdocs = ftpuser.psacln
anything written by php/apache = apache.apache ~ unless you are running php as a cgi on that domain,, then they will belong to the ftp user as well.
-sean
cron jobs will run as the user that created them. More likely than a permissions error is a path error. If you're not specifying full absolute paths to the program/script to run, and to any files you reference, you'll likely have problems as cron won't have the same PATH in its environment as Apache does or you do at your shell prompt.