Red Hat Bugzilla – Bug 822349
geeqie refuses to remove files on samba mounts
Last modified: 2013-09-02 16:24:21 EDT
Description of problem:
When trying to delete a file on a samba mount, deletion is not allowed
on a more local disk deletion is allowed
other programs ant terminal can remove said files
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. try to delete a file on a samba mount
file no more
Debug output yields
31.744055 (+00000.000045) read ahead cancelled for :null
Change checked: OK: /mnt/photo/1.RAW/2012/04/2012-04-29-_POE4264.JPG
The Dialog says:
File Deletion failed
External editor returned error status.
File deletion failed /mnt/photo/1.RAW/2012/04/2012-04-29-_POE4264.JPG
If i recall correctly (this was a while ago though), this behaviour is not seen on similar NFS mounts
this problem is not very new but i just have not bothered to report it before
> a samba mount
What sort of share is it? Public, guest, logon, what server, what mount options, what mount point?
Could you attach an strace of such a file deletion attempt within Geeqie?
i'll try to get back with a trace later, in the meantime:
it is a QNAP ts 119 NAS
cut from /etc/fstab (with ids replaced by question marks:
//komposten/foto on /mnt/photo type cifs (rw,nosuid,nodev,noexec,relatime,sec=ntlm,unc=\\komposten\foto,username=???,uid=???,forceuid,gid=???,forcegid,addr=192.168.1.11,file_mode=0755,dir_mode=0755,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)
i honestly do not know all the parameters above or why i set them at the time
Hmmm, "nounix" even.
I don't know a test-case yet. Cannot reproduce so far with ordinary cifs mounts to either Samba or Windows servers.
Created attachment 585336 [details]
strace of starting - changig directory and trying to delete a file (that fails)
| unlink("/mnt/photo/1.RAW/2012/04/2012-04-29-_POE4264.JPG") = -1 ETXTBSY (Text file busy)
So, Geeqie asked the system to delete the file, but the system call returned -1, which is failure to delete the file due and an error condition. The ETXTBSY error number is strange, since that one means it's an executable file that's currently being executed.
If geeqie is running and looking at said file:
[pontus@palsternacka ~]$ rm /mnt/photo/1.RAW/2012/04/2012-04-29-_POE4264.JPG
rm: cannot remove `/mnt/photo/1.RAW/2012/04/2012-04-29-_POE4264.JPG': Text file busy
[pontus@palsternacka ~]$ killall geeqie
[pontus@palsternacka ~]$ rm /mnt/photo/1.RAW/2012/04/2012-04-29-_POE4264.JPG
and the file is removed
(i do not know if this helps, but anyway)
Doing the same in Nautilus works fine
Is it specific to the image that is being displayed? Can you delete other/undisplayed image files via the right-click menu of Geeqie's file browser column?
If you display an image from that samba mount, does running "lsof|grep mnt/photo" (from package "lsof") show the image file as still being open inside geeqie?
> Doing the same in Nautilus works fine
Geeqie uses an mmap'ped image loader, which could make a difference. The upstream bug tracker doesn't list any problem as yours, however.
[pontus@palsternacka ~]$ cd /mnt/photo/1.RAW/2012/test2/
[pontus@palsternacka test2]$ ls -laZ
drwxr-xr-x. pontus pontus system_u:object_r:cifs_t:s0 .
drwxr-xr-x. pontus pontus system_u:object_r:cifs_t:s0 ..
-rwxr-xr-x. pontus pontus system_u:object_r:cifs_t:s0 lookingatthisfile.JPG
-rwxr-xr-x. pontus pontus system_u:object_r:cifs_t:s0 notlookingatthisfileeither.JPG
-rwxr-xr-x. pontus pontus system_u:object_r:cifs_t:s0 notlookingatthisfile.JPG
-rwxr-xr-x. pontus pontus system_u:object_r:cifs_t:s0 previouslywatched file.JPG
[pontus@palsternacka test2]$ lsof |grep /mnt/photo
geeqie 1890 pontus 7r REG 0,38 4370165 8809155002396 /mnt/photo/1.RAW/2012/test2/lookingatthisfile.JPG
geeqie 1890 pontus 8r REG 0,38 7338642 8809155002399 /mnt/photo/1.RAW/2012/test2/notlookingatthisfileeither.JPG
geeqie 1890 pontus 9r REG 0,38 4889078 8809155002397 /mnt/photo/1.RAW/2012/test2/notlookingatthisfile.JPG
geeqie 1890 pontus 10r REG 0,38 6251524 8809155002398 /mnt/photo/1.RAW/2012/test2/previouslywatched file.JPG
bash 1934 pontus cwd DIR 0,38 0 8809155002395 /mnt/photo/1.RAW/2012/test2
lsof 1974 pontus cwd DIR 0,38 0 8809155002395 /mnt/photo/1.RAW/2012/test2
grep 1976 pontus cwd DIR 0,38 0 8809155002395 /mnt/photo/1.RAW/2012/test2
lsof 1977 pontus cwd DIR 0,38 0 8809155002395 /mnt/photo/1.RAW/2012/test2
[pontus@palsternacka test2]$ rm *
rm: cannot remove `lookingatthisfile.JPG': Text file busy
rm: cannot remove `notlookingatthisfileeither.JPG': Text file busy
rm: cannot remove `notlookingatthisfile.JPG': Text file busy
rm: cannot remove `previouslywatched file.JPG': Text file busy
Created attachment 585592 [details]
strace of last excercise
and no rightclicking - choosing another file than the one being watched does not function either, but that is kond of apparent when looking at the bash results in above comment
> geeqie 1890 pontus 9r REG 0,38
> 4889078 8809155002397
It's still open for reading. That doesn't happen here. And all close() system calls in the first strace returned success.
I guess for other directories (and other mounts), lsof does not list files as still open for you either.
i do not know whether i answer the right thing here but a lsof of watching pictures in my home directory shows no open files (and those can consequently be deleted without problems).
(my knowledge is not that great, but) i understand that the problem is that the file is still opened by geeqie despite they should have been closed. do you reckon this is still a geeqie problem or a server (or other) ditto ?
Since this only happens in geeqie (AFAIK) i tend to believe that it is a geeqie problem, but you OTOH - dos not see this on "similar" mounts.
(In reply to comment #11)
> geeqie problem, but you OTOH - dos not see this on "similar" mounts.
Well, Geeqie does not care where your pictures are stored and whether that is on a local filesystem or on a mounted one.
However, the filesystem's response to file related system calls could influence the code path in Geeqie or decide about whether what Geeqie does works (or is "compatible").
Also in your recent strace, one can, for example, look for the "notlookingatthisfileeither.JPG" and see that it is open()ed and close()d without error condition. One thing that might be a problem is the order of the open, mmap, close, munmap calls. Perhaps the close() call fails (despite the good return code 0), because the file is still mmap'ed, and munmap is called later. That's nothing I'd like to touch without a local test-case.
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 16's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" and open it against that version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.
I have had the same problem with Geeqie as described above by Pontus Enhager, and I have found this bug report by looking for a solution.
I also do have a samba server on a QNAP TS-1199 Turbo NAS, and my client is running openSuse 12.2/KDE, but I think the following applies to any distribution.
Finally I found by myself a workaround/solution for this problem.
In order to get Geeqie to be able to delete files on a samba share, mounted through cifs I came up with the following mount command in fstab:
//[ip-samba-server]/[share] /[local mountpoint] cifs rw,uid=[local user], gid=[local group],file_mode=0666,nobrl,noserverino,nounix,forceduid, forcedgid,noperm,noauto,username=[username on samba-server]
Pls. refer to the man-page mount.cifs for the meaning of these paramters.
I am not sure (yet) if all these parameters are really required, but for sure the parameter "noserverino" did the trick, because as soon as I have added this one, Geeqie behaved on the samba share in the same way as it does on a local file system, incl. deleting files.
Without this parameter I have noticed, that Geeqie always keeps on a samba share the last 4 files open which have either been activated in the Geeqie picture thumbnail browser or have actually been openend and closed in a new window.
This can easily be tracked by lsof -u [user] | grep *.jpg
And Geeqie always keeps ONLY the last 4 files open, so these last 4 files can also not be deleted by other applications.
With "noserverino", Geeqie does NOT keep any files open, anymore.
I believe this particular Geeqie behaviour occurs ONLY on certain samba server (smb.conf) configurations, as on QNAP-NAS's.
Because, I have setup another (rudimentarily) samba server manually on an other "machine" (Raspberry PI), and there Geeqie worked fine from the very beginning even without the above sophisticated mounting parameters.
There, Geeqie does not keep any files open.
Hope this hint helps anyone having the same problem !