I ran into this problem today: I had a .config file that I could neither delete nor edit through *sudo* from the terminal. Opening the containing folder as 'sudo' showed a little lock icon on the file. Hm.
sudo rm myfile.config
- which was the first command in my set of instructions - returned an 'insufficient permissions' message. Using:
sudoedit myfile.config
did allow me to open a file - but on inspection, what was opened was a temporary file that could not be saved in place of the original. I did:
ls -l /etc/myfile.conf
which gave me:
-rw-r--r-- 1 root root 52 mag 17 17:12 /etc/myfile.conf
where:
*the first symbol is either '-' for 'file' or 'f' for 'folder'
*the next three symbols are permissions for the file owner: 'r' for 'read', 'w' for 'write' and 'x' for 'execute'. '-' means the given user lacks that particular
permission. Here, as superuser, I had both write ('w) and read ('r') permission, though no execute permission (which makes sense, because this is
not, after all, an executable file).
*the next three symbols are for the group permissions
*the final three symbots are for all other users' permissions
According to ls -l, I most certainly should be able to modify this file, so: what the heck?
FYI, it is easy to dig up pages on the internet that will tell you how to check that you really are in the superuser group, that you have the necessary privileges to make changes to files. For example, 'chmod' and 'chown' are two tools that can get a lot of this type of work done, and googling them will bring up some great tutorials. But in my case, ownership was clearly not the question. I could easily open (and, had I wished, modified or deleted) other files with exactly the same permissions - but not this one.
What did the trick was a suggestion I came across at: superuser.com/questions/660617:
"it could be an extended attribute of the filesystem"
To test this possibility, the commenter suggested the following command:
lsattr [FILE_TO_TEST}
Note that here one must also supply the path to the file, so in my case:
lsattr /etc/myfile.conf
which returned the following:
----i--------e--
To interpret this mysteriousness, one uses the information found on the MAN page for a related tool, 'chattr'
man chattr
which lists the fourteen values that may be present in the return string, their significance and what one may do with them. A file with the 'i' flag
"...cannot be modified: it cannot be deleted or renamed, no link can
be created to this file and no data can be written to the file."
Fortunately, the MAN page also gives a solution to the 'i' problem:
"Only the superuser ... can set or clear this attribute"
How? By use of 'chattr'. 'chattr' takes three functions, including '+' to add an attribute and '-' to remove an attribute. I tried:
sudo chattr -i /etc/myfile.conf
Note that when chattr executes successfully, it produces no return statement, in line with many other tools. To check that, indeed, the 'i' had been cleared from the file, I again typed:
lsattr /etc/myfile.conf
which now returned:
-------------e--
Returning to the /etc folder as root, I saw that the little lock icon was gone from myfile.conf. Success.
[Solved] Superuser/Owner unable to edit files
Forum rules
Don't add support questions to tutorials; start your own topic in the appropriate sub-forum instead. Before you post read forum rules
Don't add support questions to tutorials; start your own topic in the appropriate sub-forum instead. Before you post read forum rules
-
- Level 2
- Posts: 51
- Joined: Thu May 10, 2012 2:16 pm
[Solved] Superuser/Owner unable to edit files
Last edited by micheletrecaffe on Tue Feb 08, 2022 5:39 pm, edited 2 times in total.
Re: Superuser/Owner unable to edit files
Glad you found a solution to your problem , good work.
Next time you run into this you might try these commands also
To edit the file:
To modify permissions /delete file:
this brings up a root instance of nemo (replace nemo with the file manager you are using in your DE) then navigate to the file in question you should be allowed to modify the file permissions or delete it.
Next time you run into this you might try these commands also
To edit the file:
Code: Select all
xed admin:///etc/myfile
Code: Select all
pkexec nemo
Last edited by kc1di on Tue May 18, 2021 7:46 am, edited 1 time in total.
Easy tips : https://easylinuxtipsproject.blogspot.com/ Pjotr's Great Linux projects page.
Linux Mint Installation Guide: http://linuxmint-installation-guide.rea ... en/latest/
Registered Linux User #462608
Linux Mint Installation Guide: http://linuxmint-installation-guide.rea ... en/latest/
Registered Linux User #462608
Re: Superuser/Owner unable to edit files
It clearly was an extended attribute in this case, but for anyone reading this later: do note in the context of the original post that deleting and modifying are two different things for UNIX-permission bits. I.e., OP shows an
Of course, ability to create or delete any other file in the same directory does say things and in OP's case it was in fact an EA that was being stubborn, but for anyone who gets here thinking <censored three-letter acronym> upon not being able to delete a file: check permissions on the directory the file resides in, not on the file itself.
ls -l
for the file which while it implies UNIX-permission to modify the file does not imply UNIX-permission to delete: creating or deleting a file is not considered a change to the file itself but to the directory it resides in and as such the UNIX-permissions on the directory govern that ability.Of course, ability to create or delete any other file in the same directory does say things and in OP's case it was in fact an EA that was being stubborn, but for anyone who gets here thinking <censored three-letter acronym> upon not being able to delete a file: check permissions on the directory the file resides in, not on the file itself.
-
- Level 2
- Posts: 51
- Joined: Thu May 10, 2012 2:16 pm
Re: Superuser/Owner unable to edit files
kc1di:
Funny you should mention xed - I am planning a future contribution on how I cracked into my Chromebook and finally managed to get Mint on there instead of the native ChromeOS (and that was AFTER jailbreaking the <explicit deleted> Chromebook as per MrChromebox.tech's website). xed played quite the prominant role, I can tell you.
rene: thanks for the insights - what you say never occurred to me. There are new things to learn every day! Cheers!
Funny you should mention xed - I am planning a future contribution on how I cracked into my Chromebook and finally managed to get Mint on there instead of the native ChromeOS (and that was AFTER jailbreaking the <explicit deleted> Chromebook as per MrChromebox.tech's website). xed played quite the prominant role, I can tell you.
rene: thanks for the insights - what you say never occurred to me. There are new things to learn every day! Cheers!