Bug 844713

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Interesting issue, just note that GIO through gvfs commands is working fine, i.e. it's really a Nautilus problem, other GIO apps should not be affected.

Created attachment 611844 [details]
proposed patch

This patch changes the way we're verifying target before doing real operation when destination is a symlink. Turns out that calling statfs() on a symlink would stat the filesystem the symlink is on, not the destination. It's a limitation of POSIX calls as well.

So in case destination is a symlink, we avoid doing any tests that may not be accurate. Read-only filesystem indication will still work, e.g. the folder context menu will have some items greyed out, that's a different check.

Thanks - patch works fine for me!

This issue wasn't fixed in 6.4 - is it likely to be fixed in 6.5?

The proposed patch appears to work fine

I'm thinking there's more to this...

Here's the setup.

# mount | grep -e localdisk1 -e ' /mnt'
/dev/cciss/c0d0p2 on /localdisk1 type ext3 (rw,relatime,errors=continue,barrier=1,data=ordered)
none on /mnt type tmpfs (ro,relatime)
# ls -l /mnt/symlink.txt /localdisk1/testfile.txt 
-rw-r--r-- 1 root root  0 May 13 15:22 /localdisk1/testfile.txt
lrwxrwxrwx 1 root root 24 May 13 15:20 /mnt/symlink.txt -> /localdisk1/testfile.txt

The symlink is sitting on a read-only file system. The file the symlink is pointing to is a valid read write file system.

On kernel 2.6.32-279.22.1.el6.x86_64 I can do the following...

# echo 'foo' >> /mnt/symlink.txt
# cat /mnt/symlink.txt 
foo

On kernel 2.6.32-358.6.1.el6.x86_64 I do the following and get this...

# echo 'foo' >> /mnt/symlink.txt 
-bash: /mnt/symlink.txt: Read-only file system
# cat /mnt/symlink.txt 
#

I'm not sure why this happened, but I like the way it worked in 279.22.1 and not so much the way 358.6.1

On the 358.6.1 system my glibc is this.
# rpm -q glibc
glibc-2.12-1.107.el6.x86_64
glibc-2.12-1.107.el6.i686

On the 279.22.1 system my glibc is this.
# rpm -q glibc
glibc-2.12-1.80.el6_3.6.x86_64
glibc-2.12-1.80.el6_3.6.i686

strace shows that bash is just doing an open on the file and getting two different results

# strace -e trace=open bash -c 'echo foo >> /mnt/symlink.txt' 
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib64/libtinfo.so.5", O_RDONLY)  = 3
open("/lib64/libdl.so.2", O_RDONLY)     = 3
open("/lib64/libc.so.6", O_RDONLY)      = 3
open("/dev/tty", O_RDWR|O_NONBLOCK)     = 3
open("/proc/meminfo", O_RDONLY)         = 3
open("/mnt/symlink.txt", O_WRONLY|O_CREAT|O_APPEND, 0666) = 3

# strace -e trace=open bash -c 'echo foo >> /mnt/symlink.txt'
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib64/libtinfo.so.5", O_RDONLY)  = 3
open("/lib64/libdl.so.2", O_RDONLY)     = 3
open("/lib64/libc.so.6", O_RDONLY)      = 3
open("/dev/tty", O_RDWR|O_NONBLOCK)     = 3
open("/proc/meminfo", O_RDONLY)         = 3
open("/mnt/symlink.txt", O_WRONLY|O_CREAT|O_APPEND, 0666) = -1 EROFS (Read-only file system)

Some additional information I tried the other two corners of the matrix

kernel 279.22.1 with glibc 2.12-1.107 the echo works
kernel 358.6.1 with glibc 2.12-1.80 the echo doesn't work

So this seems like a regression in the RHEL 6.4 kernel.

(In reply to comment #8)
>
> The symlink is sitting on a read-only file system. The file the symlink is
> pointing to is a valid read write file system.
> 
> On kernel 2.6.32-279.22.1.el6.x86_64 I can do the following...
> 
> # echo 'foo' >> /mnt/symlink.txt
> # cat /mnt/symlink.txt 
> foo
> 
> On kernel 2.6.32-358.6.1.el6.x86_64 I do the following and get this...
> 
> # echo 'foo' >> /mnt/symlink.txt 
> -bash: /mnt/symlink.txt: Read-only file system
> # cat /mnt/symlink.txt 
> #
> 
> I'm not sure why this happened, but I like the way it worked in 279.22.1 and
> not so much the way 358.6.1

This is a different issue - and a (separate) bug/regression with 6.4 kernels (2.6.32-358) i.e. nothing to do with Nautilus

It just so happens I also had this problem with 6.4 and had reported it as bug 955580 - however, for some reason that bug was marked private (so you can't see it). It has now been marked closed and a duplicate of another private bug 920752 

All I know is that the kernel bug will be fixed in the next zstream kernel release

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Any idea if this bug will be fixed in 6.6?

The proposed patch appears to work fine

This Bugzilla has been reviewed by Red Hat and is not planned on being addressed in Red Hat Enterprise Linux 6 and therefore will be closed. If this bug is critical to production systems, please contact your Red Hat support representative and provide sufficient business justification.

Still happens on Fedora 26

see also https://bugzilla.gnome.org/show_bug.cgi?id=703179, please