similar to: Stale NFS file handle

Hey guys, I just went from 3.0beta1 up to 3.0beta3. Has anyone seen an issue of when you have mounted a remote share via smbfs and then cd to that share and do an "ls" that you first get nothing listed, and then when you do a second "ls" you get a "Stale NFS Handle" error? Then after that you can't unmount the mount point. This problem does not occur in

I've got a pretty simple Gluster 3.2.5 implementation on RHEL6. One client keeps complaining about 'Stale NFS file handle', even though I have explicitly disabled NFS for all volumes in the environment. I've got 7 volumes on the cluster, and this is the only one actively complaining about the issue. For what it is worth, the clients and servers are the same systems. Any ideas?

Hi all, I haven't found any root cause or workaround for this yet. Can any one help me in underatanding the issue? Regards, Jeevan. On Dec 21, 2017 8:20 PM, "Jeevan Patnaik" <g1patnaik at gmail.com> wrote: > Hi, > > > After running rm -rf on a directory, the files under it got deleted, but > the directory was not deleted and was showing stale file handle

An ESTALE error usually means the gfid could not be found. Does repeating the "rm -rf" delete the directory? Regards, Nithya On 3 January 2018 at 12:16, Jeevan Patnaik <g1patnaik at gmail.com> wrote: > Hi all, > > I haven't found any root cause or workaround for this yet. Can any one > help me in underatanding the issue? > > Regards, > Jeevan. > >

Hi, After running rm -rf on a directory, the files under it got deleted, but the directory was not deleted and was showing stale file handle error. After 18 minutes, I'm able to delete the directory. So could anyone help me in knowing what could have happened or when in general I get such errors. The following is NFS log: [2017-12-21 13:56:01.592256] I [MSGID: 108019]

I've mounted my glusterfs share as I always do: mount -t glusterfs `hostname`:/bhl-volume /mnt/glusterfs and I can see it in df: # df -h | tail -n1 clustr-01:/bhl-volume 90T 51T 39T 57% /mnt/glusterfs but I can't change into it, or access any of the files in it: # ls -al /mnt/glusterfs ls: cannot access /mnt/glusterfs: Stale NFS file handle Any idea what could be causing

On 04/02/2015 09:03 AM, G?tz Reinicke - IT Koordinator wrote: > Hi folks, > > I have a Centos 6 NFS server, which dirves me crazy. > > The directory I try to export cant be accessed by different clients. > > I tried a centos 7, centos 6 and a pool of vmware esxi 5.5 systems. > > At the client side I get errors like: > > mount.nfs: Stale file handle > > or

Dnia czwartek, 2 kwietnia 2015 3:03:53 PM G?tz Reinicke - IT Koordinator pisze: > Hi folks, > I have a Centos 6 NFS server, which dirves me crazy. > The directory I try to export cant be accessed by different clients. > I tried a centos 7, centos 6 and a pool of vmware esxi 5.5 systems. > At the client side I get errors like: > mount.nfs: Stale file handle [...] > I use xfs

We recently moved all our users from the Washington IMAP server to Dovecot. There has been a substantial improvement in performance, but some users are reporting duplicate messages, and we see 'Stale NFS file handle' errors in the syslog. Does anyone know what would cause this ? The errors relate to the index file, eg. Nov 29 00:49:47 imap-e.ucl.ac.uk dovecot: [ID 107833 mail.error]

Hi, I am running dovecot/postfix/amavisd within a jail on freebsd. I have a nullfs mounted within the jail that links back to an NFS server. I am constantly getting these errors and my mail never gets delivered. I am hoping someone has a fix for me! Mar 15 18:26:02 deliver(boomer at vximultimedia.com): Error: copy: i_stream_read() failed: Stale NFS file handle Mar 15 18:26:02 deliver(boomer

In the old days NFS Shared Path had a static handle (ie a number), normal based on some number pulled out of the file system/inode. To fix (well work around) a security issue, for about 10+ years now, when a NFS server reboots, it generates a new random handle for the NFS Share. (sever may generate a new random handle per mount request) The NFS Stale Handle happens when the client is still

Hi folks, I have a Centos 6 NFS server, which dirves me crazy. The directory I try to export cant be accessed by different clients. I tried a centos 7, centos 6 and a pool of vmware esxi 5.5 systems. At the client side I get errors like: mount.nfs: Stale file handle or Sysinfo set operation VSI_MODULE_NODE_mount failed with the tatus Unable to query remote mount point's attributes. On

Hi, I'm a bit curious of error messages of the type "remote operation failed: Stale NFS file handle". All clients using the file system use Gluster Native Client, so why should stale nfs file handle be reported? Regards, /jon -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello, since updating two of our backup mailservers from dovecot 1.1.16 to 1.2.4 i get the following errors from dovecot-deliver when receiving (smtp) mail. Oct 16 00:10:42 mail3 dovecot: deliver(user): write_full(/home/r/user/.temp.backupmail.22774.d17050a07b2108e8) failed: Stale NFS file handle Oct 16 00:10:42 mail3 dovecot: deliver(user): copy: i_stream_read() failed: Stale NFS file handle Oct

Greetings dovecot mailing list. I have implemented a relatively big dovecot setup (250k users) and overall I am very pleased with dovecot functionality and performance. Setup description: * dovecot 1.0.x * FreeBSD 6.3 * Postfix (using dovecot deliver as LDA). * OpenLdap backend * Storage is NFS (Clariion EMC NFSd for Maildir, and FreeBSD NFSd for Indexes). * Locking is fcntl using

The configuration files has settings that seem to address the issues of using indexes on NFS (i.e. locking and mmap fixes), but we are using Dovecot on NFS, and when the load gets high we start to see a lot of NFS stale file handle errors, particularly with MS clients like Outlook. I see the discussion about these errors from last year. Any updates on the state of the code? Should we be using

Because my primary server went down today, I have a couple of servers that have 'stale NFS mounts' which I can't unmount... # umount /home/storage/users umount: /home/storage/users: device is busy umount: /home/storage/users: device is busy short of restarting...is there a trick that I can do to umount/remount? Craig

Hi all, A while ago I posted about needing to access samba shares on the same machine that the samba server was running on. Someone posted a script to mount the shares and all was well till I upgraded my PC hadware and had a small accident :( I have tried modifing /etc/init.d/samba adding ... mount -t smbfs //127.0.0.1/common /mnt/samba/common -o

I am having a problem that I have seen described in various bug reports.. One filed bug (#1267) was supposed to have been fixed in 3.0.7 but this problem is still existing in 3.0.10 from what I can tell. Here's what I see: mercury:/root# smbstatus -LB ----------8<----------<SNIP>----------8<---------- Byte range locks: Pid dev:inode R/W start size

#against V6, corrects some format problem pointed out by checkpatch.pl. For nfs exporting, ocfs2_get_dentry() returns the dentry for fh. ocfs2_get_dentry() may read from disk(when inode not in memory) without any cross cluster lock. this leads to load a stale inode. this patch fixes above problem. solution is that in case of inode is not in memory, we get the cluster lock(PR) of alloc inode