chmod: cannot read directory `.’: Permission denied [closed]
I am trying to recursively change the permission of directories and sub-directories for «data» directory and running into following error..can someone provide inputs on the below error?
chmod -R 0644 . chmod: cannot read directory `.': Permission denied @Blender: sudo chmod -R -644 . will remove execute (search) permission from the current directory and all directories under it — not a good idea.
2 Answers 2
Directories need the execute permission set in order to see their contents.
You can think of read and execute on directories this way: directories are data files that hold two pieces of information for each file within, the file’s name and it’s inode number. Read permission is needed to access the names of files in a directory. Execute (a.k.a. search) permission is needed to access the inodes of files in a directory, if you already know the file’s name.
When you change a directory permission to 644, you are unable to read the files in that directory although you can read that directory to see it exists.
A better way might be to use string permission if you simply want to turn off
Otherwise, you can see the directory, but not access the information in that directory.
You maybe better off using relative permissions instead of absolute permissions:
Will remove write permission from group and other, but not touch execute permission.
You can also use find just to set the directories or just to set files:
$ find . -type d -exec chmod 755 <> \; This will only touch directories, setting read and execute permission on all directories and setting write permission for the owner. This way, you’re not setting execute permission on files themselves.
Permission denied to a 777 file
The application usually starts from a uwsgi server using www-data as a user. However, sometimes I manually run it (with python manage.py ) via my user — tvelichkov . The problem is that when I try to start it from my user, I got a Permission denied error to /tmp/db.log file since www-data has already created it (removing the file can temporary fix the issue, but then the server will receive the same error, since now my user owns the file).
PermissionError: [Errno 13] Permission denied: '/tmp/db.log' $ members www-data www-data tvelichkov $ ls -l /tmp/db.log -rwxrwsrwx 1 www-data www-data 22102 юли 30 15:25 /tmp/db.log But I still keep getting this Permission denied error. Any help would be appreciated. Note: I used to have no issues with this setup in Ubuntu 18.04, but now I have it in Ubuntu 20.04. UPDATE: Here are the permissions of the /tmp/ folder, but note that this is after I ran chown root:root /tmp and chmod 777 /tmp as suggested by @adrian vera, BTW after this change seems like chmod 777 /tmp/db.log is working, because I no more get the Permission denied error. Is it possible that Ubuntu changed something for the /tmp/ folder between versions 18.04 and 20.04 ? Because I’m pretty sure I didn’t change anything to this folder before running into this issue?
$ ls -l / | grep tmp drwxrwxrwx 24 root root 4096 авг 3 10:19 tmp Note2: I have one more machine with clean Ubuntu 20.04 install where I have this issue too, I will double check the permissions there too once I got home. UPDATE2: So on a clean Ubuntu 20.04 install the permissions of the /tmp/ folder are:
$ ls -l / | grep tmp drwxrwxrwt 23 root root 12288 авг 3 16:41 tmp $ ls -l /tmp/db.log -rw-r--r-- 1 www-data www-data 0 авг 3 16:54 /tmp/db.log $ sudo chmod 777 /tmp/db.log $ ls -l /tmp/db.log -rwxrwxrwx 1 www-data www-data 0 авг 3 16:54 /tmp/db.log $ lsattr /tmp/db.log --------------e----- /tmp/db.log $ whoami tvelichkov $ getent group www-data www-data:x:33:tvelichkov $ python manage.py test --settings=cs.settings.test Traceback (most recent call last): File "/home/tvelichkov/.pyenv/versions/3.6.10/lib/python3.6/logging/config.py", line 565, in configure handler = self.configure_handler(handlers[name]) File "/home/tvelichkov/.pyenv/versions/3.6.10/lib/python3.6/logging/config.py", line 738, in configure_handler result = factory(**kwargs) File "/home/tvelichkov/.pyenv/versions/3.6.10/lib/python3.6/logging/__init__.py", line 1032, in __init__ StreamHandler.__init__(self, self._open()) File "/home/tvelichkov/.pyenv/versions/3.6.10/lib/python3.6/logging/__init__.py", line 1061, in _open return open(self.baseFilename, self.mode, encoding=self.encoding) PermissionError: [Errno 13] Permission denied: '/tmp/db.log' Permissions denied on files despite 777 mode
I am getting a permission denied error on CentOS 6.10 64 bit Kindly note that the «#» indicates a Root Level User prompt.
# cd /tmp # chmod 777 file* # /bin/ls -l file* -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_00.dat -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_01.dat -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_02.dat -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_03.dat -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_04.dat -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_05.dat -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_06.dat -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_07.dat -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_08.dat -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_09.dat -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_10.dat -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_11.dat -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_12.dat -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_13.dat -rwxrwxrwx 1 apache apache 824 Sep 17 17:15 file_14.dat -rwxrwxrwx 1 apache apache 1 Sep 17 17:15 file_15.dat # cat file* > file.dat cat: file_00.dat: Permission denied cat: file_02.dat: Permission denied # /bin/ls -l file.dat -rw-rw-r-- 1 root root 10713 Sep 17 17:32 file.dat The size of the full file is 10713, which is 824*13+1, meaning it was, successfully, copied every file except the files «00» and «02». A successful copy should be 12361 bytes, 824*15+1. However, there is nothing different about these two files, except that the machine refuses to let me read them. The command «chmod 777» is redundant, just to emphasize the situation. Before running that command, permissions were all in the form «-rw-r—r—«, which still means that I should not be getting a permission denied error. There is no «.» on the permissions, so theoretically, Selinux should not be involved, but even if it is involved, why is it only picking on just two files? I can repeat the process that creates these files, and it will choose a different set of files to be unreadable. Does anybody have an explanation and fix for this? UPDATE: I have modified the process that creates the files. Previously it was receiving the data from a JavaScript client that broke an XLSX file into chunks to allow uploading spreadsheets of massive size. The server would receive the chunks as base64, decode each chunk to binary, then save it in a temporary file to be concatenated into a final XLSX file. What it does now is save each temporary chunk as base64 (100% ASCII). Once all the chunks are uploaded, it reads each file, then decodes it to binary, and appends it to the final XLSX file. Works fine. I think we’ll leave it that way. As a test, I wrote a quick 3 line program to read one of the base64 chunks, decode it to binary, then save it. Then I tried to read result. Guess what? Permission denied on the binary file. So apparently, what makes the file unreadable is some pattern of data inside the file. Using this method resolves the issue, but I still would like to know how a pattern of binary data inside a file creates a «Permission denied» error on the outside.
chmod 777 is not changing the permissions to 777
I’m trying to change the permissions of temp_dir to 777. Why are these commands not accomplishing that? I’m using Linux by the way.
kylefoley@kfoley76:/mnt/disks$ chmod 777 /mnt/disks/temp_dir kylefoley@kfoley76:/mnt/disks$ stat -c "%a %n" temp_dir 755 temp_dir kylefoley@kfoley76:/mnt/disks$ chmod -v 777 /mnt/disks/temp_dir mode of '/mnt/disks/temp_dir' changed from 0755 (rwxr-xr-x) to 0777 (rwxrwxrwx) kylefoley@kfoley76:/mnt/disks$ stat -c "%a %n" temp_dir 755 temp_dir kylefoley@kfoley76:/mnt/disks/temp_dir$ sudo chmod 777 fix_mistakes chmod: cannot access 'fix_mistakes': Permission denied kylefoley@kfoley76:/mnt/disks/temp_dir$ sudo -i root@kfoley76:~# sudo chmod 777 /mnt/disks/temp_dir chmod: cannot access '/mnt/disks/temp_dir': Permission denied I should also add that this bug must have something to do with the fact that the directory in question is a gcsfuse mounted disk, available from gcloud. Other attempts to change permissions worked fine:
kylefoley@kfoley76:~$ mkdir hey kylefoley@kfoley76:~$ stat -c "%a %n" hey 755 hey kylefoley@kfoley76:~$ chmod 777 hey kylefoley@kfoley76:~$ stat -c "%a %n" hey 777 hey deduction1 on /mnt/disks/temp_dir type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1001,default_permissions)
Note that chmod 777 should never be run. The number of circumstances where world writability does not seriously damage the UNIX security model (particularly given existence of accounts like nobody used to sandbox execution of untrusted code) are very few.
2 Answers 2
gcsfuse sets file and directory permissions when mounting. Specifically, the options are:
- file_mode – Permission bits for files, in octal
- dir_mode – Permissions bits for directories, in octal
If you do not specify the options, the defaults are dir_mode=0755,file_mode=0644 .
These options apply to all files and directories in the mount. This FUSE file system does not have the capability of changing permissions for specific files or directories, which is why chmod does nothing.
Furthermore, gcsfuse has additional access restrictions that limit access to the user who mounted the file system. Details:
As a security measure, fuse itself restricts file system access to the user who mounted the file system (cf. fuse.txt). For this reason, gcsfuse by default shows all files as owned by the invoking user. Therefore you should invoke gcsfuse as the user that will be using the file system, not as root.
If you know what you are doing, you can override these behaviors with the allow_other mount option supported by fuse and with the —uid and —gid flags supported by gcsfuse. Be careful, this may have security implications!
This is why you aren’t able to access the mount from another user. To allow other users to access the mount, specify allow_other in your mount options.