On Thu, Nov 4, 2021 at 9:35 PM deloptes <emanoil.kot...@deloptes.org> 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 caller did not match the owner of the file and the caller > > was not privileged. > > > > EPERM The operation was prevented by a file seal; see fcntl(2). > > > > I don't know whether this is truly a comprehensive list of causes. I'm > > wondering about things like FUSE-mounted file systems. What kind of > > file system is /home/user/Downloads/ part of? > > Thank you, > yes it is interesting indeed, because obexd is started as the user and > should operate on behalf of the user. > > /home/user/Downloads/ is on NFS share, but Downloads is writable only for > the user (700) > > these are the mount options > > type nfs4 > (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.40.68,local_lock=none,addr=192.168.40.40,_netdev) > > IMO there is something fishy in obexd, because as you see it is able to > create the file, but not write the content and I am not that enlightened in > this matter :/. > > > -- > FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0 >
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. -Burhan.
