nautilus cannot write on nfs file share base dir

Bug #1800043 reported by Peter Neugebauer on 2018-10-25
This bug affects 6 people
Affects Status Importance Assigned to Milestone
nautilus (Ubuntu)

Bug Description

I installed Ubuntu 18.04LTS comming from 16.04LTS where I did not have this weird problem: If I mount a NFS share from a file server (i.e. Synology DS 418) Nautilus is not able to perform any write access to it (write, delete, make new directory,...). I can do all of this operations by using shell commands (touch, cp, mkdir...) in a terminal window. Also, nautilus can perform these actions if I start it with root privileges.
Even stranger is the following: even though nautilus cannot write into the mounted shares it is able to write into its subfolders. This bug seems to affect others as well:

Ubuntu version: 18.04.1 LTS - amd64
Nautilus version: 1:3.26.4-0~ubuntu18.04.1

Sebastien Bacher (seb128) wrote :

Thank you for your bug report. Can you write into that directory using the gio command line utility? Do you get any error in the journalctl log or in the nautilus UI when trying to copy to the base directory?

Changed in nautilus (Ubuntu):
importance: Undecided → High

As for the command line: copying and deleting works with the usual cp/rm commands and also with the gio tool (gio copy/gio remove). However, it doesn't work with nautilus.
The nautilus UI simply doesn't let me place the icon of the desired file into the root window. It "flies" back to where it came from. Thus, it behaves exactly as you would expect from a read-only file system. BTW: copying _from_ the root system with nautilus also works correctly. And, again, once I go into one of my folders - everything works as usual.
For now I decided to mount my share with CIFS - which also works as desired.

Best regards

Nick Sinik (sinikn) wrote :

I exported a nfs share (rw,sync,no_subtree_check) on Ubuntu 18.04.1 LTS Release: 18.04
nautilus: 1:3.26.4-0~ubuntu18.04.2 and could not reproduce the problem. Nautilus works OK.

Nick Sinik (sinikn) on 2019-01-02
Changed in nautilus (Ubuntu):
status: New → Incomplete
Nick Sinik (sinikn) wrote :

I exported a nfs share (rw,sync,no_subtree_check) on Ubuntu 18.04.1 LTS, used nfs-kernel-server: 1:1.3.4-2.1ubuntu5 and nfs-common: 1:1.3.4-2.1ubuntu5 nautilus: 1:3.26.4-0~ubuntu18.04.2 and could not reproduce the problem. Ensure the system is properly patched.

Changed in nautilus (Ubuntu):
status: Incomplete → Invalid
Nick Sinik (sinikn) on 2019-01-02
Changed in nautilus (Ubuntu):
status: Invalid → Incomplete

Do we work on the same problem? My nfs share is exported by an external file server (i.e. a synology disc station) and imported by Ubuntu 18.04.
Thus, the line in my /etc/fstab on my Ubuntu system reads
xxx.yyy.zzz:/volume1/homes/peter /media/peter/MyStorage nfs defaults,intr 0 0
This links the external disc to my Ubuntu system. The option "intr" seemed to be important for the synology station when I still was using 16.04. Now, the behaviour doesn't change if I omit it.
Once again: using nautilus I can only read from "/media/peter/MyStorage". Using command line tools I can read and write to the share.
Also, using nautilus I can read _and_ write to every subfolder of "/media/peter/MyStorage".

Jens Gollasch (jensg) wrote :

I have the same problem, can't write to the 1st directory of nfs share in GUI.
Searched a day until found this thread here.
Coming from 14.04 to 16.04 and nemo 3.6.5 instead of nautilus (mint cinnamon 17.3->18.3). The same problem also consists with thunar.
So it should be a common bug.
Maybe a follow failure from another (gnome?)package, because with a fresh usb stick (in my case mint 18.03) it works!

Changed in nautilus (Ubuntu):
status: Incomplete → New
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nautilus (Ubuntu):
status: New → Confirmed
summary: - nautilus cannot write on nfs file share
+ nautilus cannot write on nfs file share base dir
Sebastien Bacher (seb128) wrote :
Changed in nautilus (Ubuntu):
status: Confirmed → Triaged
Feydreva (feydreva) wrote :


I m the original writter for

While It was submitted for Ubuntu 18.10, I still have the issue with Ubuntu 18.10

Spychea ~ » cat /etc/lsb-release
Spychea ~ » apt-cache policy nautilus
  Installé : 1:3.26.4-0ubuntu7.1
  Candidat : 1:3.26.4-0ubuntu7.1
 Table de version :
 *** 1:3.26.4-0ubuntu7.1 500
        500 cosmic-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1:3.26.4-0ubuntu7 500
        500 cosmic/main amd64 Packages

I have no issue with PCManFM for the file manager..
but applications on ubuntu uses Nautilus to "save file", so I cannot save file on 1st folder of NFS share.

Darel Cullen (darelj) wrote :

I have exactly the same issue. Also with a synology NAS.
Mounted like this /home/files/syn nfs rw,relatime,user,noauto 0 0

/home/files is owned and readable and writable by the user

files fly back to the source.

Sebastien Bacher (seb128) wrote :

Upstream asked for extra details
'Can you please provide gio info /media/feydreva/download and gio info -f /media/feydreva/download outputs?'

Could you provide those info?

Is the destination folder a symlink (like in

Thorsten (thorstenfuehrer) wrote :

Hi, I have exactly the same issue.
Since the OP didn't provide the gio infos upstream requested, I just wanted to jump in and provide those infos.

gio info /mnt/nfs/tfuehrerldap
Anzeigename: tfuehrerldap
Name bearbeiten: tfuehrerldap
Name: tfuehrerldap
Typ: directory
Größe: 4096
Adresse: file:///mnt/nfs/tfuehrerldap
  standard::type: 2
  standard::name: tfuehrerldap
  standard::display-name: tfuehrerldap
  standard::edit-name: tfuehrerldap
  standard::copy-name: tfuehrerldap
  standard::icon: folder
  standard::content-type: inode/directory
  standard::fast-content-type: inode/directory
  standard::size: 4096
  standard::allocated-size: 4096
  standard::symbolic-icon: folder-symbolic, folder
  etag::value: 1560855687:754488
  id::file: l68:88809598
  id::filesystem: l68
  access::can-read: TRUE
  access::can-write: FALSE
  access::can-execute: TRUE
  access::can-delete: FALSE
  access::can-trash: FALSE
  access::can-rename: FALSE
  time::modified: 1560855687
  time::modified-usec: 754488
  time::access: 1560855688
  time::access-usec: 767482
  time::changed: 1560855687
  time::changed-usec: 754488
  unix::device: 68
  unix::inode: 88809598
  unix::mode: 16877
  unix::nlink: 4
  unix::uid: 1000001
  unix::gid: 1000001
  unix::rdev: 0
  unix::block-size: 4096
  unix::blocks: 8
  unix::is-mountpoint: TRUE
  owner::user: tfuehrerldap
  owner::user-real: tfuehrerldap
  owner::group: users
  metadata::nautilus-list-view-sort-column: name
  metadata::nautilus-list-view-sort-reversed: false

gio info -f /mnt/nfs/tfuehrerldap
  filesystem::size: 3928343838720
  filesystem::free: 1362925715456
  filesystem::type: nfs
  filesystem::used: 2565296488448
  filesystem::remote: FALSE


To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.