Permission denied linux при удалении

Permission Denied при попытке что-либо удалить\изменить\залить по SFTP. В чём неправ?

Здравствуйте. Решил, вот, на Debian Jessie отказаться от FTP в пользу SFTP. Для этого создаю группу:

и помещаю в неё пользователя:

useradd oleg -G sftpusers -m -d /home/oleg -s /bin/false

Задаю пароль для пользователя:

Указываю владельца и права доступа к директории пользователя:

chown root:oleg /home/oleg chmod 750 /home/oleg

В файле /etc/ssh/sshd_config добавляю пользователя в список разрешённых к подключению:

AllowUsers sferg oleg AllowGroups sferg oleg

В том же файле заменяю параметр:

Subsystem sftp /usr/lib/openssh/sftp-server

Subsystem sftp internal-sftp

Далее, в конец того же файла добавляю строчки:

Match Group sftpusers ChrootDirectory %h ForceCommand internal-sftp

Теперь подключаюсь через SFTP с помощью Midnight Commander — список файлов получаю. Однако, не удаётся ни удалить файл, ни отредактировать, ни залить. Permission Denied. В чём неправ?

P.S. Пробовал подключаться с помощью WinSCP — та же история: файлы пользователя видны, но удалить\отредактировать\залить ничего нельзя.

P.P.S. Понимаю, что косяк с правами доступа, но что-то не могу сообразить, где именно.

Обратил внимание, что имеющиеся файлы редактировать-таки можно. Нельзя заливать новые и удалять имеющиеся.

Источник

Why can’t I delete this file as root?

I have directory exam with 2 files in it. I need to delete files but permission is denied. Even rm -rf command can’t delete these files. I logged in as a root user.

(1) Please post text from the Terminal as text if at all possible. Ideally, copy and paste it. If you have no way of capturing the text except manually transcribing it, then do that, but disclose that you are doing it, and include the screen capture image so we can double-check your typing. (2) When you have a question about permissions, please, always, do ls -la , so we can see the permissions on . (the directory).

2 Answers 2

From root user check attributes of files

if you notice i (immutable) or a (append-only), remove those attributes:

# man chattr # chattr -i [filename] # chattr -a [filename] 

Wow, that was a tricky one. Thank you for posting this solution; I was at my wits’ end. I was pretty sure that this was somehow related to my unison synchronisation; it was left in an ‘unknown’ state (due to many reasons), and this meant that those directories I couldn’t delete were set (by unison) to be append-only (this is typical of unison). But I had no clue how to view/reset that append-only mode! You were a lifesaver; I hope the original poster also had their problem solved.

And five years later, I stumble upon the same issue, and fortunately, your answer was still here to save my troubled life. @Invoker thank you again and again!

The most common reason for rm complaining that you don’t have permission to delete a file, is that the permissions on the directory forbid you from deleting the file. In order to delete a file, you need write permission on the directory. The permissions on the file are irrelevant ( rm without -f prompts for confirmation before deleting a read-only file, but that’s just a confirmation, not a limitation). On some Unix variants such as OSX (but not Linux), the ACL on a file can prevent its deletion; ls -l would show @ at the end of the permission field if there was an ACL entry on the file.

Access as root bypasses permissions, so root can delete files even in a read-only directory.

The output from ls -l shows a . at the end of the permission column. This indicates that the file has an SELinux security context. Unlike basic permissions and ACL, the SELinux security context on a file can control who is allowed to delete it. Furthermore SELinux cannot always be bypassed by root (it’s possible to have a process running as user ID 0 but with as few rights as the SELinux policy designer chose). To see what the SELinux context allows you to do, run ls -lZ . exam_a .

Another thing that can prevent a file from being deleted is if it or the directory that contains it has the append-only or immutable Linux attribute. Run lsattr -d . exam_a to view the Linux attributes. If the a or i attribute is on, you’ll need to remove it ( chattr -a -i . exam_a ) in order to delete the file; only root can do that. Root cannot bypass these attributes to delete a file, the attributes have to be turned off first.

Yet another thing that prevents a file from being deleted is if the filesystem is mounted read-only, but you’d get a different error message in that case.

Источник

Permission Denied To Delete File

First of all, I’m not looking for an answer on how to remove the files. I am looking for a reason why this doesn’t work — and a suggestion on how to remove the files without sudo. I have a directory in my Desktop that has a few inner directories (don’t judge the naming — I just extract what I need from files I’m given) and after getting the files I try and remove the files with rm -rf Bengal\ Tiger\ Creative/ , I am surprised to see the following warning for each image.

rm: cannot remove ‘Bengal Tiger Creative/Bengal Tiger Creative/images/customer-services-landscape.jpg’: Permission denied

nathan@nathan-pc:~/Desktop$ tree . ├── Bengal Tiger Creative │ └── Bengal Tiger Creative │ └── images │ ├── awards.jpg │ ├── blank.gif │ ├── bullet1-light-green.gif │ ├── bullet2-light-green.gif │ ├── bullet3-light-green.gif │ ├── bullet4-light-green.gif │ ├── customer-services-landscape.jpg │ ├── desktop.ini │ ├── header-img1.jpg │ ├── header-img2.jpg │ ├── header-img4.jpg │ ├── header-img5.jpg │ ├── softhr.gif │ ├── Thumbs.db │ ├── tiger_main-img1.jpg │ ├── tiger_main-img2.jpg │ ├── tiger_main-img3.jpg │ ├── tiger_main-img4.jpg │ ├── Vanquis-benefits-icons_iphone-green.gif │ └── white-arrow-green.gif 

nathan@nathan-pc:~/Desktop$ ls -laR Bengal* Bengal Tiger Creative: total 12 drwxrwxr-x 3 nathan nathan 4096 Aug 10 11:30 . drwxr-xr-x 6 nathan nathan 4096 Aug 10 11:34 .. drwxrwxr-x 3 nathan nathan 4096 Aug 10 11:34 Bengal Tiger Creative Bengal Tiger Creative/Bengal Tiger Creative: total 12 drwxrwxr-x 3 nathan nathan 4096 Aug 10 11:34 . drwxrwxr-x 3 nathan nathan 4096 Aug 10 11:30 .. dr-xr-xr-x 2 nathan nathan 4096 Aug 10 11:36 images Bengal Tiger Creative/Bengal Tiger Creative/images: total 356 dr-xr-xr-x 2 nathan nathan 4096 Aug 10 11:36 . drwxrwxr-x 3 nathan nathan 4096 Aug 10 11:34 .. -rwxrwxrwx 1 nathan nathan 14910 Mar 18 12:29 awards.jpg -rw-rw-r-- 1 nathan nathan 1093 Mar 21 2014 blank.gif -rw-rw-r-- 1 nathan nathan 1978 May 8 2014 bullet1-light-green.gif -rw-rw-r-- 1 nathan nathan 1969 May 8 2014 bullet2-light-green.gif -rw-rw-r-- 1 nathan nathan 2416 May 8 2014 bullet3-light-green.gif -rw-rw-r-- 1 nathan nathan 2449 May 8 2014 bullet4-light-green.gif -rw-rw-r-- 1 nathan nathan 113138 Apr 14 2014 customer-services-landscape.jpg -r--r--r-- 1 nathan nathan 142 Mar 25 11:58 desktop.ini -rw-rw-r-- 1 nathan nathan 14312 Mar 23 11:39 header-img1.jpg -rw-rw-r-- 1 nathan nathan 1480 Mar 23 11:41 header-img2.jpg -rw-rw-r-- 1 nathan nathan 1278 Mar 23 11:41 header-img4.jpg -rw-rw-r-- 1 nathan nathan 1168 Mar 23 11:41 header-img5.jpg -rw-rw-r-- 1 nathan nathan 1703 Mar 21 2014 softhr.gif -rw-rw-r-- 1 nathan nathan 88064 Aug 4 10:39 Thumbs.db -rw-rw-r-- 1 nathan nathan 23607 Mar 23 11:56 tiger_main-img1.jpg -rw-rw-r-- 1 nathan nathan 23400 Mar 23 11:56 tiger_main-img2.jpg -rw-rw-r-- 1 nathan nathan 6970 Mar 23 11:56 tiger_main-img3.jpg -rw-rw-r-- 1 nathan nathan 8996 Mar 23 11:57 tiger_main-img4.jpg -rw-rw-r-- 1 nathan nathan 275 Jul 31 2014 Vanquis-benefits-icons_iphone-green.gif -rw-rw-r-- 1 nathan nathan 1821 Jul 9 2014 white-arrow-green.gif 

Doing chmod 777 and then delete does not work.
Doing rm -rf * inside the directory does not work.
Doing sudo rm file does work. I can easily remove these files using sudo, however, I cannot see why they cannot be removed without sudo. As a relatively new Ubuntu user, I would like to learn why. Thanks in advance,
Nathan

Источник

rm: cannot remove directory/: Permission denied

Here the problem is you do not have «w» permission on the /home directory. While deleting a file note that you are not writing to that file but you are changing the contents of the directory that contains the file, so having «w» permission on the directory is a must if you want to delete any file from the directory.

If I am in a directory with «w» permission, I can delete any of its files without being worried about the file permission itself. Note that my present directory is /home/rohith which has «w» permission and hence I can delete any of its files irrespective of the file permissions.

If the same file is created in the ‘/home’ directory which has no «w» permission I get the same output as yours ! 🙂

The restricted deletion flag or sticky bit ‘t’ on a folder would also prevent deleting «it prevents unprivileged users from removing or renaming a file in the directory unless they own the file or the directory; this is called the restricted deletion flag for the directory, and is commonly found on world-writable directories like /tmp. For regular files on some older systems, the bit saves the program’s text image on the swap device so it will load more quickly when run; this is called the sticky bit.»

This happens because you don’t own the directory, it is owned by ‘root’ and the ‘root’ group. So to delete it you can either changing the ownership and then delete it (here you elevate your rights and become ‘root’ for taking the ownership):

sudo chown $USER:$USER ./shadi rm -r ./shadi 

Or you skip taking the ownership and make a sudo rm to elevate your rights and become ‘root’ for the deletion:

Yes, or you need to elevate your rights with the sudo command. this will ask for your password then and you become ‘root’ for the particular following command.

do you now if «shadi» was a file i can remove it with «sinoosh» user .it is not require «sudo » its not make scene for me why it does not work with directory

The permissions show owner root and group root, so you have to use sudo.

Yes this command is ok, but my problem is why rm is not working with this permissions i have full permissions for this directory in other field

It’s different accounts.

How would you expect safety from your account, if everyone had the permission to delete your home directory?

You do not have the w permission to delete someone other’s home directory by default, except if they chmod +w it.

Here are the different permissions, and an example ( -rwxr-x— / rwxrx ):

+-+-+-+-+ |+|u|g|o| +-+-+-+-+ |r|1|1|1| +-+-+-+-+ |w|2|2|2| +-+-+-+-+ |x|4|4|4| +-+-+-+-+ |*|7|5|0| +-+-+-+-+

It goes like this: 1 + 2 + 4 = 7 , 1 + 4 = 5 , 0 = 0 , so 750 , i.e. an ideal permission system. The owner ( u in this case) can read, write and execute the file, the owner’s group ( g in this case) can read and execute, and anyone other ( o in this case) cannot do anything. This is the legendary:

u: current user (User) g: current user's groups (Groups) o: not current user's groups (Others) r: read permission (Read) w: write permission (Write) x: execute permission (X-ecute)

Источник