GNOME Bugzilla – Bug 688714
Can't create new archives in mounted samba shares
Last modified: 2016-09-15 05:26:24 UTC
I have a large directory, almost 50Gb and 45.000 files shared by samba 3.6.3 on ubuntu 12.04.1 LTS server. When trying to add some files to an archive, file roller reports insufficient permissions. It can't add new files to an existing archive either, only the extraction of files is permitted. Steps to reproduce: - mount the shared directory; - select any file, or group of files; - right click on the selection and choose "Compress..." - click on "Create". What happens: File-roller reports insufficient privileges. What should happen: a new archive containing the selected files is created in the remote directory. ProblemType: Bug DistroRelease: Ubuntu 12.10 Package: file-roller 3.6.0-0ubuntu3 ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5 Uname: Linux 3.5.0-17-generic x86_64 ApportVersion: 2.6.1-0ubuntu6 Architecture: amd64 Date: Fri Oct 26 15:39:55 2012 InstallationDate: Installed on 2012-10-22 (4 days ago) InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5) MarkForUpload: True SourcePackage: file-roller UpgradeStatus: No upgrade log present (probably fresh install)
Bug still persist after updating to version 3.6.1.1.
Can you create files with other applications ?
Nautilus has no problems in creating new folders and files from templates. However, I tried in saving a new file directly from Libreoffice Writer, Calc and Impress, Gimp, Eye of Gnome, Evince, Shotwell, Firefox, Thunderbird and PDFmod all from Ubuntu 12.10 repositories. Only saving from Shotwell and Evince worked. All others returned an I/O error, like file-roller does. Mozilla Firefox, Thunderbird and PDFmod report that they can't use a remote directory instead.
So, if the bug is not really in file-roller, I'm going to file a new bug in Launchpad. I just don't really know which package to refer, I only understand that it is probably related to Samba or gvfs.
I tried saving from The Gimp, Libreoffice and Mozilla applications directly to /run/user/<username>/gvfs/<share> and it worked. I also installed the Calligra (KDE) suite and tried saving from the various Flow, Stage and Sheets applications to the share using their share browser and it worked. Then, I tried saving an archive from file-roller to /run/user/<username>/gvfs/<share> and... it didn't work. Same I/O error as before.
See Bug 724497. Problem is that G_FILE_ATTRIBUTE_ACCESS_CAN_WRITE isn't set by majority of backends, so it fails on the check before it starts to write... Would be better probably to try create file and check error. However when I set this flag to TRUE, File roller fails by SIGABRT. Backtrace is attached in the mentioned bug...
I proposed patch for SMB backend to set access::can-write, however applications should not rely on those attributes and should not fail if g_file_info_has_attribute is false. Also patch fixing the SIGABRT was proposed in Bug 767577, althought it still doesn't work... As per the gvfs logs, it seems that file roller doesn't even read the file, just do only some query info calls and then exits without any error message...
*** Bug 767605 has been marked as a duplicate of this bug. ***
Created attachment 329763 [details] [review] fr-new-archive-dialog: Do not fail if access::can-write is not set I've just realized that the patch for GVfs doesn't actually solve "You don't have permissions to create an archive in this folder" error, because access::can-write is set only for files, because it can't be reliably determined for folders. So here is patch for file-roller to use g_file_info_has_attribute to check whether attribute is set and do not fail if the attribute is not set.
Created attachment 329767 [details] debug output from file-roller Attachment contains debug output from file roller, which was executed in the following way: "file-roller -d /run/user/1000/gvfs/smb-share\:server\=localhost\,share\=oholy/gnome/gvfs/README". However I don't see in the output anything like the following, which I see with local path: [FR] /home/oholy/gnome/file-roller/src/fr-process.c:956 (execute_current_command): 0/2) cd /home/oholy/gnome/gvfs zip -y -6 /home/oholy/gnome/gvfs/.fr-mSuMaS/README.zip -- README [FR] /home/oholy/gnome/file-roller/src/fr-process.c:956 (execute_current_command): 1/2) mv -f -- /home/oholy/gnome/gvfs/.fr-mSuMaS/README.zip /home/oholy/gnome/gvfs/README.zip [FR] /home/oholy/gnome/file-roller/src/fr-process.c:956 (execute_current_command): 2/2) cd /tmp rm -rf /home/oholy/gnome/gvfs/.fr-mSuMaS So zip/mv/rm is not even called from some reason and no error is reported. Don't you have any idea why?
(In reply to Ondrej Holy from comment #7) > ... > > As per the gvfs logs, it seems that file roller doesn't even read the file, > just do only some query info calls and then exits without any error > message... Sorry for mistification, it does read the file, I used wrong path before. However file-roller should return some error that the file doesn't exists and do not exit silently, but this is another bug...
Worth to mention that this happens with "zip", but it seems it works correctly for e.g. "tar".
(In reply to Ondrej Holy from comment #9) > Created attachment 329763 [details] [review] [review] > fr-new-archive-dialog: Do not fail if access::can-write is not set > > > I've just realized that the patch for GVfs doesn't actually solve "You don't > have permissions to create an archive in this folder" error, because > access::can-write is set only for files, because it can't be reliably > determined for folders. So here is patch for file-roller to use > g_file_info_has_attribute to check whether attribute is set and do not fail > if the attribute is not set. patch pushed to master, thank you.