Bug 109451 - "unable to open file" on mounted smbfs shares. permissions correct.
Summary: "unable to open file" on mounted smbfs shares. permissions correct.
Alias: None
Product: taglib
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Scott Wheeler
: 98771 102281 117977 (view as bug list)
Depends on:
Reported: 2005-07-22 08:57 UTC by Richard Edmands
Modified: 2006-10-07 15:19 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:

amarok file (154.96 KB, application/zip)
2005-07-25 03:02 UTC, Richard Edmands
patch to retry failed r/w fopen r/o (518 bytes, patch)
2006-10-05 23:19 UTC, Martin Aumueller

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Edmands 2005-07-22 08:57:46 UTC
Version:           1.3.1 (using KDE KDE 3.4.1)
Installed from:    SuSE RPMs
Compiler:          WhatEver Suse 9.3 Pro Used. 
OS:                Linux

On SuSE 9.3 Pro. (Probley everything else 2)
Using either the offical amarok 1.2.2 build by suse or the amarok 1.3 beta 2 build by GURU. (Probley all other builds 2)

When adding music to the "collection" from a remote folder of music (via smb) which has been mounted by root "mount -t smbfs //computername/music /home/user/music".

Terminal spits out hundreds of
(tablib: could not open file /home/user/music/***.mp3)

user has read and execute access to the files.

no other applications have problems reading or executing files mounted like that. (including other media players playing those exact same mp3's)
Comment 1 Scott Wheeler 2005-07-22 09:03:30 UTC
Can you see if you're able to read the metadata for them in Konqueror?   (right click on the file -> properties -> meta data)   Which other media players are able to read the files?
Comment 2 Richard Edmands 2005-07-22 13:59:12 UTC
Scott Wheeler wrote:

[bugs.kde.org quoted mail]
konqueror: no meta data tab or button or whatever, depending on however 
konqueror was supposed to handle that
xmms: works, right clicking on files in the playlist and going view info 
brings up the ID3 tags happily.
xine: (from memory) happy to play, donno about the tags tho.
mplayer: happy to play, donno about the tags tho.
amaroK: happy to play, but won't add files to the "collection". During 
attempts, the terminal spits out taglib: can't open file 
Comment 3 Scott Wheeler 2005-07-22 22:00:19 UTC
And you are able to read these files if you copy them to another partition?
Comment 4 Thiago Macieira 2005-07-23 04:24:56 UTC
Which kernel version? There were bugs in the smbfs code in all but the most recent Linux kernels, so you may be hitting them.

It would be interesting to test a non-KDE taglib app.
Comment 5 Richard Edmands 2005-07-23 06:56:25 UTC
yeah, if i copy the files to locally, they are perfectly happy in every 
tested way.

uname -a spits out : Linux linux #1 Thu Jun 2 
14:23:14 UTC 2005 i686 i686 i386 GNU/Linux
is that recent enough?
Comment 6 Thiago Macieira 2005-07-23 17:57:51 UTC
I've talked with Scott last night and we don't think it's the old smbfs bug.

However, given that it doesn't work in smb mounts only, we're at loss. We don't believe it's a taglib bug, though.

Can you run this:
  strace -f -o /tmp/amarok amarokapp

then try to open one such file, then close amarok? Attach the produced file here, please (or mail it to one of us, if you don't want your information disclosed).
Comment 7 Richard Edmands 2005-07-25 03:02:12 UTC
Created attachment 11918 [details]
amarok file

looks like my last attempt to reply got interperated funny by something. well,
i'm doing this manually now, the file is compressed this time to save space.

"yeah, i had a read of the file /tmp/amarok when it gets to the part about the
mp3's, it says crap about permission denied, which seems illogical, cause, read
and execute permissions are fine... unless it's trying to write, which would be
completely inappropriate and concerning.

File is about 1.8MB
md5: 8ad6532617c5be333427e15d60c031e1"
Comment 8 Scott Wheeler 2005-07-25 03:18:18 UTC
Ok, this is a file system bug.  The interesting line is the one before "permission denied".  When TagLib opens a file it first checks to see if the file is writable.  If it is it opens it in read/write mode; if not it opens it in read only mode.  The problem is that your file system is reporting that it's writable, then TagLib tries to open it in read read/write mode and gets permission denied.  If the check to see if it is writable were correctly returning false, then it would open the file in read only mode.
Comment 9 Scott Wheeler 2005-09-22 17:09:10 UTC
*** Bug 102281 has been marked as a duplicate of this bug. ***
Comment 10 Jeff Mitchell 2005-09-22 19:43:28 UTC

Have you reported this to the samba folk?

Comment 11 Scott Wheeler 2005-09-22 22:33:32 UTC
No, I haven't.  Someone told me that it's fixed in the most recent version, but I haven't confirmed that.
Comment 12 Richard Edmands 2005-09-26 00:56:12 UTC
meh, i'll test it, which distro would have the version of samba i should 
be testing?
Comment 13 Jeff Mitchell 2005-09-26 01:23:11 UTC
Gentoo, circa March 23rd 2005?  :-)  I can test it too with Gentoo current.
Comment 14 Scott Wheeler 2005-10-08 13:58:48 UTC
Just for future reference:

Comment 15 Richard Edmands 2005-10-11 05:31:32 UTC
Scott Wheeler wrote:

[bugs.kde.org quoted mail]
yeah, i reported the bug, it was temporary fixed by adding -r to the 
command, someone said something about it being fixed in a new version of 
something, so i was going to test it. dam i hate short-term memory.
Comment 16 Scott Wheeler 2005-12-09 11:41:53 UTC
*** Bug 117977 has been marked as a duplicate of this bug. ***
Comment 17 Martin Aumueller 2006-10-05 23:19:43 UTC
Created attachment 18028 [details]
patch to retry failed r/w fopen r/o

The cifs file system implementation could probably do something about the issue
of read-only exported shares mounted read-write. But then, the check for
writability is ultimately done on the server, but access(2) does not involve
the server.

The same problem might happen with nfs mounts. The RESTRICTIONS section of my
Linux access(2) man page contains this:
access() may not work correctly on NFS file systems with UID mapping enabled,
because UID mapping is done on the  server  and  hidden from the client, which
checks permissions.

So I suggest to implement something like the work-around in the attached patch.
Comment 18 Mark Kretschmann 2006-10-07 15:18:54 UTC
*** Bug 98771 has been marked as a duplicate of this bug. ***
Comment 19 Mark Kretschmann 2006-10-07 15:19:47 UTC
*** Bug 135243 has been marked as a duplicate of this bug. ***