File (/home/pi/binkd-1.1/sportnet/outbound/ffa0fffb.TU1, 1.4KB) for 24:120/6 added to BSO/FLO file: /home/pi/binkd-1.1/sportnet/outbound/00780006.hlo
Deleting /home/pi/binkd-1.1/sportnet/outbound/58abc9fa.pkt (from line 2012)
***** End
Example of the Error 13..
***** Start
ERROR 13 (Permission denied) opening /home/pi/binkd-1.1/sportnet/outbound/00960001.hlo
Take a look at your /home/pi/binkd-1.1/sportnet/outbound directory
with:
ls -alh
Then check the permissions on 00960001.hlo specifically. You may need
to use chown to change the permissions of that file so that it will continue. And with
that said, you mentioned it seems to happen on locally imported
messages with smbutil. Make sure all of your scripts that use
smbutil are executed by the user you want these file permissions to
be, or things will start going haywire.
Looks like at some point something accessed 00960001.hlo and changed
the permission. Did you accidentally run smbutil with root at one
point when testing to see if it would work from the command line
before setting a script in motion?
Hiya DM...
Using: SBBSecho 3.00-Linux r3.28 Feb 8 2017 GCC 4.9.2 invoked with options: -linf
The past two days I have been getting Error 13 in a few bundles sbbsecho is trying to create. I am contributing these to possible permission level for each BSO bundle. Problem is, it doesn't happen all the time... only with an imported file using smbutil. Sometimes the bundle gets zip'd correctly, other times I get the Error 13 as shown below.
Example of a good packing...
***** Start
Outbound Packet: /home/pi/sbbs/temp/sbbsecho/58abc9fa.pkt Finalizing outbound packet from 24:24/1 to 24:120/6: /home/pi/sbbs/temp/sbbsecho/58abc9fa.pkt
Node (24:120/6) successfully locked via: /home/pi/binkd-1.1/sportnet/outbound/00780006.bsy
Sending packet (/home/pi/sbbs/temp/sbbsecho/58abc9fa.pkt, 4.6KB) from 24:24/1 to 24:120/6
Moving packet for 24:120/6: /home/pi/sbbs/temp/sbbsecho/58abc9fa.pkt to /home/pi/binkd-1.1/sportnet/outbound/58abc9fa.pkt
Packing packet (/home/pi/binkd-1.1/sportnet/outbound/58abc9fa.pkt) into bundle (/home/pi/binkd-1.1/sportnet/outbound/ffa0fffb.TU1) for 24:120/6 using ZIP
Executing: zip -jD /home/pi/binkd-1.1/sportnet/outbound/ffa0fffb.TU1 /home/pi/binkd-1.1/sportnet/outbound/58abc9fa.pkt
File (/home/pi/binkd-1.1/sportnet/outbound/ffa0fffb.TU1, 1.4KB) for 24:120/6 added to BSO/FLO file: /home/pi/binkd-1.1/sportnet/outbound/00780006.hlo
Deleting /home/pi/binkd-1.1/sportnet/outbound/58abc9fa.pkt (from line 2012)
***** End
Example of the Error 13..
***** Start
Outbound Packet: /home/pi/sbbs/temp/sbbsecho/58abc9f8.pkt Finalizing outbound packet from 24:24/1 to 24:150/1: /home/pi/sbbs/temp/sbbsecho/58abc9f8.pkt
Node (24:150/1) successfully locked via: /home/pi/binkd-1.1/sportnet/outbound/00960001.bsy
Sending packet (/home/pi/sbbs/temp/sbbsecho/58abc9f8.pkt, 4.6KB) from 24:24/1 to 24:150/1
Moving packet for 24:150/1: /home/pi/sbbs/temp/sbbsecho/58abc9f8.pkt to /home/pi/binkd-1.1/sportnet/outbound/58abc9f8.pkt
Packing packet (/home/pi/binkd-1.1/sportnet/outbound/58abc9f8.pkt) into bundle (/home/pi/binkd-1.1/sportnet/outbound/ff820000.TU1) for 24:150/1 using ZIP
Executing: zip -jD /home/pi/binkd-1.1/sportnet/outbound/ff820000.TU1 /home/pi/binkd-1.1/sportnet/outbound/58abc9f8.pkt
ERROR 13 (Permission denied) opening /home/pi/binkd-1.1/sportnet/outbound/00960001.hlo
***** End
Psoosible resolution??
Then check the permissions on 00960001.hlo specifically. You may
need to use chown to change the permissions of that file so that
it will continue. And with
I ahve, and it's read only. The problem is when the node licks the
mail up it's gone till the next time it's created.
that said, you mentioned it seems to happen on locally imported
messages with smbutil. Make sure all of your scripts that use
smbutil are executed by the user you want these file permissions
to be, or things will start going haywire.
OK... I'm running the bash script we discussed a week or so under
crontab. I would agree with your assesment as rar as root but why does
it work for some zipped bundles and not others? In the script I use
chmod 777 to the .txt files created by perl so they have ALL access.
Looks like at some point something accessed 00960001.hlo and
changed the permission. Did you accidentally run smbutil with
root at one point when testing to see if it would work from the
command line before setting a script in motion?
Again, if that was the case smbutil being run as root, why would it
not effect the other bundles being made to other nodes?
I'll do the ls -alh later and see what's going on.
Digital Man wrote to Bill McGarrity on 02-21-17 18:03 <=-
Re: Error 13 when packing a bundle.
By: Bill McGarrity to Digital Man on Tue Feb 21 2017 12:44 am
***** End
Psoosible resolution??
What user created the 00960001.hlo file? What are the permissions on
the file? Can you paste the output from "ls -l /home/pi/binkd-1.1/sportnet/outbound" here?
Accession wrote to Bill McGarrity on 02-21-17 19:30 <=-
On Tue Feb 21 2017 19:45:36, Bill McGarrity wrote to Accession:
Then check the permissions on 00960001.hlo specifically. You may
need to use chown to change the permissions of that file so that
it will continue. And with
I ahve, and it's read only. The problem is when the node licks the
mail up it's gone till the next time it's created.
So then the problem seems to be when the file is created. Is something else touching that file besides sbbsecho?
that said, you mentioned it seems to happen on locally imported
messages with smbutil. Make sure all of your scripts that use
smbutil are executed by the user you want these file permissions
to be, or things will start going haywire.
OK... I'm running the bash script we discussed a week or so under
crontab. I would agree with your assesment as rar as root but why does
it work for some zipped bundles and not others? In the script I use
chmod 777 to the .txt files created by perl so they have ALL access.
A crontab created by the specific user, and not root.. correct? Meaning you did
"crontab -e" as the user you wish to run as (with no sudo).
Also, chmod only makes the file readable/writable/executable. It does
not set ownership. "chown" sets the user and group. You shouldn't
really need to chmod anything as sbbsecho creates the proper read/write capabilities. However, you may need to "chown -R <user>.<group> <directory>/*" if something is changing ownership.
Looks like at some point something accessed 00960001.hlo and
changed the permission. Did you accidentally run smbutil with
root at one point when testing to see if it would work from the
command line before setting a script in motion?
Again, if that was the case smbutil being run as root, why would it
not effect the other bundles being made to other nodes?
I'm not sure, unless something else is touching that specific file
aside from sbbsecho.
I'll do the ls -alh later and see what's going on.
If you do choose to continue to use chmod (aside from chown), you may
want to consider using either 666 (-rw-rw-rw-) = readable and writable
to all, 664 (-rw-rw-r--) = readable and writable for file owner and
group, and readable to everyone else, or even 660 (-rw-rw----) if you
want it for that specific user and group only. Your outbound
directory's contents do not need to be executable
(which the 7 adds).
It varied. I'm going through doing chmod's on the ones that seem to
be giving me problems. Two nights ago it was 5 .hlo files, last n
ight it was two that I tracked down and manually did a chmod on them.
I'll hopefully see tonight if there are more.
Nick was kind enough to give teh same advice as you. I'll get it
worked out and thanks so much for the reply.
So then the problem seems to be when the file is created. Is
something else touching that file besides sbbsecho?
Yes, but last night instead of the 5 or 6 errors I was getting, there
was only two so I isolated those and did a chmod as well.
A crontab created by the specific user, and not root.. correct?
Meaning you did
"crontab -e" as the user you wish to run as (with no sudo).
Yes, no sudo. it's under Pi
OK.. let me check that tonight to see if there are any further issues.
I'll fine tune it once I get this issue resolved. First play on the
BIG field then downsize.. LOL!!
Appreciate your help...
Accession wrote to Bill McGarrity on 02-22-17 16:53 <=-
On Wed Feb 22 2017 14:39:00, Bill McGarrity wrote to Accession:
So then the problem seems to be when the file is created. Is
something else touching that file besides sbbsecho?
Yes, but last night instead of the 5 or 6 errors I was getting, there
was only two so I isolated those and did a chmod as well.
chmod most likely isn't needed at all, since sbbsecho creates those
files with workable permissions. It's most likely something being ran (whether it be sbbsecho or smbutil) was accidentally used by root at
one point, or binkd was accidentally ran as root once or something..
but chown should probably fix this
at some point.
Unfortunately you'll probably have to go through and make sure your
entire sbbs
directory is owned by the "pi" user and whatever group it belongs to
for things
to work properly. Rather than looking everywhere with "ls -alh" you can simply run "chown -R <user>.<group> /home/<user>/sbbs/*" without
quotes. If binkd is not under your sbbs heirarchy, you probably want to
do the same for that directory as well.
A crontab created by the specific user, and not root.. correct?
Meaning you did
"crontab -e" as the user you wish to run as (with no sudo).
Yes, no sudo. it's under Pi
I take it "Pi" is your user? Is that what you login with? Or is it "alarmpi" or
"pi" or .. I'm not sure what your actual user is.
OK.. let me check that tonight to see if there are any further issues.
Ok.
I'll fine tune it once I get this issue resolved. First play on the
BIG field then downsize.. LOL!!
Permissions and ownership have always been a pain in the ass. I
eventually just
ran everything as root, since it's only a Rpi, and it only contains BBS related
stuff. If some retard really wants to try to guess my (quite) long root password, they can have at it. :)
Appreciate your help...
No problemo. Besides the current development of software I use here,
this is one of the very few things keeping interest in the hobby these days. :)
I am running Synchronet on Ubuntu and have had trouble with file ownership. I usually have to chown -R ftn:ftn /sbbs at various times.
when I installed the software, sbbsecho ran as ftn and sbbs ran as
root. Once I changed sbbs to run as ftn user, everything worked.
to work properly. Rather than looking everywhere with "ls -alh" you
can simply run "chown -R <user>.<group> /home/<user>/sbbs/*" without quotes. If binkd is not under your sbbs heirarchy, you probably want
to do the same for that directory as well.
I am running Synchronet on Ubuntu and have had trouble with file ownership. I usually have to chown -R ftn:ftn /sbbs at various times. when I installed the software, sbbsecho ran as ftn and sbbs ran as
root. Once I changed sbbs to run as ftn user, everything worked.
to work properly. Rather than looking everywhere with "ls -alh"
you can simply run "chown -R <user>.<group> /home/<user>/sbbs/*"
without quotes. If binkd is not under your sbbs heirarchy, you
probably want to do the same for that directory as well.
Just an FYI....
The changes I made to the bash scripts adding the chown did the trick. Everything zipped properly in the bundles...
Thanks so much!!
The changes I made to the bash scripts adding the chown did the trick. Everything zipped properly in the bundles...
Thanks so much!!
Right on, brutha! Glad to hear it's working. :)
Right on, brutha! Glad to hear it's working. :)
Yeah... thanks to your and DM my little 'linux" knowledge box is
getting full... it's actually fun now... lol!!
And soon it will all be second nature. It takes a little getting used
to, but once you do it becomes just as easy as Windows. Especially
when you dive in and
use the CLI, as you're forced to figure things out and learn the
proper command
line useage, unlike installing a full GUI desktop where most of the
hard stuff is taken care of for you.
| Sysop: | Winzlo |
|---|---|
| Location: | Minnesota, USA |
| Users: | 11 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 495934:34:05 |
| Calls: | 82 |
| Files: | 1,070 |
| D/L today: |
27 files (11,920K bytes) |
| Messages: | 286,923 |