Good afternoon,
I had a chance today to recreate the issue I was having last weekend. I copied all of the contents of my /sbbs/fido directory to /sbbs/u/fido,
which is on an nfs share. I then renamed /sbbs/fido to /sbbs/fido.old, and created a symlink to /sbbs/u/fido in the /sbbs directory as /sbbs/fido.
I have the same issue if I change the sbbsecho.ini to point to /sbbs/u/fido rather than attempt to use a symlink (the symlink is non-existant in that test case).
Here is what sbbsecho did when attempting to process inbound mail:
Scanning for Inbound Packets...
Scanning secure inbound: /sbbs/fido/inbound/
ERROR 11 (Resource temporarily unavailable) line 5619 opening /sbbs/fido/ inbound/0005B525.PKT
Those are all the errors that I receive.
It then goes on to scan for inbound netmail and then exits with a 0, even though it never was able to toss any of the PKT files listed above. If I remove the ~fido symlink and restore the /sbbs/fido directory, these PKT files are tossed as normal, no ERROR 11 messages and no exiting with 0
even though it failed.
I have the same issue if I change the sbbsecho.ini to point to /sbbs/u/fido rather than attempt to use a symlink.
Both systems are running Debian 9, and I am otherwise able to read and
write to the nfs share from the system running sbbs. The sbbsecho source says it is v 3.117 2019/06/29
Scanning for Inbound Packets...
Scanning secure inbound: /sbbs/fido/inbound/
ERROR 11 (Resource temporarily unavailable) line 5619 opening /sbbs/fido/ inbound/0005B525.PKT
It seems like the NFS share doesn't want to let you open the file.
You could experiment with the code (sbbsecho.c, nopen.c) if you like, but I don
t have any concrete suggestions.
It seems like the NFS share doesn't want to let you open the file.I figured that but was not sure why, since I am able to open them otherwise. Matter of fact, it is doing so as I type this message. :)
Keep in mind, that your SBBS processes may be running under a different user - >nd your NFS permissions may not allow that user to access the files on the shar
. I guess this is particularly true if SBBS is running as root... (which nfs wi
l change to "nobody" unless you have no_root_squash in your exports.
I thought about that, but the issue shows itself even when it is being run outside of sbbs, i.e. if I run sbbsecho from the command line I still get
the same errors.
---
SLMR 2.1a OPCODE: MWAG = Make Wild-Assed Guess
Synchronet CAPCITY2 * capcity2.synchro.net *
Telnet/SSH:2022/Rlogin/HTTP
I thought about that, but the issue shows itself even when it is being run outside of sbbs, i.e. if I run sbbsecho from the command line I still get
the same errors.
I thought about that, but the issue shows itself even when it is being run outside of sbbs, i.e. if I run sbbsecho from the command line I still get the same errors.
it still runs as a bbs user that is set in sbbs.ini
I thought about that, but the issue shows itself even when it is being run >outside of sbbs, i.e. if I run sbbsecho from the command line I still get
the same errors.
Right, and if you run it as root, and NFS is configure to drop root to "nobody
you'll get those errors.
What do you run it as? Does "id" of the user you run it as show a uid > 0?
Sysop: | BrokenMind |
---|---|
Location: | Central Pennsylvania United States |
Users: | 60 |
Nodes: | 4 (0 / 4) |
Uptime: | 58:27:44 |
Calls: | 177 |
Files: | 2,017 |
Messages: | 20,571 |