GNOME Bugzilla – Bug 724497
Can't create compressed archives or raw disk images on SMB share.
Last modified: 2018-09-21 17:39:07 UTC
I can't create compressed archives (using file-roller or the zip command) on an SMB share to which I have full read/write permissions. I also can't create disk images on the drive, using dd, ddrescue or palimpset. I can copy files to the drive, which works as expected. When I mount the share using "mount -t cifs..." everything works, so I believe the bug is in gvfs. I've observed the same symptoms on Fedora 20 and Arch, so I don't believe this is a distribution specific issue. I don't think I'm the only one with this issue: https://bugzilla.gnome.org/show_bug.cgi?id=688714 It also appears that the issue may effect FTP shares: http://askubuntu.com/questions/213928/create-archive-on-ftp-in-ubuntu-12-10 File roller appears to be failing the following check: " if (! g_file_info_get_attribute_boolean (parent_info, G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE)) { dialog = _gtk_error_dialog_new (GTK_WINDOW (self), GTK_DIALOG_MODAL, NULL, _("Could not create the archive"), "%s", _("You don't have permission to create an archive in this folder")); gtk_dialog_run (GTK_DIALOG (dialog)); gtk_widget_destroy (GTK_WIDGET (dialog)); g_object_unref (parent_info); g_object_unref (file); return NULL; }"
The files in the /run/user/1000/gvfs/ directory (or .gvfs) are provided by FUSE as fallback and some functionality is missing. So that is the reason probably, why mount -t cifs... works and gvfs doesn't. However I am able to create archives using File Roller and zip command in the /run/user/1000/gvfs/smb-share... on Fedora 20. Do you see any errors when using e.g. zip command? But it fails for me when using "Compress..." item from Nautilus...
I've just realized that file roller is using gio api. It is possible to create archive to the path /run/user/1000/gvfs/smb..., but it isn't work with uri smb://...
Created attachment 270489 [details] backtrace Problem is that G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE isn't set by majority of backends, so it fails on the check mentioned in the first comment. However when I set this flag, File roller fails by SIGABRT. Backtrace is attached...
Created attachment 329761 [details] [review] smb: Set always G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE for files G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE is set for regular files only when S_IWUSR is not set currently (i.e. FALSE only). It seems to me that it is reliable to set this to TRUE for regular files in other cases. Applications should not rely on those attributes, however it is crucial for some apps which rely on them still (e.g. File Roller).
Actally this patch doesn't solve "You don't have permissions to create an archive in this folder" error, because the attribute is set only for files. There isn't any reliable way, how to determine whether directory is writable or not, see Bug 581368. So file roller code needs to be changed to not rely on this attribute...
Comment on attachment 329761 [details] [review] smb: Set always G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE for files Pushed as commit 2c6f2ff . $ ls -l total 0 ---------- 1 oholy oholy 0 Jun 13 17:10 a --w--w--w- 1 oholy oholy 0 Jun 13 17:10 b $ gvfs-ls -l -a "access::can-write" smb://server/share/ a 0 (regular) access::can-write=FALSE b 0 (regular) access::can-write=TRUE
(In reply to Ondrej Holy from comment #5) > Actally this patch doesn't solve "You don't have permissions to create an > archive in this folder" error, because the attribute is set only for files. > There isn't any reliable way, how to determine whether directory is writable > or not, see Bug 581368. So file roller code needs to be changed to not rely > on this attribute... I proposed patch for file-roller to not rely on the attribute. There isn't any other obvious gvfs-related problem, but let the bug open for now..
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/225.