= Сообщение: 2977 из 7127 ====================================== FTSC_PUBLIC = От : Bill McGarrity 1:266/404 22 Feb 17 14:39:00 Кому : Accession 22 Feb 17 14:39:00 Тема : Error 13 when packing a bundle. FGHI : area://FTSC_PUBLIC?msgid=6530.2ftscpubl@1:266/404+1d134e13 На : area://FTSC_PUBLIC?msgid=723:1/1+58acecb5 = Кодировка сообщения определена как: ASCII ================================== ============================================================================== -=> Accession wrote to Bill McGarrity on 02-21-17 19:30 <=-
Ac> On Tue Feb 21 2017 19:45:36, Bill McGarrity wrote to Accession:
Ac>> Then check the permissions on 00960001.hlo specifically. You may Ac>> need to use chown to change the permissions of that file so that Ac>> it will continue. And with
BM> I ahve, and it's read only. The problem is when the node licks the BM> mail up it's gone till the next time it's created.
Ac> So then the problem seems to be when the file is created. Is something Ac> 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.
Ac>> that said, you mentioned it seems to happen on locally imported Ac>> messages with smbutil. Make sure all of your scripts that use Ac>> smbutil are executed by the user you want these file permissions Ac>> to be, or things will start going haywire.
BM> OK... I'm running the bash script we discussed a week or so under BM> crontab. I would agree with your assesment as rar as root but why does BM> it work for some zipped bundles and not others? In the script I use BM> chmod 777 to the .txt files created by perl so they have ALL access.
Ac> A crontab created by the specific user, and not root.. correct? Meaning Ac> you did
Ac> "crontab -e" as the user you wish to run as (with no sudo).
Yes, no sudo. it's under Pi
Ac> Also, chmod only makes the file readable/writable/executable. It does Ac> not set ownership. "chown" sets the user and group. You shouldn't Ac> really need to chmod anything as sbbsecho creates the proper read/write Ac> capabilities. However, you may need to "chown -R <user>.<group> Ac> <directory>/*" if something is changing ownership.
OK.. let me check that tonight to see if there are any further issues.
Ac>> Looks like at some point something accessed 00960001.hlo and Ac>> changed the permission. Did you accidentally run smbutil with Ac>> root at one point when testing to see if it would work from the Ac>> command line before setting a script in motion?
Can't remember... :(
BM> Again, if that was the case smbutil being run as root, why would it BM> not effect the other bundles being made to other nodes?
Ac> I'm not sure, unless something else is touching that specific file Ac> aside from sbbsecho.
As I said, let's see what tonight brings then I'll try the chown command.
BM> I'll do the ls -alh later and see what's going on.
Ac> If you do choose to continue to use chmod (aside from chown), you may Ac> want to consider using either 666 (-rw-rw-rw-) = readable and writable Ac> to all, 664 (-rw-rw-r--) = readable and writable for file owner and Ac> group, and readable to everyone else, or even 660 (-rw-rw----) if you Ac> want it for that specific user and group only. Your outbound Ac> directory's contents do not need to be executable
Ac> (which the 7 adds).
I'll fine tune it once I get this issue resolved. First play on the BIG field then downsize.. LOL!!
