Using dolphin 17.08.3-1 package on Arch. I've mounted an NFS share v3 and while I can write on the root dir from terminal with my user I can't write from Dolphin, get no options to create new file or past any files from Dolphin. Tried the same thing from Debian 9 with Dolphin 16.08.3 and it works fine there. not sure how to troubleshoot further, running Dolphin from terminal gives no specific error and I see nothing relevant on journal logs.
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. ***