I am attempting to set special ACLs on all files and directories in a tree and they don't seem to be honored. I'm running Solaris 5.10. The ACLs are described by 'man chmod'.
I am setting ACLs such that modification of file attributes (A) or file ACLs (W) is not allowed. But still I am allowed to modify them - and once I do, all the special ACLs on a file disappear. For example:
/test> ls -lV filename
-r-x------+ 1 svcdiscprod sasuser 355 Dec 13 09:56 filename
owner#:r-xp-Da-R-c--s:fd----:allow
user:svcdiscprod:r-xp-Da-R-c--s:fd----:allow
everyone#:------a-R-c--s:------:allow
/test> chmod 666 filename # <== This command should be blocked
/test> ls -lV filename
-rw-rw-rw- 1 svcdiscprod sasuser 355 Dec 13 09:56 filename
What is the solution?
Why do you think the command should be blocked?
Per the ZFS Administration Guide:
Setting ACLs on ZFS Files
...
The owner of the file is granted the write_acl permission unconditionally, even if the permission is explicitly denied. ...
Related
I'm trying to sync directories within the same machine, basically copying files from one directory to another directory.
under certain circumstances, the write permission of the destination files will be removed to protect them. However, rsync command seems to ignore the lack of write permission and overwrite all the files in the destination anyway. Any idea why?
Command used(all have the same problem):
$ rsync -azv --delete source/ destination/
$ rsync -azv source/ destination/
version:
rsync version 2.6.9 protocol version 29
destination file permission: -r--r--r--,
source file permission: -rwxrwxrwx,
destination file owner: same owner(not root though),
output:
building file list ... done
sent 101 bytes received 26 bytes 254.00 bytes/sec
total size is 1412 speedup is 11.12
resulting destination file: -rwxrwxrwx
OS:
both macOS(latest) and redhat linux
I called Unix.mkdir "test" 0o000 and expected directory with rwxrwxrwx permissions but had -------w-.
After call Unix.mkdir "test" (Unix.umask 0o000) I have the same result.
I can't understand why.
How to create directory with rwx permissions for all with OCaml Unix module?
The value you specify to Unix.mkdir is the permissions you want the directory to have, as modified by your current umask. If you specify 0o000 you should expect to create a directory with no permissions allowed to anybody. Since the umask can only deny some extra permissions, your reported result is impossible, at least in Unix.
Note that the second parameter to Unix.mkdir is not a umask value, it's a permissions value. The reason the OCaml documentation says to look at umask is so that you realize the specified value will be modified by your umask. It works like this: the directory will be created with the permissions you specify, except that any bit that is set in your umask will be clear in the resulting permissions. In other words, the umask specifies the accesses you wish to be denied by default.
If you really want to create a directory with all permissions allowed to everybody, you'll need to make sure your umask is 0. Here's what happens with a reasonable umask value of 0o022:
$ umask
0022
$ ocaml
OCaml version 4.02.1
# #load "unix.cma";;
# Unix.mkdir "testing1" 0o777;;
- : unit = ()
# ^D
$ ls -ld testing1
drwxr-xr-x 2 jeffsco staff 68 Jul 30 13:43 testing1
The resulting directory has all permissions allowed, except the 0o022 permissions of the umask. (No write permission for group or other.)
Here's what happens if you set your umask to 0 before creating the directory:
$ ocaml
OCaml version 4.02.1
# #load "unix.cma";;
# Unix.umask 0o000;;
- : int = 18
# Unix.mkdir "testing2" 0o777;;
- : unit = ()
# ^D
$ ls -ld testing2
drwxrwxrwx 2 jeffsco staff 68 Jul 30 13:45 testing2
When the umask is set to 0, the permissions of the created directory will be exactly those specified in the call to Unix.mkdir.
I created a user with admin access named hadoop. The funny thing is that when I create a folder and try to give it 777 access it gives me back an error.
hadoop#linux:~$ mkdir testfolder
hadoop#linux:~$ ls -ltra testfolder/
total 8
drwxrwxrwx 25 hadoop sudo 4096 Jun 14 20:00 ..
drwxrwxr-x 2 hadoop hadoop 4096 Jun 14 20:00 .
hadoop#linux:~$ chmod -777 -R
testfolder/ chmod: cannot read directory ‘testfolder/’: Permission denied
Why is that when I am the creator of the directory ?
hadoop#linux:~$ groups
hadoop root sudo
Strangely, using the GUI, I can go in and right click the directory and change the file permissions. Can anyone help me understand what i am not understanding.
Note : I use Ubuntu 14
Your command chmod -777 -R testfolder/ is the issue here, more specific the - as part of the first argument.
Leave it away, just use chmod 777 -R testfolder/ and all should be fine...
Not exactly sure about the details, but the -777 should remove permissions, thus preventing access at least to the recursive portion of the command. I assume that is not what you want to do. Instead you probably want to grant more permissions to the directory. Looks like the command blocks itself. Though that might be by purpose, at least in an indirect manner.
scp -r /Applications/XAMPP/htdocs/keypairfile.pem uploads ec2-user#publicdns:/var/www/html
where uploads is a directory returns Permission denied (publickey).
However
scp -i /Applications/XAMPP/htdocs/keypairfile.pem footer.php ec2-user#publicdns:/var/www/html
works (notice the flag change).
uploads is an empty folder
These are the file permissions for the uploads directory
drwxrwxrwx 3 geoffreysangston admin 102 Nov 15 01:40 uploads
These are the file permissions for /var/www/html
drwxr-x--- 2 ec2-user ec2-user 4096 Jan 5 20:45 html
I've tried changing html to 777 and that doesn't work either.
The -i flag specifies the private key (.pem file) to use. If you don't specify that flag (as in your first command) it will use your default ssh key (usually under ~/.ssh/).
So in your first command, you are actually asking scp to upload the .pem file itself using your default ssh key. I don't think that is what you want.
Try instead with:
scp -r -i /Applications/XAMPP/htdocs/keypairfile.pem uploads/* ec2-user#publicdns:/var/www/html/uploads
Even if above solutions don't work, check permissions to destination file of aws ec2 instance. May be you can try with- sudo chmod 777 -R destinationFolder/*
transferring file from local to remote host
scp -i (path of your key) (path for your file to be transferred) (username#ip):(path where file to be copied)
e.g scp -i aws.pem /home/user1/Desktop/testFile ec2-user#someipAddress:/home/ec2-user/
P.S. - ec2-user#someipAddress of this ip address should have access to the destination folder in my case /home/ec2-user/
If you want to upload the file /Applications/XAMPP/htdocs/keypairfile.pem to ec2-user#publicdns:/var/www/html, you can simply do:
scp -Cr /Applications/XAMPP/htdocs/keypairfile.pem/uploads/ ec2-user#publicdns:/var/www/html/
Where:
-C - Compress data
-r - Recursive
answer for newbies (like me):
I had this error when trying to copy the files while being on the server.
So my answer is: exit, or open another terminal
When I try to install new modules to drupal 7 via "Install new module" form, I get following error message.
The specified file
temporary://fileTFJ015 could not be
copied, because the destination
directory is not properly configured.
This may be caused by a problem with
file or directory permissions. More
information is available in the
system log.
http://ftp.drupal.org/files/projects/date-7.x-1.0-alpha2.tar.gz
could not be saved to
temporary://update-cache/date-7.x-1.0-alpha2.tar.gz.
Unable to retrieve Drupal project
from
http://ftp.drupal.org/files/projects/date-7.x-1.0-alpha2.tar.gz.
My Drupal 7 is installed with CPanel QuickInstall tool and hosted with HostGator shared hosting service.
Any ideas how to solve this issue?
There is an issue with shared hosts and temp folders...if you want the background you can read this:
http://drupal.org/node/1008328
in the meantime try changing your tmp folder to be relative to your sites file root:
sites/default/files/temp
The quickest way to get a handle on this issue is to navigate via your web browser to:
/admin/config/media/file-system
You'll probably see an error there about not being able to write to the /tmp directory. To fix this, you can create a temp directory under site's root and set permissions appropriately.
1) Create a directory here [drupal_installed_here]/tmp
2) Navigate via your web browser to /admin/config/media/file-system and change the temp directory to be:
tmp instead of /tmp (no leading slash)
3) Try this command:
chmod 775 [drupal_istalled_here]/tmp
and refresh the /admin/config/media/file-system page
3) If that does not work, try this command:
chmod 777 /home/quickstart/websites/tmp
and refresh the /admin/config/media/file-system page
The last command opens up your temp directory permissions a lot (rwxrwxrwx), but sometimes that's necessary to get your site working on shared hosts.
This error took me a long time to figure out despite several threads on the internet related to it.
If you get this error on a page, then here are the steps that you need to follow to solve it:
Go to Admin->Reports->Recent Log Messages. Read the most recent error message. This will tell you which folder is causing the problem. It is not necessarily the directory listed in the online threads about this subject. For me it was: sites/default/files/js
If you are running Drupal on a linux server then you need to add read/write permissions to the problem folder. You can do this by going to the linux/SSH command line and typing the following (replace the folder address with the address for your folder)
chmod 777 /var/www/html/sites/default/files/js
That's it. The error message should be gone now.
My old, problematic configuration:
chmod 664 -R /var/drupal-bc/sites/default/files
chmod 664 -R /var/drupal-bc/sites/default/private
drw-rw-r-- 2 www-data www-data 4096 Jul 31 12:35 files
drw-rw-r-- 3 www-data www-data 4096 Jul 5 15:08 private
My new, functional configuration:
chmod 774 -R /var/drupal-bc/sites/default/files
chmod 774 -R /var/drupal-bc/sites/default/private
drwxrwxr-- 2 www-data www-data 4096 Jul 31 12:35 files
drwxrwxr-- 3 www-data www-data 4096 Jul 5 15:08 private
Please do not use 777 permissions, because you will have security problems. 775 will do just fine.
chmod 775 -R /var/drupal-bc/sites/default/files
chmod 775 -R /var/drupal-bc/sites/default/private
If you have javascript caching turned on, you might need to 755 the /sites/all/your-theme/js
chmod 777 /var/www/html/sites/default/files/js
solved the issue for me