file permissions “r–r–r” or “444” – but even root can’t change or move

Forum Forums General Tips and Tricks file permissions “r–r–r” or “444” – but even root can’t change or move

  • This topic has 1 reply, 2 voices, and was last updated Jan 27-8:51 am by Xunzi_23.
Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
  • #130707

      While freeing up an USB stick, containing antiX 23 alpha (testing version) in order to create a boot device for antiX 23.1 testing, I ran in a strange issue I haven’t seen before.

      Since I wanted to have a backup of the stick to the external terabyte hdd, I gave order to move the full content to a backup folder, being root. All went trough, 15GB were moved within 12 minutes. And then the proccess stopped with error on the very last file. Same in zzzFM and on console, even on root console, feeding the move command manually for this very file. Also rm -f fails on it.


      root@eiche:~# chmod 755 '/media/root/antiX-Live-usb/boot/syslinux/ldlinux.sys'
      chmod: Beim Setzen der Zugriffsrechte für '/media/root/antiX-Live-usb/boot/syslinux/ldlinux.sys': Die Operation ist nicht erlaubt
      root@eiche:~# ls -l '/media/root/antiX-Live-usb/boot/syslinux/ldlinux.sys'
      -r--r--r-- 1 root root 59392 10. Feb 2023  /media/root/antiX-Live-usb/boot/syslinux/ldlinux.sys
      root@eiche:~# stat '/media/root/antiX-Live-usb/boot/syslinux/ldlinux.sys'
       Datei: /media/root/antiX-Live-usb/boot/syslinux/ldlinux.sys
       Größe: 59392     	Blöcke: 120        EA Block: 4096   reguläre Datei
      Gerät: 8/49	Inode: 1570803     Verknüpfungen: 1
      Zugriff: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
      Zugriff: 2023-02-10 12:01:37.088184489 +0100
      Modifiziert: 2023-02-10 12:01:37.122184491 +0100
      Geändert: 2023-02-10 12:01:37.145184493 +0100
      Geburt: 2023-02-10 12:01:37.088184489 +0100

      Please note. This is *not* the usb stick currently in use system having been booted from. I have unmounted it (by unplugdrive, also manually by feeding the umount command) and replugged it. Same result, I can’t modify or delete this very file. I have tried to set a test file to same permissions (chmod 444) to get r–r–r permissions, and the test file can be moved and permissions changed perfectly fine by root, root can even move it without changing permissions first (as expected). Obviously something is special with this very file.

      To make it short: This file is “immutable”. Meaning the immutable flag is set on this file. Just removing this flag frees it, and it can be deleted or moved by root again:

      root@eiche:~# lsattr '/media/root/antiX-Live-usb/boot/syslinux/ldlinux.sys'
      ----i---------e------- /media/root/antiX-Live-usb/boot/syslinux/ldlinux.sys
      root@eiche:~# chattr -i '/media/root/antiX-Live-usb/boot/syslinux/ldlinux.sys'
      root@eiche:~# lsattr '/media/root/antiX-Live-usb/boot/syslinux/ldlinux.sys'
      --------------e------- /media/root/antiX-Live-usb/boot/syslinux/ldlinux.sys

      Now the file can be moved properly by root, even with merely r–r–r permissions set.

      Maybe somebody else run into same issue some day, so I’ll leave it here.

      Windows is like a submarine. Open a window and serious problems will start.


        Thanks Robin,
        immutable is not so well known.
        The attribute gave headaches a few times, especially on USB sticks when files
        or whole stick were thus marked by the controller after user unplugged without
        unmounting, while system was still writing…arggh.

        The same can occur on SD SSD NVME on power loss, if not recognized by computer
        assume immutable lock first.
        Power on, leave for controller to do its work. For SSD disconnect data line
        where possible. Others leave computer in BIOS settings seems to work well.
        If a system is logging the repair can not be efficiently performed so better
        no OS is booted.
        Some USB sticks need online repair.

      Viewing 2 posts - 1 through 2 (of 2 total)
      • You must be logged in to reply to this topic.