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).
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.
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. :)
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: | Nelgin |
|---|---|
| Location: | Plano, TX |
| Users: | 513 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 00:10:24 |
| Calls: | 8,291 |
| Calls today: | 4 |
| Files: | 15,520 |
| Messages: | 928,847 |