I have a simple question about chmod permissions. What is the difference between writing and read+write? Doesn’t writing assume that you are reading the file in order to write it?
To test my theory, I created two files:
test200.txt
test600.txt
I proceeded to set chmod 200 for test200.txt,
and chmod 600 test600.txt.
vim inserting a gibberish string, writing and quitting, and then
reading the two files with the more command worked perfectly in both instances.
What am I missing out here?
Thanks,
Aaronson
I'm pretty sure you did something wrong in your test, maybe you didn't set the permissions to 200 and 600, because what you described shouldn't be possible. Maybe you gave your self rights implicitly by using sudo -i.
Example:
touch file600 file200
chmod 600 file600
chmod 200 file200
echo "content for file600" > file600
echo "content for file200" > file200
more file600
more file200
Output:
content for file600
more: cannot open file200: Permission denied
Apart from that the difference between w and r+w is that you can of course just write in the case of w, but you can delete the file. So in some strange cases it might be useful to set this.
Related
anyone can please tell me how you set permission 777 on serverfree.com because i am seen there and there is not any option to set permission and unable to set permission via web based ssh.
please tell me how you set permission.
actually everythis is fine on serverfree.com but i am unable to set cron, someone tell me it's permission issue , but i don't know how to set permission on serverfree.com without SSH ?
Usually, you are able to set the permissions via your FTP-Client.
e.g. in FileZilla there is an option "File permissions..." where you can set the permission values for each file.
You're on a *nix System, right?
If you only want set permissions without calling chmod directly(as your question suggests), you can try following on the console, if you have Perl installed:
perl -e 'chmod 0777, "Filename"'
Another approach is to use the install utility which is a glorified copying program which can set permissions in one step. (See the -m argument.)
install -m 777 "File" "/Copy/Location"
You can find it in the GNU coreutils(if you have it installed there), and isn't directly included to *nix systems(but BSD for example). Also simple move the file out of directory and call install to move it back.
But for both methods you need SSH, and i don't think there is a solution to set permissions without(because you never can do the chmod() system call that you need to set them).
How can I change the owner of the files written by php from terminal (command line)? The files are created by upload form in apposite folder.
Many thaks
Use the command "chown":
chown owner filenames
To solve this problem in the future uploads, you can use the chown command:
chown($path, $user_name);
http://php.net/manual/en/function.chown.php
There is also a chmod command, if you prefer to change permissions:
http://www.php.net/manual/en/function.chmod.php
Maybe you can change the owner within the PHP program itself (of course if you have the permission to do that) with the exec command of PHP.
For example:
exec('whoami');
See the documentation of this php instruction here: http://php.net/manual/en/function.exec.php
This could work, but only if the servers configuration allows so.
If this doesn't work, you can try also this, but again you need some priviledges to do it:
// File name and username to use
$file_name= "foo.php";
$path = "/home/sites/php.net/public_html/sandbox/" . $file_name ;
$user_name = "root";
// Set the user
chown($path, $user_name);
See the documentation of this php instruction here: http://php.net/manual/en/function.chown.php
There are some instructions in php to modify file attributes like, chmod, chown, among others.
I have set up a php file to run that just echos hello.
<?php
echo hello;
?>
My cron job looks like this:
/usr/local/bin/php -f “/home/username/public_html/mls/test.php”
when my script runs i get a confirmation email that says:
Could not open input file: /home/username/public_html/mls/test.php
I don't know what is causing this. I am using godaddy's virtual private server with cpanel x installed. I have used the ssh to set permissions 777 on folder and file and still can not get it to run.
Any advice would be helpful. Thanks.
For some reason PHP cannot open the file. Try replacing /usr/local/bin/php -f with "ls -la" to try to crib some more information. Remember to NOT quote the file name in the crontab: php -f filename.php, not php -f "filename.php", unless it contains spaces -- and then it's better to use single quotes.
Possibly, try "ls -la /home", "ls -la /home/username", "ls -la ~/public_html" and so on.
Also try appending
2>&1
to the command line, in case only stdout is mailed to you (I don't really think so, but being sure costs little).
One other possibility
The crontab as it is refers /home/username/public_html/mls/test.php - that is, a public HTML directory inside username's commonest value for a home directory.
It is possible that the cron job is either not running with the appropriate user and privileges, or that the user it "sees" is actually a virtual user - there is no "/home/username" at all - and the "home directory" is elsewhere, possibly even existing just as long as the cron job runs. In this case the solution might be to refer to
~/public_html/mls/test.php
or, as described above, to first run a command such as pwd or ls -la to determine exactly where the cron job's current working directory is.
If this, too, fails, then another workaround could be to invoke the PHP HTTP handler via curl or lynx:
/usr/bin/curl http://www.thishostname.com/mls/test.php
Possibly using either some environment variable or curl header or _GET option to authenticate to the script as the cron job, and avoid it being accessible from the outside.
I'm attempting to pipe an email to PHP with my Postfix mail server, using the technique mentioned here and have encountered the following error...
Mar 16 22:52:52 s15438530 postfix/pipe[9259]: AD1632E84C63: to=<php#[myserver].com>, relay=plesk_virtual, delay=0.61, delays=0.59/0/0/0.02, dsn=4.3.0, status=deferred (temporary failure. Command output: /bin/sh: /var/www/vhosts/[myserver].com/httpdocs/clients/emailpipe/email2php.php: Permission denied 4.2.1 Message can not be delivered at this time )
I'd really appreciate if anyone could shed some light on this issue for me. I've tried 777'ing the emailpipe directory, to no avail. Where am I going wrong?
Many thanks.
From the postfix docs...
For security reasons, deliveries to command and file destinations are performed with the rights of the alias database owner. A default userid, default_privs, is used for deliveries to commands/files in root-owned aliases.
So you have two options, either set the default_privs in main.cf to match the ownership of the email2php file.
Alternatively, there should be a way to create an alias database that is owned by the user instead of postfix/nobody. I haven't tried this before though so can't advise.
I have fixed this issue by disabling the SELINUX.
Make sure that you have
#!/usr/bin/php
<?php
(or whatever your path to php is - do "which php" on the server)
at the top of each of your php scripts and that each of the php script files is executable
chmod +x /var/.../email2php.php
Also, make sure that you can test the script from the command line:
cat some_rfc822_email.txt | /var/.../email2php.php
and get the result that you want
To fix this issue, you'll want to chown or chmod /var/www/vhosts/[myserver].com/httpdocs/clients/emailpipe/email2php.php to executable by your postfix user. Alternately, you'll want to redefine this user to execute the file successfully.
Simply changing the permissions of your directory (unless you used -R) won't be sufficient.
To illustrate why this works, consider the following toy example:
<me>#harley:~$ touch test
<me>#harley:~$ ls -al test
-rw-r--r-- 1 <me> <me> 0 2012-03-26 23:44 test
<me>#harley:~$ sh test
<me>#harley:~$
<me>#harley:~$ ./test
bash: ./test: Permission denied
<me>#harley:~$ chmod 755 test
<me>#harley:~$ ./test
<me>#harley:~$
In order to execute a file directly through the running shell, it needs to be set as executable. Other invocations (for example, sh email2php.php or php email2php.php) only require read access, because they're chaining execution off a different file entirely.
For what's likely to be causing the issue in the first place, see here.
Have never used sass before.
On my production server having to switch chmod 644 public/* then run /etc/init.d/apache2 restart to restart the server.
Once server has rendered the css, I then have to come back and run chmod 755 public/* to actually load the css, js and images.
If 755 has higher creds, why does it fail?
actual error is:
Errno::EACCES (Permission denied - /srv/www/mysite.com/myapp/public/stylesheets/custom.css):
Use this Command : chmod 766 -Rf public/. it might be work for you
I know you already got your answer, but if you want to know more of the theory behind it, check this out:
http://www.thinkplexx.com/learn/article/unix/command/chmod-permissions-flags-explained-600-0600-700-777-100-etc
It's pretty straight-forward... I think it's definitely worth glancing at.
Also, in case you don't already know, the -f option only told chmod to not display a diagnostic message if it couldn't modify the file, so it wasn't totally necessary (though it could be helpful). The -R switch changed the modes of the file hierarchies rooted in the files rather than the files themselves.