Thomas Schmitt wrote:
> Can it be that obexd is allergic to symbolic links ?
>
>
https://discussion.fedoraproject.org/t/cannot-receive-file-over-bluetooth/1813/3
> points to
>
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/obexd/plugins/filesystem.c#n95
> which spews -EPERM if not obex_o
Greg Wooledge wrote:
> In the absence of a useful error message, you could either source-dive
> into obexd and try to figure out what it's actually doing... or you could
> *guess* (as I am currently guessing) that it's complaining about
> too-loose permissions, and then look at all the permissions
Hi,
deloptes wrote:
> lstat("/home", {st_mode=S_IFLNK|0777, st_size=10, ...}) = 0
> readlink("/home", "home-lisa/", 4095) = 10
Can it be that obexd is allergic to symbolic links ?
https://discussion.fedoraproject.org/t/cannot-receive-file-over-bluetooth/1813/3
points to
https://git.kerne
Greg Wooledge wrote:
> WHAT application? And how is THAT creature spawned?
Sorry for confusion. For testing I run it on the command line, but it is
meant to be spawned from one BT manager application. It is spawned as
process the same way I start it in the command line.
--
FCD6 3719 0FFB F1BF
On Fri, Nov 05, 2021 at 06:24:38PM +0100, deloptes wrote:
> I now used strace
> writev(2, [{iov_base="obexd[23074]: PUT(0x2), {iov_base="\n", iov_len=1}], 2) = 40
> sendto(3, "<31>Nov 5 18:04:33 obexd[23074]"..., 59, MSG_NOSIGNAL, NULL, 0)
> = 59
> openat(AT_FDCWD, "/home/user/Downloads/20211105_
David Wright wrote:
> Because both tests are run by hand, that does make it easier to strace
> what's going on in more detail than the debug output. For example, the
> open's flags are listed.
I forgot to mention that home is actually a link to home-lisa which is the
mount point for the NFS share
On Fri, Nov 05, 2021 at 06:00:43PM +0100, deloptes wrote:
> Greg Wooledge wrote:
>
> > So, never mind. Continue whatever other investigations you have lined
> > up.
>
> Ah yes, obexd is meant to be run at user level. In my case it is started by
> a master application, but anyway thank you for th
Greg Wooledge wrote:
> So, never mind. Continue whatever other investigations you have lined
> up.
Ah yes, obexd is meant to be run at user level. In my case it is started by
a master application, but anyway thank you for the effort.
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
On Fri 05 Nov 2021 at 11:55:19 (-0400), Greg Wooledge wrote:
> On Fri, Nov 05, 2021 at 10:59:46AM -0400, Greg Wooledge wrote:
> > On Fri, Nov 05, 2021 at 02:46:18PM +0100, deloptes wrote:
> > > Greg Wooledge wrote:
> > >
> > > > Check whether the systemd unit file is restricting network access for
On Fri, Nov 05, 2021 at 10:59:46AM -0400, Greg Wooledge wrote:
> On Fri, Nov 05, 2021 at 02:46:18PM +0100, deloptes wrote:
> > Greg Wooledge wrote:
> >
> > > Check whether the systemd unit file is restricting network access for
> > > the service/process.
> >
> > ??? How do I do this - a hint woul
On Fri, Nov 05, 2021 at 02:46:18PM +0100, deloptes wrote:
> Greg Wooledge wrote:
>
> > Check whether the systemd unit file is restricting network access for
> > the service/process.
>
> ??? How do I do this - a hint would be helpful.
Start by figuring out the name of the service.
Then try "syst
Greg Wooledge wrote:
> Check whether the systemd unit file is restricting network access for
> the service/process.
??? How do I do this - a hint would be helpful.
thanks in advance
--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0
On Fri, Nov 05, 2021 at 09:32:27AM +0100, deloptes wrote:
> Burhan Hanoglu wrote:
>
> > Could be something about that NFS mount. To narrow down; point it to
> > /home/user/something that is not on NFS but on the local FS instead
> > and see what happens.
>
> Hi,
> yes it looks like it is somehow
Burhan Hanoglu wrote:
> Could be something about that NFS mount. To narrow down; point it to
> /home/user/something that is not on NFS but on the local FS instead
> and see what happens.
Hi,
yes it looks like it is somehow related, because on a local FS even with
same directory permissions (700)
On Thu, Nov 4, 2021 at 9:35 PM deloptes wrote:
>
> Greg Wooledge wrote:
>
> > That's an interesting message for that operation.
> >
> > The open(2) man page shows only two possible sources for EPERM on an open:
> >
> > EPERM The O_NOATIME flag was specified, but the effective user ID of
> > the
Greg Wooledge wrote:
> That's an interesting message for that operation.
>
> The open(2) man page shows only two possible sources for EPERM on an open:
>
> EPERM The O_NOATIME flag was specified, but the effective user ID of
> the caller did not match the owner of the file and the caller
>
On Thu, Nov 04, 2021 at 05:44:31PM +0100, deloptes wrote:
> obexd[4068]: open(/home/user/Downloads/20020011.jpg): Operation not
> permitted (1)
That's an interesting message for that operation.
The open(2) man page shows only two possible sources for EPERM on an open:
EPERM The O_NOATIM
This is how I am starting the daemon
/usr/lib/bluetooth/obexd -d -n -r /home/user/Downloads -a
and this is what I get when trying to transfer a file
obexd[4068]: obexd/src/obex.c:obex_session_start()
obexd[4068]: obexd/src/obex.c:cmd_connect()
obexd[4068]: CONNECT(0x0), (0xff)
obexd[4068]: obe
18 matches
Mail list logo