Bug 387936

I can confirm this bug on Kubuntu 17.10, using Dolphin 17.04.3.

I have a folder mounted via NFS, and I can read its contents in Dolphin, but can't create/modify/delete anything (e.g. the context menu for Create New is grayed out).
It works from the command line, and I can also save files to this folder from other progams.
However, Nautilus shows similar behavior as Dolphin.

Detailed description:
I have a Synology NAS, and mount some of the shared folders via NFS.
Mounting the NAS folder /volume1/homes shows this bug, while e.g. accessing /volume1/video via NFS and Dolphin works fine.

The Synology NAS only accepts NFSv3 for /volume1/homes, but I do not know why.
Mounting the video folder with NFSv3 and NFSv4 works fine.

Permissions for the individual folders:
ls -ld / /mnt/ /mnt/DS216/ /mnt/DS216/homes/ /mnt/DS216/homes/woife /mnt/DS216/Video
drwxr-xr-x 24 root  root  4096 Dez  8 15:55 /
drwxr-xr-x  9 root  root  4096 Dez 17 13:12 /mnt/
drwxr-xr-x  4 root  root     0 Dez 17 19:36 /mnt/DS216/
drwxr-xr-x 10 root  root  4096 Dez  5 21:53 /mnt/DS216/homes/
drwx------ 10 woife users 4096 Dez 17 19:16 /mnt/DS216/homes/woife
drwxrwxrwx  8 root  root  4096 Dez 17 19:12 /mnt/DS216/Video

It does not matter if I mount the folder via autofs or manually.
The only option I pass via autofs is "-rw".

> The Synology NAS only accepts NFSv3 for /volume1/homes, but I do not know why.
Mounting the folder with NFSv4 works now, again I don't know why.

However, the behavior with NFSv3 and NFSv4 is the same.

haven't seen any actions since 3 months now, if there is a way to provide more info please tell me how. 

this is still valid in version 17.12.3 of dolphin

Confirmed. Same issue on Fedora 28 with dolphin-17.12.2-2.fc28.x86_64. It seems to believe a NFSv4 mount is read-only. (It isn't.)

Thanks for the new info. Can you provide details about your method of mounting it so we can try to figure out what combination of options triggers this bug?

(In reply to Nate Graham from comment #5)
> Thanks for the new info. Can you provide details about your method of
> mounting it so we can try to figure out what combination of options triggers
> this bug?

Standard mounting from /etc/fstab:

nas2-osl1:/volume1/homes/@LH-REDPILL-LINPRO.COM/0/tore-7097 /nfshome nfs defaults 0 0

The resulting /proc/mounts entry:

nas2-osl1:/volume1/homes/@LH-REDPILL-LINPRO.COM/0/tore-7097 /nfshome nfs4 rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,clientaddr=2a02:c0:(snip),local_lock=none,addr=2a02:c0:(snip) 0 0

The mount is writable just fine from other applications, such as the shell:

$ stat /nfshome
  File: /nfshome
  Size: 6654            Blocks: 0          IO Block: 32768  directory
Device: 38h/56d Inode: 4727201     Links: 1
Access: (0755/drwxr-xr-x)  Uid: ( 7097/    tore)   Gid: ( 7097/    tore)
Context: system_u:object_r:nfs_t:s0
Access: 2018-07-04 14:16:34.555886284 +0200
Modify: 2018-07-04 14:16:33.518885060 +0200
Change: 2018-07-04 14:16:33.518885060 +0200
 Birth: -
$ touch /nfshome/test
$ rm /nfshome/test
$ 

I believe the NFS server is a Synology RackStation RS3617xs.

Tore

Noticed something interesting now:

$ test -w /nfshome && echo rw || echo ro
ro
$ test -w /nfshome/bin && echo rw || echo ro
rw

This seems to match Dolphin's behaviour. I can use Dolphin to manage files inside subdirectories just fine, just not at the top-level mount point. But even though "test -w" suggests otherwise, the top-level mount point is writeable just fine. Curious.

Seems like with dolphin 18.08.0-1 (arch version) I can create folders just fine on the root dir. 

If anyone else also can confirm then I'll mark this from my side as resolved.

Can confirm. Looks like something fixed this, yay.

*** Bug 400293 has been marked as a duplicate of this bug. ***