Bug 844713 - Nautilus can't create folder/document in writeable directory when referenced via a symlink from a read-only file system
Nautilus can't create folder/document in writeable directory when referenced ...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nautilus (Show other bugs)
6.3
All Linux
unspecified Severity low
: rc
: ---
Assigned To: Alexander Larsson
Desktop QE
:
Depends On:
Blocks: 1002711
  Show dependency treegraph
 
Reported: 2012-07-31 09:25 EDT by James Pearson
Modified: 2017-07-10 04:55 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-18 09:53:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch (1.58 KB, patch)
2012-09-11 11:53 EDT, Tomáš Bžatek
no flags Details | Diff

  None (edit)
Description James Pearson 2012-07-31 09:25:02 EDT
Description of problem:

When using nautilus to create a new folder/document in a writeable directory that is browsed to via a symbolic link from a file system that is mounted read-only you get the error window 'Error while copying to <dest>. The destination is read-only.'

Version-Release number of selected component (if applicable):

nautilus-2.28.4-19

How reproducible:

Always

Steps to Reproduce:
1. mkdir /tmp/mnt
2. mount -t tmpfs none /tmp/mnt
3. ln -s /var/tmp /tmp/mnt/symlink_to_var_tmp
4. mount -o ro,remount /tmp/mnt
5. nautilus /tmp/mnt/symlink_to_var_tmp
6. Right-click in the window and select 'Create Folder'
  
Actual results:

Error message:

 Error while copying to "symlink_to_var_tmp".
 The destination is read-only.

Expected results:

New directory is created

Additional info:

It appears nautilus uses details from the parent read-only file system, not details from the actual file system the symlink lands on when doing this check

In fact, I'm not sure if this check in the code is actually needed - as if you try to create a folder/document on a file system that is not writeable, the menu items are greyed out anyway

Commenting out this check in verify_destination() in libnautilus-private/nautilus-file-operations.c 'fixes' the problem ...
Comment 2 RHEL Product and Program Management 2012-09-07 01:26:41 EDT
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.
Comment 3 Tomáš Bžatek 2012-09-10 12:04:14 EDT
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.
Comment 4 Tomáš Bžatek 2012-09-11 11:53:17 EDT
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.
Comment 5 James Pearson 2012-09-12 09:29:06 EDT
Thanks - patch works fine for me!
Comment 7 James Pearson 2013-03-13 10:52:47 EDT
This issue wasn't fixed in 6.4 - is it likely to be fixed in 6.5?

The proposed patch appears to work fine
Comment 8 David Brown 2013-05-13 18:31:23 EDT
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
Comment 9 David Brown 2013-05-13 18:49:11 EDT
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)
Comment 10 David Brown 2013-05-13 19:46:18 EDT
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.
Comment 11 James Pearson 2013-05-14 04:53:14 EDT
(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
Comment 12 RHEL Product and Program Management 2013-10-13 20:32:12 EDT
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.
Comment 14 James Pearson 2014-04-22 06:13:58 EDT
Any idea if this bug will be fixed in 6.6?

The proposed patch appears to work fine
Comment 16 Chris Williams 2015-09-18 09:53:19 EDT
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.
Comment 17 Pavel Sklenak 2017-07-10 03:31:14 EDT
Still happens on Fedora 26
Comment 18 Pavel Sklenak 2017-07-10 04:55:44 EDT
see also https://bugzilla.gnome.org/show_bug.cgi?id=703179, please

Note You need to log in before you can comment on or make changes to this bug.