A symbolic link created by zfs is returning as ../../zd0, tested through multiple ways to check. Not sure why the result is not /dev/zd0 as that is the actual link as far as I am aware.
admin#r2-compute1:~$ ls -l /dev/zvol/cpool/cinder-volumes
lrwxrwxrwx 1 root root 9 Jun 25 09:53 /dev/zvol/cpool/cinder-volumes -> ../../zd0
admin#r2-compute1:~$ stat /dev/zvol/cpool/cinder-volumes
File: /dev/zvol/cpool/cinder-volumes -> ../../zd0
Size: 9 Blocks: 0 IO Block: 4096 symbolic link
Device: 6h/6d Inode: 640 Links: 1
Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2020-06-25 10:07:28.610707769 -0700
Modify: 2020-06-25 09:53:52.174435310 -0700
Change: 2020-06-25 09:53:52.174435310 -0700
Birth: -
admin#r2-compute1:~$ file /dev/zvol/cpool/cinder-volumes
/dev/zvol/cpool/cinder-volumes: symbolic link to ../../zd0
I am working with openstack and zfs and am wondering why the symbolic link returns "../../zd0" instead of "dev/zd0". I am not sure what the ../../ means and understanding would assist in my openstack implementation understanding. First time posting and Google and SymbolHound did not produce any results in regards to the meaning behind ../../
Thank you!
Probably while creating the soft links ../../zd0 was adopted instead of the full path /dev/zd0 (or whatever the path was supposed to be given).
If absolutely necessary, you may try to unlink this first and recreate the link by providing FULL-PATH to the DEVICE/FILE.
NOTE: Try this with caution and ensure the paths are correct, this is just the symbolic code to help you correct the error:
unlink /dev/zvol/cpool/cinder-volumes
ln -s /dev/zvol/cpool/cinder-volumes /dev/zd0
Related
I have some files on a scratch drive of a HPC server. The server automatically deletes files which are 2 weeks old.
Using stat filename.txt I can see the follow information. Is there a way to somehow open/touch/manipulate files to update the Access date to prevent deletion without actually changing the file?
File: ‘name’
Size: 2583438768 Blocks: 4819945 IO Block: 524288 regular file
Device: xxh/xxxd Inode: 10354xxxx Links: 1
Access: (/-rw-r--r--) Uid: (/) Gid: (/)
Context: system_u:object_r:tmp_t:s0
Access: 2022-11-22 09:47:33.000000000 -0800
Modify: 2019-12-06 06:50:33.000000000 -0800
Change: 2022-11-22 16:54:55.000000000 -0800
Birth: -
Use the Linux touch command, eg:
$ touch filename.txt
In case it matters: I stumbled over this problem when backing up a directory using rsync in a Cygwin environment, and rsync suddenly gave the error message:
rsync: readdir("/cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/idb"): File exists (17)
Here, /cygdrive/d/portable/FirefoxPortable is the directory to be saved, and until now, this has worked fine. Suspecting that the real problem is not related to rsync, I did a
ls /cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/idb
and indeed got the error message
ls: reading directory '/cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/idb': File exists
So, idb is a directory (which is true), because ls says that it is reading this direcory, but why do I get a File exists error for a directory?
ls -ld /cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/idb
yields
drwxr-xr-x 1 FISRONA Domain Users 0 May 6 2019 '/cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/idb'
and
stat /cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/idb
displayed:
File: /cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/idb
Size: 0 Blocks: 0 IO Block: 65536 directory
Device: 5a61dfech/1516363756d Inode: 12873190524118251466 Links: 1
Access: (0755/drwxr-xr-x) Uid: (3672028/ FISRONA) Gid: (1049089/Domain Users)
Access: 2019-05-06 11:32:50.000000000 +0200
Modify: 2019-05-06 11:32:50.190000000 +0200
Change: 2019-05-06 11:32:50.190000000 +0200
Birth: 2019-05-06 11:32:50.190000000 +0200
What could be messed up here to cause this behaviour?
BTW, I also checked the parent directory (because sometimes, differences in upper/lower case filenames can result in odd effects under Cygwin, due to the underlying Windows operating system):
ls -l /cygdrive/d/portable/FirefoxPortable/Data/profile/storage/default/moz-extension+++4c6d0e71-68ce-470e-87aa-8db1a3f6524d^userContextId=4294967295/
total 0
drwxr-xr-x 1 FISRONA Domain Users 0 May 6 2019 idb
I am running Centos 7 kernel 3.10.0 on Oracle's VirtualBox 4.3.20 with an ext4 filesystem.
It seems that setting the "A" flag on a file doesn't keep the access time field from updating.
I created a file and used stat to check the access time -
touch ./foo
stat ./foo
which returns the following
File: ./foo
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fd01h/64769d Inode: 1444417 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 1000/ user_1) Gid: ( 1000/ user_1)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2015-08-02 11:52:23.451524456 -0700
Modify: 2015-08-02 11:52:23.451524456 -0700
Change: 2015-08-02 11:52:23.451524456 -0700
Birth: -
If I then change the attribute and rerun stat -
sudo chattr +A ./foo
stat ./foo
I get the following which (I think) shows the access time value as updated?
File: ./foo
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fd01h/64769d Inode: 1444417 Links: 1
Access: (0777/-rwxrwxrwx) Uid: ( 1000/ user_1) Gid: ( 1000/ user_1)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2015-08-02 11:53:32.400974020 -0700
Modify: 2015-08-02 11:53:32.400974020 -0700
Change: 2015-08-02 11:53:32.400974020 -0700
Birth: -
Am I misunderstanding the use of the A flag? I thought it would keep the access time from changing?
Thanks for any insights you can offer. I am just trying to understand how things work.
Rog
+A will keep the same atime when you open the file with vi for example and not modify it. The result you've posted after modifying the attribute doesn't look right to me. Changing the attribute should only affect the 'Change' timestamp. In your case, all 3 timestamps are the same.
I am studying the linux file system. I had an experiment to explore how linux saves the hard links.
I made 1000 hard links for a file in the same directory. The size of .(DOT) increased to 28672; I remove 500 hard links, the size of .(DOT) did not decrease. (I used "stat ." to check the size.) Why doesn't the size decrease?
This is my experiment:
I have a folder named test, which has only one small file testfile and a script, the status was like this:
York:~/test$ ll -li
total 84
7995940 drwxr-xr-x 2 York domain_users 4096 Jul 17 19:20 ./
7995939 drwxr-xr-x 3 York domain_users 69632 Jul 17 19:20 ../
7996494 -rwxrwxrwx 1 York domain_users 94 Jul 17 19:14 copy.sh*
8026281 -rw-r--r-- 1 York domain_users 7 Jul 17 19:17 testfile
York:~/test$ stat .
File: `.'
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: fc03h/64515d Inode: 7995940 Links: 2
Access: (0755/drwxr-xr-x) Uid: (2060469376/York) Gid: (2060452353/domain_users)
Access: 2015-07-17 19:20:06.288345960 +0200
Modify: 2015-07-17 19:20:05.420340318 +0200
Change: 2015-07-17 19:20:05.420340318 +0200
Birth: -
Then I ran the script:
for i in `seq 200000 200999`;
do
ln testfile "$i"
done
After that, I got the following result:
York:~/test$ stat .
File: `.'
Size: 28672 Blocks: 64 IO Block: 4096 directory
Device: fc03h/64515d Inode: 7995940 Links: 2
Access: (0755/drwxr-xr-x) Uid: (2060469376/York) Gid: (2060452353/domain_users)
Access: 2015-07-17 19:21:25.364862751 +0200
Modify: 2015-07-17 19:21:11.064768884 +0200
Change: 2015-07-17 19:21:11.064768884 +0200
Birth: -
And I could see that the inode counter is 1001, which was what I expected:
York:~/test$ ll -li testfile
8026281 -rw-r--r-- 1001 York domain_users 7 Jul 17 19:17 testfile
I used "rm" to remove 500 hard links, I saw:
York:~/test$ ll -li testfile
8026281 -rw-r--r-- 501 York domain_users 7 Jul 17 19:17 testfile
But the size of the directory did not decrease:
York:~/test$ stat .
File: `.'
Size: 28672 Blocks: 64 IO Block: 4096 directory
Device: fc03h/64515d Inode: 7995940 Links: 2
Access: (0755/drwxr-xr-x) Uid: (2060469376/York) Gid: (2060452353/domain_users)
Access: 2015-07-17 19:24:35.138125221 +0200
Modify: 2015-07-17 19:24:35.142125246 +0200
Change: 2015-07-17 19:24:35.142125246 +0200
Birth: -
My understanding about the directory in file system is like this: For each directory, an inode is allocated for attributions like folder name etc, and also a block of data is used to keep entries for files and directories in that folder. Because each hard link needs one entry, 1000 hard links need more space than a block of data, another data blocks are needed. So the size of the directory .(DOT) increases. Vise versa, if I remove 500 hard links, the size should decrease.
But the experiment showed that the size did not decrease. Where am I wrong?
Thank you in advance!
Best Wishes,
York
What you're seeing is correct. Many Linux filesystems never shrink the size of a directory inode; they just blank out the entries for deleted files, allowing them to be reused if more files are added to the directory later. The only way to return the directory to its original size may be to delete it and create a new one with the same name.
Frequently, inodes are implemented on b-trees and as a minor optimization, the can grow as needed, but don't collapse.
I want to know how does a process in Linux decides what privileges it has?
Suppose there is a binary program Read_File that reads from file /home/myname/data.txt and displays the contents of it to the STD output; now, how does Read_File decides whether or not it has permission to read data.txt, what type of ids it checks to decide the privileges?
First, a bit of background:
The process is usually run by a specific user. So for example, if you log in yourself and run the program, it will run with the same privileges as yourself. You can check the permissions on the file with either stat or ls -l.
Using stat
malbert#dredg:/tmp$ stat foo
File: `foo'
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fb00h/64256d Inode: 618 Links: 1
Access: (0644/-rw-r--r--) Uid: (11204/ malbert) Gid: (10513/domain users)
Access: 2011-06-10 13:03:27.181227226 +0200
Modify: 2011-06-10 13:03:27.181227226 +0200
Change: 2011-06-10 13:03:27.181227226 +0200
The important infos here are:
Access: (0644/-rw-r--r--) Uid: (11204/ malbert) Gid: (10513/domain users)
This tells you the permissions for the owner (rw-), group (r--) and everyone else (r--). It also shows you the current owner id (Uid) and the current group id (Gid).
The abbreviations stand for:
r = read access
w = write access
x = execute/traverse directory access
Using ls -l
ls -l gives you a quick summary:
malbert#dredg:/tmp$ ls -l /tmp
total 48
drwx------ 2 malbert domain users 4096 2011-06-10 08:51 akonadi-malbert.zOSngu
-rw-r--r-- 1 malbert domain users 0 2011-06-10 13:03 foo
drwx------ 2 kdm nogroup 4096 2011-06-10 08:51 kde-kdm
drwx------ 3 malbert domain users 4096 2011-06-10 08:51 kde-malbert
[snip]
Here you can see the same info as with stat, but as a summary. Also, the uid's and gid's are resolved into names (in this case malbert and domain users). You can use ls -u to see these as numeric values.
In case you want to run the application as a different user as yourself, you can either use su, sudo or your application itself can drop priviledges and change the user it is running as. This is usually the way system daemons do things.
ACLs / extended attributes
Be careful about extended attributes. When listing the files using ls -l these are visible with an appended + sign. For example:
malbert#dredg:/tmp$ ls -l
total 48
drwx------ 2 malbert domain users 4096 2011-06-10 08:51 akonadi-malbert.zOSngu
-rw-rwxr--+ 1 malbert domain users 0 2011-06-10 13:03 foo
drwx------ 2 kdm nogroup 4096 2011-06-10 08:51 kde-kdm
drwx------ 3 malbert domain users 4096 2011-06-10 08:51 kde-malbert
[snip]
Notice the following line:
-rwxr--+ 1 malbert domain users 0 2011-06-10 13:03 foo
The + sign in -rwxr--+ points to extended attributes. It is possible that these are ACLs. There is an excellent document on ACLs in the SuSE documentation. Go have a look at it if you need to. Explaining ACLs would certainly explode this article, so I won't discuss those.
Extended attributes could also be related to the file system. See the man page of chattr for more information on that.
Now, as a sidenote: this is StackOverflow. Questions should be development related. For questions like this one, there's http://www.serverfault.com. But As you were not aware, that this is not a development problem, but more related to the OS, I felt I should answer anyway ;)
Good luck, and have fun!
The process doesn't decide anything; whenever it tries an operation the operating system checks it's EUID and decides if has the required privileges.
For example when it tries to access a file, the owner and permissions of the file are checked. If the EUID of the process doesn't have enough privileges for an operation, that operation will fail (usually with EPERM).