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.
Related
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.
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
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 have a Debian Wheezy computer running a Postgresql Server and NO NFS filesystems.
After rebooting the computer, the following error has appeared:
ls: cannot access 0000: Stale NFS file handle
516439 drwx------ 2 postgres postgres 8 Nov 12 20:25 .
516480 drwx------ 3 postgres postgres 4096 Nov 17 17:08 ..
? ?????????? ? ? ? ? ? 0000
The "/var/lib/postgresql/9.1/main/pg_notify/0000" file is STALE and I cannot remove it or do anything at all with it. In order to get rid of that file, I tried the following options:
Rebooting the computer in order to unmount the filesystem (as suggested in several forums) did not work.
Removing postgresql (apt-get -purge) did not do anything at all either.
Trying to manually remove that file does not work either (Stale NFS file handle).
This directory is part of a JFS partition over a ciphered volume managed by LVM.
The output for the fsck:
fsck.jfs version 1.1.15, 04-Mar-2011
processing started: 11/17/2014 20:22:30
Using default parameter: -p
The current device is: /
ujfs_rw_diskblocks: read 0 of 4096 bytes at offset 32768
ujfs_rw_diskblocks: read 0 of 4096 bytes at offset 61440
Superblock is corrupt and cannot be repaired
since both primary and secondary copies are corrupt.
Output for ls -l:
ls -l /var/lib/postgresql/9.1/main/pg_notify/0000
I would like to know...
Why do I have a problem with a NFS handle in a non-NFS partition?
Is there anyway in which I can get rid of that file (workarounds are more than welcome as well)?
I'm trying to share a NFS mount among multiple users. I can't get it to work, because I always get access denied. I can mount the shares, but I can't see the files.
The export is made through Heartbeat+Pacemaker. I don't think that makes the difference, but here's the export config:
primitive exports_nfs_proys ocf:heartbeat:exportfs \
params rmtab_backup="none" directory="/export/proyectos" clientspec="172.16.54.0/24" options="rw,async,no_subtree_check,insecure,root_squash" fsid="2" \
op monitor interval="30s" \
op start interval="0" timeout="240s"
So I mount the NFS share:
jorge.suarez#decp1304:~$ sudo mount -t nfs4 172.16.54.56:/proyectos/innovacion /mnt
jorge.suarez#decp1304:~$ cd /mnt
bash: cd: /mnt: Permission denied
On the client:
$ stat /mnt
File: «/mnt»
Size: 3896 Blocks: 0 IO Block: 1048576 directorio
Device: 19h/25d Inode: 131542 Links: 2
Access: (6770/drwsrws---) Uid: (65534/ nobody) Gid: ( 3001/proyecto-innovacion)
Access: 2012-08-23 14:47:53.953641353 +0200
Modify: 2012-08-23 14:47:53.263610391 +0200
Change: 2012-08-23 14:47:53.263610391 +0200
jorge.suarez#decp1304:/$ getent group | grep proyecto-innovacion
gproyecto-innovacion:*:3001:diego,felix,jorge.suarez,maria
jorge.suarez#decp1304:/$ getent passwd | grep jorge.suarez
jorge.suarez:*:4004:2000:Jorge Suárez de Lis:/home/remoto/jorge.suarez:/bin/bash
On the server:
root#ctserv01:/# stat /export/proyectos/innovacion
File: «.»
Size: 3896 Blocks: 0 IO Block: 4096 directorio
Device: fb04h/64260d Inode: 131542 Links: 2
Access: (6770/drwsrws---) Uid: (65534/ nobody) Gid: ( 3001/proyecto-innovacion)
Access: 2012-08-23 14:47:53.953641353 +0200
Modify: 2012-08-23 14:47:53.263610391 +0200
Change: 2012-08-23 14:47:53.263610391 +0200
root#ctserv01:/# getent group | grep proyecto-innovacion
proyecto-innovacion:*:3001:diego,felix,jorge.suarez,maria
root#ctserv01:/# getent passwd | grep jorge.suarez
jorge.suarez:*:4004:2000:Jorge Suárez de Lis:/home/remoto/jorge.suarez:/bin/bash
So, I'm doing something wrong, but all seems OK here. The UID/GID are matching on client and server.
If I set the directory permissions to 777 I can access, read and write the directory, but I want to restrict this just to some users so that's not an accepted solution.
Make sure you have SELinux disable on server and client
Make sure you use following option in export
rw,sync,no_root_squash
Make sure you allowed proper subnet or host name etc.