I try to check the attributes of some write-protected files in the.git directory using the command lsattr.
$ lsattr .git/objects/4d/8595f02d97d82a3c4464d9fc1bc47b255dd9bf
lsattr: Operation not supported While reading flags on .git/objects/4d/8595f02d97d82a3c4464d9fc1bc47b255dd9bf
$ stat .git/objects/4d/8595f02d97d82a3c4464d9fc1bc47b255dd9bf
File: .git/objects/4d/8595f02d97d82a3c4464d9fc1bc47b255dd9bf
Size: 115 Blocks: 8 IO Block: 4096 regular file
Device: 0,36 Inode: 436 Links: 1
Access: (0444/-r--r--r--) Uid: ( 1000/ test) Gid: ( 1000/ test)
$ file .git/objects/4d/8595f02d97d82a3c4464d9fc1bc47b255dd9bf
.git/objects/4d/8595f02d97d82a3c4464d9fc1bc47b255dd9bf: zlib compressed data
$ git -v
git version 2.39.1
uname -r
5.15.91-1-MANJARO\
I'd like to figure out why lsattr can't get the attributes of some files and how to make such files.
EDIT. Those files are on the tmpfs filesystem.
Because user extended attributes are not permitted on the tmpfs filesystem, this occurs. However, by enabling TMPFS_XATTR in kernel configuration, extended attributes on tmfps can be enabled.
Related
Given a directory, I'd like to know whether the files in the directory have been modified or not. (Boolean) i.e. if the directory's state has changed from before.
I don't want to run a file watcher service for this as I don't need to know which file has been modified (or if many files change receive many events)
I've looked at atime, mtime, ctime from stat
eg: for a dir named taskmaster which already contains sample.txt
stat taskmaster
output
File: taskmaster
Size: 245760 Blocks: 480 IO Block: 4096 directory
Device: 802h/2050d Inode: 1309314 Links: 1
Access: (0777/drwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-05-22 21:25:06.226421200 +0530
Modify: 2020-05-22 21:25:06.222175900 +0530
Change: 2020-05-22 21:25:06.222175900 +0530
Birth: -
After I modify the folder contents
# modify an existing file
echo modify > taskmaster/sample.txt
stat taskmaster gives
File: taskmaster
Size: 245760 Blocks: 480 IO Block: 4096 directory
Device: 802h/2050d Inode: 1309314 Links: 1
Access: (0777/drwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-05-22 21:25:06.226421200 +0530
Modify: 2020-05-22 21:25:06.222175900 +0530
Change: 2020-05-22 21:25:06.222175900 +0530
Birth: -
The exact same output.
If no file is removed or deleted the access and modify times do not change. How can I achieve this?
I think you need to do stat on individual files, something like this :
previous="$(stat *)"
while sleep 60; do
current="$(stat *)"
if [[ $current != $previous ]]; then
echo "Some files changed."
fi
previous=$current
done
Earlier comment: stat -c %Y /path/to/directory also works, does have a ceveat.
There are several fields that the stat command reads and accesses and it depends on how the contents of the direcctory were modified.
stat command output uses st_mtime
printf("Last file modification: %s", ctime(&sb.st_mtime));
Source: https://www.pdl.cmu.edu/posix/docs/POSIX-stat-manpages.pdf
Stat documentation
The field st_mtime for a file is changed by file modifications, e.g. by mknod(2), truncate(2), utime(2) and write(2) (of more than zero bytes).
st_mtime of a directory is changed by the creation or deletion of files in that directory. The st_mtime field is not changed for changes in owner, group, hard link count, or mode.
Source: http://man.he.net/man2/stat
So if a file is created, written to or deleted within a directory, the directory modified time will be automatically updated, but not if an additional hardlink or permissions are changed on a file within that directory.
I cannot find information on casading the changes up towards / but the directories utime cchange 'should' propagate this upwards but possibly not immediately. I would cetainly test that though for your use case.
This is all done as the root user.
The script for backups at /usr/share/perl5/PVE/VZDump/LXC.pm sets a default mount point
my $default_mount_point = "/mnt/vzsnap0";
But regardless of whether I use the GUI or the command line I get the following error:
ERROR: Backup of VM 103 failed - mkdir /mnt/vzsnap0:
Permission denied at /usr/share/perl5/PVE/VZDump/LXC.pm line 161.
And lines 160 - 161 in that script is:
my $rootdir = $default_mount_point;
mkpath $rootdir;
After the installation before I created any images or did any backups I setup two things.
(1) SSHFS mount for /mnt/backups
(2) Added all other drives as Linux LVM
What I did for the drive addition is as simple as:
pvcreate /dev/sdb1
pvcreate /dev/sdc1
pvcreate /dev/sdd1
pvcreate /dev/sde1
vgextend pve /dev/sdb1
vgextend pve /dev/sdc1
vgextend pve /dev/sdd1
vgextend pve /dev/sde1
lvextend pve/data /dev/sdb1
lvextend pve/data /dev/sdc1
lvextend pve/data /dev/sdd1
lvextend pve/data /dev/sde1
For the SSHFS instructions see my blog post on it: https://6ftdan.com/allyourdev/2018/02/04/proxmox-a-vm-server-for-your-home/
Here are filesystem directory permission related files and details.
cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/pve/root / ext4 errors=remount-ro 0 1
/dev/pve/swap none swap sw 0 0
proc /proc proc defaults 0 0
df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.8G 0 7.8G 0% /dev
tmpfs 1.6G 9.0M 1.6G 1% /run
/dev/mapper/pve-root 37G 8.0G 27G 24% /
tmpfs 7.9G 43M 7.8G 1% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup
/dev/fuse 30M 20K 30M 1% /etc/pve
sshfs#10.0.0.10:/mnt/raid/proxmox_backup 1.4T 725G 672G 52% /mnt/backups
tmpfs 1.6G 0 1.6G 0% /run/user/0
ls -dla /mnt
drwxr-xr-x 3 root root 0 Aug 12 20:10 /mnt
ls /mnt
backups
ls -dla /mnt/backups
drwxr-xr-x 1 1001 1002 80 Aug 12 20:40 /mnt/backups
The command that I desire to succeed is:
vzdump 103 --compress lzo --node ProxMox --storage backup --remove 0 --mode snapshot
For the record the container image is only 8GB in size.
Cloning containers does work and snapshots work.
Q & A
Q) How are you running the perl script?
A) Through the GUI you click on Backup now, then select your storage (I have backups and local and the both produce this error), then select the state of the container (Snapshot, Suspend, Stop each produce the same error), then compression type (none, LZO, and gzip each produce the same error). Once all that is set you click Backup and get the following output.
INFO: starting new backup job: vzdump 103 --node ProxMox --mode snapshot --compress lzo --storage backups --remove 0
INFO: Starting Backup of VM 103 (lxc)
INFO: Backup started at 2019-08-18 16:21:11
INFO: status = stopped
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: CT Name: Passport
ERROR: Backup of VM 103 failed - mkdir /mnt/vzsnap0: Permission denied at /usr/share/perl5/PVE/VZDump/LXC.pm line 161.
INFO: Failed at 2019-08-18 16:21:11
INFO: Backup job finished with errors
TASK ERROR: job errors
From this you can see that the command is vzdump 103 --node ProxMox --mode snapshot --compress lzo --storage backups --remove 0 . I've also tried logging in with a SSH shell and running this command and get the same error.
Q) It could be that the directory's "immutable" attribute is set. Try lsattr / and see if /mnt has the lower-case "i" attribute set to it.
A) root#ProxMox:~# lsattr /
--------------e---- /tmp
--------------e---- /opt
--------------e---- /boot
lsattr: Inappropriate ioctl for device While reading flags on /sys
--------------e---- /lost+found
lsattr: Operation not supported While reading flags on /sbin
--------------e---- /media
--------------e---- /etc
--------------e---- /srv
--------------e---- /usr
lsattr: Operation not supported While reading flags on /libx32
lsattr: Operation not supported While reading flags on /bin
lsattr: Operation not supported While reading flags on /lib
lsattr: Inappropriate ioctl for device While reading flags on /proc
--------------e---- /root
--------------e---- /var
--------------e---- /home
lsattr: Inappropriate ioctl for device While reading flags on /dev
lsattr: Inappropriate ioctl for device While reading flags on /mnt
lsattr: Operation not supported While reading flags on /lib32
lsattr: Operation not supported While reading flags on /lib64
lsattr: Inappropriate ioctl for device While reading flags on /run
Q) Can you manually created /mnt/vzsnap0 without any issues?
A) root#ProxMox:~# mkdir /mnt/vzsnap0
mkdir: cannot create directory ‘/mnt/vzsnap0’: Permission denied
Q) Can you replicate it in a clean VM ?
A) I don't know. I don't have an extra system to try it on and I need the container's I have on it. Trying it within a VM in ProxMox… I'm not sure. I suppose I could try but I'd really rather not have to just yet. Maybe if all else fails.
Q) If you look at drwxr-xr-x 1 1001 1002 80 Aug 12 20:40 /mnt/backups, it looks like there are is a user with id 1001 which has access to the backups, so not even root will be able to write. You need to check why it is 1001 and which group is represented by 1002. Then you can add your root as well as the user under which the GUI runs to the group with id 1002.
A) I have no problem writing to the /mnt/backups directory. Just now did a cd /mnt/backups; mkdir test and that was successful.
From the message
mkdir /mnt/vzsnap0: Permission denied
it is obvious the problem is the permissions for /mnt directory.
It could be that the directory `s "immutable" attribute is set.
Try lsattr / and see if /mnt has the lower-case "i" attribute set to it.
As a reference:
The lower-case i in lsattr output indicates that the file or directory is set as immutable: even root must clear this attribute first before making any changes to it. With root access, you should be able to remove this with chattr -i /mnt, but there is probably a reason why this was done in the first place; you should find out what the reason was and whether or not it's still applicable before removing it. There may be security implications.
So, if this is the case, try:
chattr -i /mnt
to remove it.
References
lsattr output
According to inode flags—attributes manual page:
FS_IMMUTABLE_FL 'i':
The file is immutable: no changes are permitted to the file
contents or metadata (permissions, timestamps, ownership, link
count and so on). (This restriction applies even to the supe‐
ruser.) Only a privileged process (CAP_LINUX_IMMUTABLE) can
set or clear this attribute.
As long as the bounty is still up I'll give it to a legitimate answer that fixes the problem described here.
What I'm writing here for you all is a work around I've thought of which works. Note, it is very slow.
Since I am able to write to the /mnt/backups directory, which exists on another system on the network, I went ahead and changed the Perl script to point to /mnt/backups/vzsnap0 instead of /mnt/vzsnap0.
Bounty remains for anyone who can get the /mnt directory to work for the mount path to successfully mount vzsnap0 for the backup script..
1)
Perhaps your "/mnt/vzsnap0" is mounted as read only?
It may tell from your:
/dev/pve/root / ext4 errors=remount-ro 0 1
'errors=remount-ro' means in case of mistake remounting the partition like readonly. Perhaps this setting applies for your mounted filesystem as well.
Can you try remounting the drive as in the following link? https://askubuntu.com/questions/175739/how-do-i-remount-a-filesystem-as-read-write
And if that succeeds, manually create the directory afterwards?
2) If that didn't help:
https://www.linuxquestions.org/questions/linux-security-4/mkdir-throws-permission-denied-error-in-a-directoy-even-with-root-ownership-and-777-permission-4175424944/
There, someone remarked:
What is the filesystem for the partition that contains the directory.[?]
Double check the permissions of the directory, or whether it's a
symbolic link to another directory. If the directory is an NFS mount,
rootsquash can prevent writing by root.
Check for attributes (lsattr). Check for ACLs (getfacl). Check for
selinux restrictions. (ls -Z)
If the filesystem is corrupt, it might be initially mounted RW but
when you try to write to a bad area, change to RO.
Great, turns out this is a pretty long-standing issue with Ubuntu Make which is faced by many people.
I saw a workaround mentioned by an Ubuntu Developer in the above link.
Just follow the below steps:
sudo -s
unset SUDO_UID
unset SUDO_GID
Then run umake to install your application as normal.
you should now be able to install to any directory you want. Works flawlessly for me.
try ls laZ /mnt to review the security context, in case SE Linux is enabled. relabeling might be required then. errors=remount-ro should also be investigated (however, it is rather unlikely lsattr would fail, unless the /mnt inode itself is corrupted). Creating a new directory inode for these mount-points might be worth a try; if it works, one can swap them.
Just change /mnt/backups to /mnt/sshfs/backups
And the vzdump will work.
I have implemented a new NAS filer recently, and after mounting
it on a Linux server, the Perl interpreter (version 5.005_03) is unable
to recognize the existence of files on that mount:
[root#server ~]# stat /newmount/testfile
File: `/newmount/testfile'
Size: 0 Blocks: 0 IO Block: 65536 regular empty file
Device: 48h/72d Inode: 9262698097446760736 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 500/ testuser) Gid: ( 500/ testuser)
Access: 2017-02-22 16:44:21.218314000 +0200
Modify: 2017-02-22 16:44:21.218314000 +0200
Change: 2017-02-22 16:44:21.218314000 +0200
[root#server ~]# perl -e 'print "File Exists\n" if -e "/newmount/testfile";'
[root#server ~]#
The interesting thing here, is this:
When I try with a newer version of the
interpreter (like perl, v5.8.8) it works:
[root#server ~]# perl -e 'print "File Exists\n" if -e "/newmount/testfile";'
File Exists
[root#server ~]#
What am I missing on the old Perl?
Thanks in advance!
Thanks for anyone trying to help, I found the root cause of the issue.
For anyone facing a similar issue with legacy systems,
check if the storage exporting the NFS mounts is using 64-bit file descriptors.
In my case, switching to 32-bit file descriptors on the storage solved the issue.
I had a similar issue while using Perl.
The mounted nfs directory had perms of 775 and ownership of 0:788
Account running Perl had primary GID of 402 and was also a member of 788.
Error messages indicated "does not exist or is not a directory"
I changed the primary group of the active account to 788 and it began working.
Only posting in the hopes of preventing someone else from ripping out their last remaining hairs.
I can't send mail from Ubuntu and when I cat /var/log/apache2/error.log
I see the following error:
sh: 1: /usr/sbin/sendmail: Permission denied
Note :- SElinux is disabled
$ stat /usr/sbin/sendmail
File: ‘/usr/sbin/sendmail’ -> ‘/etc/alternatives/sendmail’
Size: 26 Blocks: 0 IO Block: 4096 symbolic link
Device: 801h/2049d Inode: 1318147 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
You need to be a superuser to use any binaries found at sbin. As sendmail is in /usr/sbin/, you have to be superuser, If your are not, You will get the Permission denied error
I am using stat to get the acess time of a file (current date is October 23, 2013)
[juan#JN-LNXSVR-02 labfiles]$ stat nursery
File: `nursery'
Size: 837 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 139539 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 500/ juan) Gid: ( 500/ juan)
Access: 2013-10-22 18:03:20.703888346 -0400
Modify: 2013-10-21 16:57:07.801165793 -0400
then I edit the file and close it without any modification, and submit stat again
juan#JN-LNXSVR-02 labfiles]$ vi nursery
[juan#JN-LNXSVR-02 labfiles]$ stat nursery
File: `nursery'
Size: 837 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 139539 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 500/ juan) Gid: ( 500/ juan)
Access: 2013-10-22 18:03:20.703888346 -0400
Modify: 2013-10-21 16:57:07.801165793 -0400
Change: 2013-10-21 16:57:07.801165793 -0400
but the access time did not change, why?
I could not find any noatime attribute
juan#JN-LNXSVR-02 labfiles]$ grep noatime /proc/mounts
[juan#JN-LNXSVR-02 labfiles]$
The output of the mount command is
[juan#JN-LNXSVR-02 labfiles]$ mount
/dev/mapper/vg_jnlnxsvr02-lv_root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
/dev/sda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
[juan#JN-LNXSVR-02 labfiles]$
Could you include the output of mount? Maybe your disk is mounted with noatime?
EDIT (again): relatime would only update it once when reading after a modification but not every time. Since Linux 2.6.30 this seems to be the standard option, so if you do write + read it would update on the read. But write + read + read would only update it for the first read (and once after every following modification).
Given that your access time is already newer than your modification time, the access time would not be updated when mounted with relatime (or without atime option) if you only read.
from man mount:
noatime
Do not update inode access times on this filesystem (e.g., for faster access on
the news spool to speed up news servers).
relatime
Update inode access times relative to modify or change time. Access time is
only updated if the previous access time was earlier than the current modify or
change time. (Similar to noatime, but doesn't break mutt or other applications
that need to know if a file has been read since the last time it was modified.)
Since Linux 2.6.30, the kernel defaults to the behavior provided by this option
(unless noatime was specified), and the strictatime option is required to
obtain traditional semantics. In addition, since Linux 2.6.30, the file's last
access time is always updated if it is more than 1 day old.
And for the record, if you want to have the old behaviour back, use strictatime.
Allows to explicitly requesting full atime updates. This makes it possible for
kernel to defaults to relatime or noatime but still allow userspace to override
it. For more details about the default system mount options see /proc/mounts.