Tag Info

New answers tagged

1

Example of changing all the directories to 755 (-rwxr-xr-x): find /opt/lampp/htdocs -type d -exec chmod 755 {} \ Example of changing all the files to 644 (-rw-r--r--): find /opt/lampp/htdocs -type f -exec chmod 644 {} \; This would make all the files executable, while not unnecessarily setting execute permissions on the directories themselves. Credit ...


2

When sticky bit is set, only the file's owner, the directory's owner, or root can rename or delete the file. The sudo command is there to enable a user to impersonate another user, including root. When user2 issues a command through sudo to become root, he's getting root's permissions, and root always has all permissions on the system.


0

In fact it seems that the system was more affected that the log was saying! maybe because of the dev folder, maybe symlinks... don't know but after crawling forums etc and trying folder by folder, I finally saved the server with for package in $(rpm -qa); do rpm --setperms $package; done A special thx for @Gilles and his superb answer A special NO Thx! ...


1

Talked to the infrastructure people, and the answer is that there are extended ACLs in place that act differently based on location, and that they were erroneously set.


0

The only time I have seen this kind of scenario is when the NFS share is exported from a Windows server running NFS for Windows services. The POSIX attributes demanded by the Unix/Linux world aren't mapped cleanly onto the NTFS attributes and the result is that permissions display one thing and (sometimes) act as another. In our particular situation we ...


-1

If the sticky bit chmod +s is set on the folder, the umask is overridden with the attributes of the folder owner. that is why you may be seeing inconsistent results between folders.


4

When you make any changes to filesystem in recovery root shell , you have to remount the partition with read write permissions, mount -o remount,rw / . Then you can proceed with changing permissions of root directory


4

Without something like SELinux, root can always write to files; since you're running as root you can always write. If you're not running as root, then the permissions apply; if file exists and is not writable, then > file or >> file will fail. If file does not exist, then it will be created if the parent directory is writable.


2

You should be able to restore permissions from a root shell, if you manage to start one. You should be able to get a root shell by logging in as root on the console. At this point, depending on your configuration, you may or may not be able to gain root access from an ordinary account with su or sudo, and you probably won't be able to log in under any ...


2

Assuming you are running Linux with Grub as bootloader: Boot into Boot Linux Grub Into Single User Mode Login with the root account Execute chmod 755 /etc Reboot the system I'm not sure if you can go beyond point 2. If it's not possible to login as root (which in fact should be, since the process which asks you for your password should have access to the ...


1

chmod -f 777 file.txt || true As it's an OR, if one of the statements returns true, then the the return is true. This results in an exit status of zero.


1

When you change a file's metadata (permissions, ownership, timestamps, …), you aren't changing the directory, you're changing the file's inode. This requires the x permission on the directory (to access the file), and ownership of the file (only the user who owns the file can change its permissions). I think this is intuitive if you remember that files can ...


1

I really dislike unexplained {} and \ markup and don't care much for the ; either! In the alternative, if the {} and \; are overly troublesome, there is an alternative approach. In addition, this approach handles spaces in the file name better than the find ... -exec formulation. find . -type d -print0 | xargs -0 chmod MASK find . -type f -print0 | ...



Top 50 recent answers are included