! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Regression: thunar detects writable share as being read-only
Status:
RESOLVED: FIXED

Comments

Description lectrode 2019-05-07 02:18:23 CEST
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
Comment 1 lectrode 2019-05-07 02:24:12 CEST
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.
Comment 2 lectrode 2019-05-08 21:15:47 CEST

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));
+          }
         }
     }
Comment 3 alexxcons editbugs 2019-05-08 21:53:17 CEST
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.
Comment 4 lectrode 2019-05-09 00:00:23 CEST
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));
         }
     }
Comment 5 lectrode 2019-05-09 18:36:01 CEST
Does Andre know about this bug report? Should he be added to the CC list?
Comment 6 alexxcons editbugs 2019-05-09 21:50:49 CEST
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.
Comment 7 alexxcons editbugs 2019-05-09 21:57:26 CEST
> 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 )
Comment 8 lectrode 2019-05-09 22:07:56 CEST
Created attachment 8504 
Patch to only perform boolean attribute check if attribute is defined

Thanks. Uploaded full patch as attachment
Comment 9 Andre Miranda editbugs 2019-05-14 06:08:58 CEST
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.
Comment 10 lectrode 2019-05-14 08:24:36 CEST
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.
Comment 11 Andre Miranda editbugs 2019-05-14 17:33:03 CEST
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
Comment 12 lectrode 2019-05-14 17:53:28 CEST
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
Comment 13 Andre Miranda editbugs 2019-05-14 18:12:35 CEST
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?
Comment 14 lectrode 2019-05-14 18:20:06 CEST
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.
Comment 15 Andre Miranda editbugs 2019-05-15 03:48:54 CEST
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
Comment 16 Andre Miranda editbugs 2019-05-22 05:41:22 CEST
@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?
Comment 17 alexxcons editbugs 2019-05-22 13:41:32 CEST
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)
Comment 18 gero3977 2019-05-22 17:47:55 CEST
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
Comment 19 Git Bot editbugs 2019-05-28 03:17:24 CEST
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
Comment 20 Git Bot editbugs 2019-05-28 03:18:41 CEST
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

Bug #15367

Reported by:
lectrode
Reported on: 2019-05-07
Last modified on: 2019-05-28

People

Assignee:
Xfce Bug Triage
CC List:
6 users

Version

Attachments

Additional information