nautilus cannot write on nfs file share base dir

Bug #1800043 reported by Peter Neugebauer
58
This bug affects 11 people
Affects Status Importance Assigned to Milestone
Nautilus
Fix Released
Unknown
nautilus (Ubuntu)
Triaged
High
Unassigned

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: https://askubuntu.com/questions/1000973/nautilus-cannot-write-into-1st-directory-of-a-nfs-share

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

Revision history for this message
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
Revision history for this message
Peter Neugebauer (peter-neugebauer2) wrote :

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
Peter

Revision history for this message
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)
Changed in nautilus (Ubuntu):
status: New → Incomplete
Revision history for this message
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)
Changed in nautilus (Ubuntu):
status: Invalid → Incomplete
Revision history for this message
Peter Neugebauer (peter-neugebauer2) wrote :

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".

Revision history for this message
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
Revision history for this message
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
Revision history for this message
Sebastien Bacher (seb128) wrote :
Changed in nautilus (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Feydreva (feydreva) wrote :

Hello,

I m the original writter for
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1759299
and
https://askubuntu.com/questions/1000973/nautilus-cannot-write-into-1st-directory-of-a-nfs-share

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

Spychea ~ » cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.10
DISTRIB_CODENAME=cosmic
DISTRIB_DESCRIPTION="Ubuntu 18.10"
Spychea ~ » apt-cache policy nautilus
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 http://fr.archive.ubuntu.com/ubuntu cosmic-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1:3.26.4-0ubuntu7 500
        500 http://fr.archive.ubuntu.com/ubuntu 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.

Revision history for this message
Darel Cullen (darelj) wrote :

I have exactly the same issue. Also with a synology NAS.
Mounted like this
192.168.1.43:/volume1/homes /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.

Revision history for this message
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 https://gitlab.gnome.org/GNOME/nautilus/issues/976)?

Revision history for this message
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
Attribute:
  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
Attribute:
  filesystem::size: 3928343838720
  filesystem::free: 1362925715456
  filesystem::type: nfs
  filesystem::used: 2565296488448
  filesystem::remote: FALSE

cheers,
Thorsten

Revision history for this message
Feydreva (feydreva) wrote :

Sorry for delay :
as of today :

Spychea ~ » lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 19.04
Release: 19.04
Codename: disco

Spychea ~ » nautilus --version
GNOME nautilus 3.32.1

Spychea ~ » gio info -f /nfs/Download
attributs :
  filesystem::size: 5897253478400
  filesystem::free: 2102894526464
  filesystem::type: nfs
  filesystem::used: 3794193195008
  filesystem::remote: FALSE
Spychea ~ » gio info -f /nfs/Documents_Feydreva
attributs :
  filesystem::size: 5897253478400
  filesystem::free: 2102894526464
  filesystem::type: nfs
  filesystem::used: 3794193195008
  filesystem::remote: FALSE
Spychea ~ »

I use thunar as my default file manager now.
Some program use Nautilus when saving, so I have pb with them too

Changed in nautilus:
status: Unknown → New
Changed in nautilus:
status: New → Fix Released
Changed in nautilus:
status: Fix Released → New
Changed in nautilus:
status: New → Fix Released
Revision history for this message
Marco (lampje) wrote :

Hi, I have here exactly the same issue on ubuntu 20.04
can't write to the 1st directory of nfs share in nautilus.
In the terminal window no problem

Revision history for this message
Dovid Bender (dovi5988) wrote :

I am having the same issue with Ubuntu 20.04. I am using version GNOME nautilus 3.36.3. Via the command line I have no issue. The problem only seems to be in nautilus.

Revision history for this message
Jens Gollasch (jensg) wrote :

Same here with Mint 20.2 (Ubuntu 20.04) and Nemo 5.0.3 and Nautilus 3.36.3.
With PCManFM 1.3.1 and command line no issue.

Revision history for this message
Walid Shouman (weshouman) wrote :

Same issue with Nautilus on Ubuntu 22.04

Observations: Thunar file manager had the same issue, PCManFM works fine.

To post a comment you must log in.
This report contains Public information  
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.