RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 844713 - Nautilus can't create folder/document in writeable directory when referenced via a symlink from a read-only file system
Summary: Nautilus can't create folder/document in writeable directory when referenced ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nautilus
Version: 6.3
Hardware: All
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Alexander Larsson
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1002711
TreeView+ depends on / blocked
 
Reported: 2012-07-31 13:25 UTC by James Pearson
Modified: 2018-12-01 14:44 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-18 13:53:19 UTC
Target Upstream Version:
Embargoed:

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

Description James Pearson 2012-07-31 13:25:02 UTC 
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 Program Management 2012-09-07 05:26:41 UTC 
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 16:04:14 UTC 
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 15:53:17 UTC 
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 13:29:06 UTC 
Thanks - patch works fine for me!
Comment 7 James Pearson 2013-03-13 14:52:47 UTC 
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 22:31:23 UTC 
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 22:49:11 UTC 
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 23:46:18 UTC 
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 08:53:14 UTC 
(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 Program Management 2013-10-14 00:32:12 UTC 
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 10:13:58 UTC 
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 13:53:19 UTC 
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 07:31:14 UTC 
Still happens on Fedora 26
Comment 18 Pavel Sklenak 2017-07-10 08:55:44 UTC 
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.