Normally, thunar would allow you to copy a file to a SMB share that you have read/write access to. Recently, it now shows a "Destination is read-only" warning instead and fails to perform the copy. SMB share is mounted by browsing to "smb://server/share" in thunar. SMB is presented with default options on Windows 10 build 1809 Issue also confirmed when accessing a synology NAS SMB share. The regression begins with this commit: https://git.xfce.org/xfce/thunar/commit/?id=d4cc7e6fc0a39a0d554375c7530df7a20802e354
System info: Distro: Manjaro Samba: 4.10.2-1 Another note: issue was also tested and confirmed with a Samba share that is completely read-write accessible to all users and guests hosted by another Manjaro computer.
While I'm not very familiar with C, I think I may have found the issue. In this particular instance, the following returns "null" instead of true or false: thunar/thunar-transfer-job.c [in line 838]: g_file_info_get_attribute_boolean (dest_info, G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE) Adding the following conditional appears to solve the issue: @@ -835,16 +835,18 @@ thunar_transfer_job_verify_destination (ThunarTransferJob *transfer_job, if (dest_info != NULL) { - if (!g_file_info_get_attribute_boolean (dest_info, G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE)) - { - g_set_error (error, G_IO_ERROR, G_IO_ERROR_READ_ONLY, - _("Error while copying to \"%s\": The destination is read-only"), - dest_name); - - succeed = FALSE; - } - - g_object_unref (G_OBJECT (dest_info)); + if (g_file_info_get_attribute_boolean (dest_info, G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE) != NULL) + { + if (!g_file_info_get_attribute_boolean (dest_info, G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE)) + { + g_set_error (error, G_IO_ERROR, G_IO_ERROR_READ_ONLY, + _("Error while copying to \"%s\": The destination is read-only"), + dest_name); + + succeed = FALSE; + } + g_object_unref (G_OBJECT (dest_info)); + } } }
Thanks for reporting, and thanks for the proposed fix ! The doc of "g_file_info_get_attribute_boolean" does not mention "NULL" as possible return value .. though other g_file_info methods actually do return NULL if the attribute was not found. So I guess the gtk3 doc is missing the NULL return on "attribute not found". https://developer.gnome.org/gio//2.54/GFileInfo.html#g-file-info-get-attribute-boolean Now, if you are motivated to further investigate, it would be interesting to know, why the attribute G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE actually is missing for your file. I cannot reproduce the bug here, since I dont have a SMB share ... probably Andre Miranda will take a look at this bug soon.
If I have time, I might look into that. If I were to guess, I'd say it's likely due to a limitation or bug in the way the share is mounted via gvfs/fuse. Also, just noticed a minor flaw in the patch code above. The curly bracket I added at the end needs to be before the "g_object_unref (G_OBJECT (dest_info));", as un-referencing that variable should not be dependent on the conditional I added. I'd edit the previous comment, but that doesn't appear to be possible with this site. Fixed patch: @@ -835,16 +835,18 @@ thunar_transfer_job_verify_destination (ThunarTransferJob *transfer_job, if (dest_info != NULL) { - if (!g_file_info_get_attribute_boolean (dest_info, G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE)) - { - g_set_error (error, G_IO_ERROR, G_IO_ERROR_READ_ONLY, - _("Error while copying to \"%s\": The destination is read-only"), - dest_name); - - succeed = FALSE; - } - - g_object_unref (G_OBJECT (dest_info)); + if (g_file_info_get_attribute_boolean (dest_info, G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE) != NULL) + { + if (!g_file_info_get_attribute_boolean (dest_info, G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE)) + { + g_set_error (error, G_IO_ERROR, G_IO_ERROR_READ_ONLY, + _("Error while copying to \"%s\": The destination is read-only"), + dest_name); + + succeed = FALSE; + } + } + g_object_unref (G_OBJECT (dest_info)); } }
Does Andre know about this bug report? Should he be added to the CC list?
Dont worry, he is subscribed to the bugzilla rss feed, additionally I asked him to take a look if he has time. He probabl is just busy with reallife ... possibly on vaccation.
> I'd edit the previous comment, but that doesn't appear to be possible with this site. Nope, bugzilla does not allow so. Hope we will move to gitlab soon. Note that you can attach patches as attachment. Like that you can replace older patches. ( Would be nice to have a patch, produced with "git format-patch", so we can give credit to the author in an easy way )
Created attachment 8504 Patch to only perform boolean attribute check if attribute is defined Thanks. Uploaded full patch as attachment
g_file_info_get_attribute_boolean either returns TRUE or FALSE, when you compare its result with NULL you are actually comparing it to 0 which is the same of FALSE: https://developer.gnome.org/glib/stable/glib-Standard-Macros.html#FALSE:CAPS So what your patch really does it to make impossible to reach g_set_error, thus it seems to fix the problem for you. Try to build and run the following sample: https://gist.github.com/andreldm/007a07c2fd361e938cac42e1d5c04bd9 Please post here the output you get. Also check how Nautilus or Nemo behave with your SMB share.
Good to know. That's a shame. Ran the following after using Thunar to mount "smb://twr-lnx-1811.local/public/", which is a completely accessible (perms = 777) share. $ ./fs_sample "smb://twr-lnx-1811.local/public/"Unable to detect file type of smb://twr-lnx-1811.local/public/ (fs_sample:26315): GLib-GIO-CRITICAL **: 22:23:38.904: g_file_info_get_attribute_boolean: assertion 'G_IS_FILE_INFO (info)' failed is smb://twr-lnx-1811.local/public/ on read only filesystem? FALSE (fs_sample:26315): GLib-GIO-CRITICAL **: 22:23:38.904: g_file_info_get_attribute_boolean: assertion 'G_IS_FILE_INFO (info)' failed can smb://twr-lnx-1811.local/public/ be written? FALSE (fs_sample:26315): GLib-GObject-CRITICAL **: 22:23:38.904: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (fs_sample:26315): GLib-GObject-CRITICAL **: 22:23:38.904: g_object_unref: assertion 'G_IS_OBJECT (object)' failed I tested Nemo; it can browse and copy files to/from the share as expected.
Well, GIO doesn't work with smb/sftp protocols, please open a terminal window on the remote location (e.g. via Thunar context menu), then run "/path/to/fs_sample $(pwd)", the output should not contain error messages, for example: $ ~/fs_sample $(pwd) /run/user/1000/gvfs/sftp:host=192.168.1.102/home/andre is a directory is /run/user/1000/gvfs/sftp:host=192.168.1.102/home/andre on read only filesystem? FALSE can /run/user/1000/gvfs/sftp:host=192.168.1.102/home/andre be written? TRUE
Ah, ok. This should be correct now: $ ~/fs_sample $(pwd) /run/user/1000/gvfs/smb-share:server=twr-lnx-1811.local,share=public is a directory is /run/user/1000/gvfs/smb-share:server=twr-lnx-1811.local,share=public on read only filesystem? FALSE can /run/user/1000/gvfs/smb-share:server=twr-lnx-1811.local,share=public be written? FALSE
Ok, seems we are getting somewhere, indeed GIO is for some reason telling us that folder is not writable. I looked into Nemo's source, the only place G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE appears is in nemo-file.c which exposes this as "nemo_file_can_write". However that function is not called in "verify_destination", just G_FILE_ATTRIBUTE_FILESYSTEM_READONLY (and free space) is checked: https://github.com/linuxmint/nemo/blob/85f9907528c2d47fc111260c3baf05843f5d6d32/libnemo-private/nemo-file-operations.c#L3008 One more favor, can you try Nautilus?
Looks like Nautilus can browse the share, as well as copy/paste files to/from the share. Note: It cannot copy/paste files to/from thunar, only to/from other nautilus windows. Nemo does not have this limitation.
I was able to reproduce the bug with an ancient Windows XP VM I had around, issue reported upstream: https://gitlab.gnome.org/GNOME/glib/issues/1779
@Alex from the upstream bug we can conclude that we cannot blindly trust G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE, not really gio or gvfs' fault because they depend on third party components that may be flawed. Removing that check now Thunar just fails telling/asking "Permission denied. Do you want to skip? Retry | Yes to all | Yes | Cancel". Reading git history I learned that those checks were introduced by fixing Bug 5658, which asked only to check free space on FS. I guess those checks are meant to tell the user exactly why the operation failed. The options I see: 1) Remove only the G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE check. If the FS is read-only Thunar will fail with a generic message, the user will need to find out why, but now we are free of false positives. 2) Skip that only for remote FS with G_FILE_ATTRIBUTE_FILESYSTEM_REMOTE (untested). I would go with option #1, what do you think?
An extensive investigation :) Well done ! #1 would be fine for me. Probably would be good to have a comment in the code to explain why G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE is not used (or a link to this bug)
I seem to experiencing the same issue but instead with a WebDAV share. I reported it to the Arch Linux bug tracker. https://bugs.archlinux.org/task/62705
Andre Miranda referenced this bugreport in commit 068b25a276130d1a93c23561d72dd875180f6924 Do not check G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE anymore (Bug #15367) https://git.xfce.org/xfce/thunar/commit?id=068b25a276130d1a93c23561d72dd875180f6924
Andre Miranda referenced this bugreport in commit 46f4f0f0fa1edb3535aacdef76017ee41eb55047 Do not check G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE anymore (Bug #15367) https://git.xfce.org/xfce/thunar/commit?id=46f4f0f0fa1edb3535aacdef76017ee41eb55047