I am not sure if this is the correct component to file the bug for. * my environment * Fedora 28 x86_64 computer joined to Microsoft Active Directory (AD) with realmd and SSSD. POSIX attributes are stored in and coming from AD. SELinux is disabled. USER's home directory is served over NFS. In order to use different servers we symlink the home directory. So different servers can be used. USER's home directory path is a symlink. The symlink is located on a share of one server. This share is mounted read-only. The symlink points to a different local path. That path can point to a different server. It looks like this: $ getent passwd USER USER:*:12345:6789:NAME OF USER:/usr/home/USER:/bin/bash $ ls -ld /usr/home/USER lrwxrwxrwx 1 root root 21 May 8 2009 /usr/home/USER -> /usr/people/home/USER $ ls -ld /usr/people/home/USER drwx------ 54 USER GROUP 16384 Sep 25 18:47 /usr/people/home/USER $ ls -ld /usr/home /usr/people/home drwxr-xr-x 2 root root 28672 Sep 21 11:47 /usr/home drwxr-xr-x 331 root root 28672 Sep 21 11:47 /usr/people/home The mount point options are (additional spaces and truncation by me): $ mount | grep home nas1:/home on /usr/people/home type nfs (rw,...same...) nas1:/meta on /usr/home type nfs (ro,...same...) * finding the cause of the problem * It seems only the first mount point options are obeyed (read-only folder). The symlink does not seem to be resolved (realpath?) to the read-write folder. I edited /etc/fstab (changed ro to rw for /usr/home) and rebooted the computer. Afterwards Thunar has no problems anymore to copy/cut-paste files with content to home directory. I want to keep mounting the share with the symlinks read-only because it is small. /usr/home - maximum size is 16 MB /usr/people/home - maximum size is much larger than 16 MB I try to create a guide to create a similar environment for local testing. When done I will post it as comment. * the problem behavior * These actions fail with an error message from Thunar ("The destination is read-only." see below for more information): - drag-and-drop an email attachment from Evolution to the homedirectory - in thunar right mouse button click on file, select copy; go to USERS's homedirectoy (house icon on the left side in PLACES); Edit -- Paste - in thunar copy/cut a file with content (a single letter is sufficient); pasting into /usr/home/USER These actions work without problem: - in thunar copy/cut a file with content (a single letter is sufficient); pasting into /usr/people/home/USER - in thunar copy/cut an *empty* file and paste it in either homedirectory path - in Evolution right mouse button click on the same email attachment and using "Save as" to save the file in the homedirectory - in terminal: echo "test" > /tmp/test ; cp /tmp/test.txt /usr/home/USER - in terminal: echo "test" > /tmp/test ; cp /tmp/test.txt /usr/people/home/USER - using `nautilus` or `dolphin` to copy/cut-paste files (with and without content) to either home directory * the error message from thunar * After I paste the file 2 pop-up windows appear. Window 1 with title and content is: ---8<--- File Operation Progress -- Copying files to "USER"... Colleting files... [[]] ---8<--- Window 2 with title and content is: ---8<--- -- Error while copying to "USER". The destination is read-only. [Close] ---8<--- * more information* With testing I confirmed: - not a problem of tcsh vs bash as loginshell. - not reproducible with local account and symlinked local folders: root@box:~ # useradd -m test root@box:~ # passwd test ... root@box:~ # ls -ld /home drwxr-xr-x. 3 root root 4096 Jun 20 18:05 /home root@box:~ # mkdir /home2 root@box:~ # mv /home/test /home2 root@box:~ # ls -ld /home /home2 /home2/test drwxr-xr-x. 2 root root 4096 Sep 25 19:23 /home drwxr-xr-x 3 root root 4096 Sep 25 19:23 /home2 drwx------ 17 test test 4096 Sep 25 19:20 /home2/test root@box:~ # ln -s /home2/test /home root@box:~ # ls -l /home total 0 lrwxrwxrwx 1 root root 11 Sep 25 19:23 test -> /home2/test same result with / as new home basedir
The mentioned error comes from thunar_transfer_job_verify_destination, which beside other things, gets filesystem info and checks if it's not read-only, all using GIO functions. Nautilus code[1] uses the same functions, except that it passes "filesystem::free,filesystem::readonly" to g_file_query_filesystem_info while thunar passes "filesystem::*". The documentation says "The wildcard "*" may be used to match all keys and namespaces, or "namespace::*" will match all keys in a given namespace." so the wildcard still must be valid. Unfortunately I don't have a similar environment as described (Windows AD, NFS, etc) to try to reproduce. 1 - https://gitlab.gnome.org/GNOME/nautilus/blob/62ba6d83df162b149785ed10a13d242ee1a13dc1/src/nautilus-file-operations.c
Thank you for very fast and detailed feedback. I try to set up a Fedora 29 computer in our productive environment. That will take some time. I found a way to reproduce the problem on a single computer with local accounts. The computer is NFS server and client at the same time. ## as far as I remember I did this (I forgot to take notes) # download ISO file: #firefox https://getfedora.org/en/workstation/prerelease/ wget --timestamping "https://download.fedoraproject.org/pub/fedora/linux/releases/test/29_Beta/Workstation/x86_64/iso/Fedora-Workstation-netinst-x86_64-29_Beta-1.5.iso" # prepare test computer # with ISO file install Fedora 29 x86_64 virtual machine with Xfce desktop; no subgroups enabled # create user account; pick a name you like, this account will be referenced with "USER" # we will create another local account to reproduce the bug; this account is referenced with "name" # log in to virtual machine with GUI to enable SSH for easier access from host; maybe sshd.service had been enabled by default, I cannot remember sudo systemctl enable --now sshd.service # in case of problems try to disable firewall sudo systemctl disable --now firewalld.service ## at this point I started to take notes # log in with SSH to guest ssh USER@GUEST # switch to root sudo su # install NFS server dnf install -y nfs-utils # create directories for NFS shares and mountpoints mkdir /share1 /share2 /mount1 /mount2 # configure shares echo "/share1 localhost(ro)" | sudo tee -a "/etc/exports" echo "/share2 localhost(rw)" | sudo tee -a "/etc/exports" # start NFS server on system start; and right now systemctl enable --now nfs-server.service # create user account useradd -m name # set password passwd name # change path of user home directory vipw # change from: #name:x:1001:1001::/home/name:/bin/bash # to: #name:x:1001:1001::/mount1/name:/bin/bash # move user home directory mv /home/name /share2 # create symlink ln -s /share2/name ../share1 # mount NFS shares to mountpoints echo "localhost:/share1 /mount1 nfs ro,defaults 0 0" | sudo tee -a "/etc/fstab" echo "localhost:/share2 /mount2 nfs rw,defaults 0 0" | sudo tee -a "/etc/fstab" # reload server configuration systemctl reload nfs-server.service # SELinux: disable permanently vim /etc/selinux/config # change from: SELINUX=enforcing # to: SELINUX=disabled # reboot required reboot # log in to GUI session with user "name" # start thunar from lower panel; "`thunar` -- Help -- About" prints version: 1.8.1; package is: Thunar-1.8.1-20.fc29.x86_64 (rpm -qf `which thunar`) # in `thunar` address bar displays path "/share2/name/" # you can create files and folders with thunar in the directory # you can copy-paste files and folders with and without content from and to the directory (select file/folder, press Ctrl+c, press Ctrl+v) # to reproduce the bug: # in `thunar` on left side at "PLACES" click on home directory icon labeled "name" # address bar displays path "/mount1/name/" # you can create files and folders with thunar in the directory # you can copy-paste files without content from and to the directory (select file, press Ctrl+c, press Ctrl+v) # you cannot copy-paste folders with and without content from and to the directory # you cannot copy-paste files with content (single character is sufficient) from and to the directory # error message appears: ---8<--- Error while copying to "name". The destination is read-only. [Close] ---8<--- ## useful commands # list running sessions loginctl # kill a stuck session loginctl kill-session 4 # delete user folder and account to start over rm -rf /share2/name
What what it is worth: On a Fedora 29 (Thunar 1.8.1) computer in the productive environment it is the same problem.
I followed your instructions to the letter, but nfs-server.service is failing to start and I can't login with the created user. Can you please automate (bash script) the setup until the point where I can manually reproduce the issue? Or share the virtual machine disk (I know it's big, but I can download it ASAP and you may get rid it afterwards)?
I installed a new virtual machine from scratch with the guide from comment 2 and I have no problem with nfs-server.service. I can share the virtual machine, no problem. Original size is 3,8 GiB. Compressed it is 1,2 GiB. I will upload the archive and sent you the download link to your personal email address. I updated the guide (easier to follow due to numbered steps; removed relative path for symlink creation, include prompt, use root user account). 1. download ISO file of Fedora 29 x86_64 BETA: $ wget --timestamping "https://ftp-stud.hs-esslingen.de/pub/fedora/linux/releases/test/29_Beta/Workstation/x86_64/iso/Fedora-Workstation-netinst-x86_64-29_Beta-1.5.iso" 2. install a new virtual computer from downloaded ISO file, f.i. using VirtualBox ; set optical disc below hard disk as boot option ; set Network option from "NAT" to "Bridged Adapter" 3. select "Install Fedora 29" and press enter 4. set language to "English" and "English (United States)" and press [Continue] 5. press [I want to proceed] 6. at hub: set "Installation Destination" to hard disk of virtual computer and press [Done] 7. at hub: set "Software Selection" to "Xfce Desktop" and press [Done] 8. at hub: click on [Begin Installation] 9. set root password for root account ; click on [Done] ; create user account with administrative rights and set password ; click on [Done] 10. when installation is done click on [Reboot] 11. log in as user to virtual computer 12. click on [Use default config] 13. in terminal execute commands: $ sudo systemctl disable --now firewalld.service $ ip a # to get IP to be able to continue the IP address, f.i. 192.168.2.103 14. log out from virtual guest computer 15. log in from host via SSH to guest computer: [user@HOST ~]$ ssh root@192.168.2.103 [root@GUEST ~]# dnf install -y nfs-utils [root@GUEST ~]# mkdir /share1 /share2 /mount1 /mount2 [root@GUEST ~]# echo "/share1 localhost(ro)" | sudo tee -a "/etc/exports" /share1 localhost(ro) [root@GUEST ~]# echo "/share2 localhost(rw)" | sudo tee -a "/etc/exports" /share2 localhost(rw) [root@GUEST ~]# cat "/etc/exports" /share1 localhost(ro) /share2 localhost(rw) [root@GUEST ~]# systemctl enable --now nfs-server.service Created symlink /etc/systemd/system/multi-user.target.wants/nfs-server.service → /usr/lib/systemd/system/nfs-server.service. [root@GUEST ~]# systemctl status nfs-server.service ● nfs-server.service - NFS server and services Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; vendor vendor preset: disabled) Drop-In: /run/systemd/generator/nfs-server.service.d └─order-with-mounts.conf Active: active (exited) since Mon 2018-10-15 22:37:29 CEST; 11s ago Process: 1836 ExecStart=/bin/sh -c if systemctl -q is-active gssproxy; then systemctl restart gssproxy ; fi (code=exited, status=0/SUCCESS) Process: 1823 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, status=0/SUCCESS) Process: 1822 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS) Main PID: 1836 (code=exited, status=0/SUCCESS) Oct 15 22:37:29 GUEST systemd[1]: Starting NFS server and services... Oct 15 22:37:29 GUEST systemd[1]: Started NFS server and services. [root@GUEST ~]# useradd -m name [root@GUEST ~]# passwd name [root@GUEST ~]# vipw # change from: name:x:1001:1001::/home/name:/bin/bash # change to: name:x:1001:1001::/mount1/name:/bin/bash [root@GUEST ~]# mv /home/name /share2 [root@GUEST ~]# ln -s /share2/name /share1/name [root@GUEST ~]# echo "localhost:/share1 /mount1 nfs ro,defaults 0 0" | sudo tee -a "/etc/fstab" localhost:/share1 /mount1 nfs ro,defaults 0 0 [root@GUEST ~]# echo "localhost:/share2 /mount2 nfs rw,defaults 0 0" | sudo tee -a "/etc/fstab" localhost:/share2 /mount2 nfs rw,defaults 0 0 [root@GUEST ~]# cat "/etc/fstab" | grep -v "#" /dev/mapper/fedora-root / ext4 defaults 1 1 UUID=44b9fca5-b3a9-425f-96ef-9725d31c4ab3 /boot ext4 defaults 1 2 /dev/mapper/fedora-swap swap swap defaults 0 0 localhost:/share1 /mount1 nfs ro,defaults 0 0 localhost:/share2 /mount2 nfs rw,defaults 0 0 [root@GUEST ~]# systemctl reload nfs-server.service [root@GUEST ~]# systemctl status nfs-server.service ● nfs-server.service - NFS server and services Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; vendor preset: disabled) Drop-In: /run/systemd/generator/nfs-server.service.d └─order-with-mounts.conf Active: active (exited) since Mon 2018-10-15 22:37:29 CEST; 4min 43s ago Process: 1907 ExecReload=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS) Process: 1836 ExecStart=/bin/sh -c if systemctl -q is-active gssproxy; then systemctl restart gssproxy ; fi (code=exited, status=0/SUCCESS) Process: 1823 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, status=0/SUCCESS) Process: 1822 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS) Main PID: 1836 (code=exited, status=0/SUCCESS) Oct 15 22:37:29 GUEST systemd[1]: Starting NFS server and services... Oct 15 22:37:29 GUEST systemd[1]: Started NFS server and services. Oct 15 22:42:01 GUEST systemd[1]: Reloading NFS server and services. Oct 15 22:42:01 GUEST systemd[1]: Reloaded NFS server and services. [root@GUEST ~]# vim /etc/selinux/config # change from: SELINUX=enforcing # change to: SELINUX=disabled [root@GUEST ~]# ls -l /share* /mount* /mount1: total 0 lrwxrwxrwx 1 root root 12 Oct 15 22:41 name -> /share2/name /mount2: total 4 drwx------ 15 name name 4096 Oct 15 22:51 name /share1: total 0 lrwxrwxrwx. 1 root root 12 Oct 15 22:41 name -> /share2/name /share2: total 4 drwx------. 15 name name 4096 Oct 15 22:51 name [root@GUEST ~]# reboot 16. after reboot log in to GUI session with user "name" to an Xfce session 17. click on [Use default config] 18. start "File Manager" (=`thunar`) from lower panel; "Help -- About Thunar" prints version: 1.8.2 in Thunar's address bar the path is shown as "/share2/name/" ### now to reproduce the bug: 19. in `thunar` on left side at "PLACES" click on home directory icon labeled "name" 20. the address bar displays the path as "/mount1/name/" 21. you cannot copy-paste folders with and without content from and to the directory ; you cannot copy-paste files with content (single character is sufficient) from and to the directory the error message prints this text: ---8<--- Error while copying to "name". The destination is read-only. [Close] ---8<---
Dear Andre Miranda, an email with the download link should be in your inbox. Thank you very much for your help.
Created attachment 8306 fs_sample.c Hi René, Sorry for the very long time to reply and thank you for preparing and sending me that VM, now I can easily reproduce the issue, it's not possible to move a non-empty file from desktop to the user's home folder. With the attached sample I was able to confirm that GLib thinks the home folder (i.e. /mount1/name) is read-only, its output is: is /mount1/name/content read only? FALSE is /mount1/name read only? TRUE is /mount1/name/Desktop read only? FALSE I tried Nautilus, and it also does not allow one to paste files to home, no errors, the Paste option is just disabled. Nemo complains it cannot get information for file “/mount1/name/Desktop/content”: No such file or directory. With all this info, I'm almost sure it's a GLib issue, it's wrongly reporting the home directory to be read-only. I tried my best, but I couldn't find any relevant issue on GNOME's gitlab[1] or the old bugzilla[2], so I ask you to report upstream. 1 - https://gitlab.gnome.org/GNOME/glib/issues 2 - https://bugzilla.gnome.org
Hi Andre, thank you very much for your help. I would not have been able to do it without you. :) I reported it upstream at: https://gitlab.gnome.org/GNOME/glib/issues/1689
Hi Andre, at: https://gitlab.gnome.org/GNOME/glib/issues/1689#note_472730 Ondrej Holy from GNOME's GitLab instance wrote: ---8<--- ... the problem is that Thunar returns `The destination is read-only`. error from https://github.com/xfce-mirror/thunar/blob/master/thunar/thunar-transfer-job.c#L830. This is because `G_FILE_ATTRIBUTE_FILESYSTEM_READONLY` is set to `TRUE` for `/mount1/name`. But I think that Thunar should check `G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE` instead in this case, which is by the way set to `TRUE`. Because the filesystem attributes are obtained for the symlink file itself, not for its target. This behavior was probably changed by commit 0f5017fb (https://gitlab.gnome.org/GNOME/glib/commit/0f5017fb701b221846f04fa610c8429bbaa49136) recently. But I think it is right as it is now and that Thunar needs to be fixed. ---8<---
Andre Miranda referenced this bugreport in commit d4cc7e6fc0a39a0d554375c7530df7a20802e354 Correctly check if destination is writable (Bug #14718) https://git.xfce.org/xfce/thunar/commit?id=d4cc7e6fc0a39a0d554375c7530df7a20802e354
Andre Miranda referenced this bugreport in commit 3840d3ad78e754b75a932195382845f5486aec71 Correctly check if destination is writable (Bug #14718) https://git.xfce.org/xfce/thunar/commit?id=3840d3ad78e754b75a932195382845f5486aec71
Andre Miranda referenced this bugreport in commit d137b6f924476ec7fabbd4c4dcc8da9134984ce2 Correctly check if destination is writable (Bug #14718) https://git.xfce.org/xfce/thunar/commit?id=d137b6f924476ec7fabbd4c4dcc8da9134984ce2
Thanks for opening the upstream bug and pinging me back, I just pushed the fix for all branches, it will be available in the next releases.
Thank you very much :)