Bug 822349 - geeqie refuses to remove files on samba mounts
geeqie refuses to remove files on samba mounts
Product: Fedora
Classification: Fedora
Component: geeqie (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Michael Schwendt
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-05-17 02:39 EDT by Pontus Enhager
Modified: 2013-09-02 16:24 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-02-13 14:13:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace of starting - changig directory and trying to delete a file (that fails) (2.55 MB, text/plain)
2012-05-18 01:10 EDT, Pontus Enhager
no flags Details
strace of last excercise (6.56 MB, text/plain)
2012-05-19 13:10 EDT, Pontus Enhager
no flags Details

  None (edit)
Description Pontus Enhager 2012-05-17 02:39:48 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):

How reproducible:

Steps to Reproduce:
1. try to delete a file on a samba mount
Actual results:
deletion inhibited

Expected results:
file no more

Additional info:
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
Comment 1 Michael Schwendt 2012-05-17 05:03:31 EDT
> 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?
Comment 2 Pontus Enhager 2012-05-17 11:45:26 EDT
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=,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
Comment 3 Michael Schwendt 2012-05-17 12:27:04 EDT
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.
Comment 4 Pontus Enhager 2012-05-18 01:10:27 EDT
Created attachment 585336 [details]
strace of starting - changig directory and trying to delete a file (that fails)
Comment 5 Michael Schwendt 2012-05-18 03:03:27 EDT
| 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.
Comment 6 Pontus Enhager 2012-05-18 12:52:50 EDT
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
[pontus@palsternacka ~]$ 

and the file is removed

(i do not know if this helps, but anyway)

Doing the same in Nautilus works fine
Comment 7 Michael Schwendt 2012-05-18 13:54:45 EDT
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.
Comment 8 Pontus Enhager 2012-05-19 13:07:15 EDT
[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
[pontus@palsternacka test2]$
Comment 9 Pontus Enhager 2012-05-19 13:10:50 EDT
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
Comment 10 Michael Schwendt 2012-05-19 15:09:11 EDT
> geeqie     1890        pontus    9r      REG       0,38   
> 4889078 8809155002397
> /mnt/photo/1.RAW/2012/test2/notlookingatthisfile.JPG

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.
Comment 11 Pontus Enhager 2012-05-19 15:31:53 EDT
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.
Comment 12 Pontus Enhager 2012-05-20 02:52:33 EDT
(In reply to comment #11)
> geeqie problem, but you OTOH - dos not see this on "similar" mounts.

s/dos/you do/
Comment 13 Michael Schwendt 2012-05-20 03:31:51 EDT
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.
Comment 14 Fedora End Of Life 2013-01-16 10:58:10 EST
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: 
Comment 15 Fedora End Of Life 2013-02-13 14:13:19 EST
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.
Comment 16 Paddington 2013-09-02 16:24:21 EDT
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 !

Note You need to log in before you can comment on or make changes to this bug.