0

I have a problem. chattr +e <file> does not work, if the file does not have the +e attr set on it, or if it's removed and re-added.

[root@ip-203-0-113-13 log]# df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  3.8G     0  3.8G   0% /dev
tmpfs          tmpfs     3.8G     0  3.8G   0% /dev/shm
tmpfs          tmpfs     3.8G  388K  3.8G   1% /run
tmpfs          tmpfs     3.8G     0  3.8G   0% /sys/fs/cgroup
/dev/nvme0n1p1 ext4       30G  1.2G   28G   5% /
tmpfs          tmpfs     763M     0  763M   0% /run/user/1000
[root@ip-203-0-113-13 log]# df -ih
Filesystem     Inodes IUsed IFree IUse% Mounted on
devtmpfs         950K   343  949K    1% /dev
tmpfs            953K     1  953K    1% /dev/shm
tmpfs            953K   389  953K    1% /run
tmpfs            953K    17  953K    1% /sys/fs/cgroup
/dev/nvme0n1p1   1.9M   97K  1.8M    6% /
tmpfs            953K     5  953K    1% /run/user/1000
[root@ip-203-0-113-13 log]# find /tmp -type f | wc -l
6126
[root@ip-203-0-113-13 tmp]# touch bar
[root@ip-203-0-113-13 tmp]# chattr -e bar
[root@ip-203-0-113-13 tmp]# chattr +e bar
chattr: No space left on device while setting flags on bar

Waaaaat?

There is plenty of space on the device and plenty of inodes free, so why is chattr +e failing? If it makes a difference, I'm seeing this failure on Fedora 28 on EC2. I'm not seeing on SUSE 42 on EC2 (yet?)

Update:

I ran strace on the command. I'm not sure if it's helpful, but it seems interesting...

Wayne Werner
  • 709
  • 4
  • 14
  • 26
  • What filesystems are in use - `df -T` output ? – user9517 May 21 '19 at 21:06
  • @Iain ext4, apparently – Wayne Werner May 21 '19 at 21:42
  • does `chmod +e` work when `chattr` is breaking or give you a better error? – Martin Barker May 21 '19 at 22:28
  • @MartinBarker `chmod: invalid mode: ‘+e’`, so... no I don't think so – Wayne Werner May 22 '19 at 00:07
  • @WayneWerner oh sorry I did not mean exactly I meant for the correct group (so Owner, group or other) so can you try `chmod o+e ` replacing `` with your file name? you will need to set that back i just want to see if you can modify permissions it might provide an error that might help or tell us it could be a busted FileSystem – Martin Barker May 22 '19 at 00:10
  • @MartinBarker still doesn't work... `e` isn't a file permission, it's an attribute. I'm not aware of chmod being able to set file attributes. – Wayne Werner May 22 '19 at 00:12
  • Just updated to cover that I was thinking if it's erroring as well it might help identify the cause if not it could be a broken FileSystem allocation table / journal . – Martin Barker May 22 '19 at 00:13
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/93949/discussion-between-martin-barker-and-wayne-werner). – Martin Barker May 22 '19 at 00:16
  • What are the existing attributes on the file, when you receive the error? Check with `lsattr`. – Michael Hampton May 22 '19 at 01:04
  • @MichaelHampton if `e` is not set, it fails. If `e` is already set, it succeeds (I guess because it's a nop). – Wayne Werner May 22 '19 at 01:24
  • Huh? How does `lsattr` fail? What error does it show? – Michael Hampton May 22 '19 at 01:25
  • not `lsattr` - `chattr +e` fails. `e` is the only attribute (or not) on the file. – Wayne Werner May 22 '19 at 01:27
  • I asked you to run `lsattr` on the file and report the result. – Michael Hampton May 22 '19 at 01:49
  • I guess it's not clear from my reply - `lsattr` shows that e is the only attribute set when I first `touch bar`. If I `chattr +e bar` then I have no problem. If I `chattr -e bar` then `lsattr` shows that no attributes are set. If I follow that up with `chattr +e` bar then I get the error, as shown above. – Wayne Werner May 22 '19 at 02:02

1 Answers1

1

If you check manual this parameter is not suppose to alter, I am surprised you are able to remove, since it is not able to find contiguous area it is showing above error.

Extent format   e   (unavailable)   
The e attribute indicates that the file is using extents for mapping the blocks on disk
asktyagi
  • 2,401
  • 1
  • 5
  • 19
  • Yeah, I read that in the docs too. But (clearly?) I'm able to remove it. I just can't put it back. – Wayne Werner May 22 '19 at 02:06
  • Hmm. That's a good point. It doesn't even make sense to try to "remove" this attribute. Now I'm surprised that anything at all happened. – Michael Hampton May 22 '19 at 02:10
  • I think you can't do without reboot(still not sure), but may be it is removed from app level and come back post reboot. – asktyagi May 22 '19 at 02:10
  • Somehow we've got a file that exists without this attribute. I'm not sure where the attribute is getting removed, but when we try to add it, things fail badly. – Wayne Werner May 22 '19 at 02:19