This is the most common complaint that I have gotten from folks using my node. There are two problems going on, but the main one is that the fee to send the transaction is higher than your max fee rate is set for CLN. I have the fee rate set unusually high on my node, and no doubt some custodial services also have additional fees they add on top. That means the total fess for the route are probably over what your node is configured to accept. Unfortunately the Core Lightning service on Start9 does not expose the config option in CLN to increase this, so if fees go past a certain amount, sends will consistently fail to find a suitable route. The other problem is with Core Lightning routing in general (discussed further here in this thread on the Start9 forum) The two problems compound each other, where you end up having to shut down your node, clear the gossip store, turn it back on, and wait several hours for it to re-populate. That doesn’t resolve the fee problem though.
The reason I have the fees set high, for anyone curious, is because of a problem that BTC Sessions ran into which cost him a lot of sats to recover from. He had the default fee rate on his node set to the default low settings, and he reduced his minimum channel size very low (like I did on mine) to encourage his viewers to start experimenting with lightning by connecting to his node. What ended up happening, though, is that scores of people opened small channels to his node (for mining), sent the sats to his side of the channel (like I showed in my video here) to create inbound liquidity to receive payouts. The net result of this was to sap all of BTC Session’s inbound liquidity from his main channels with the broader network, because all of the users were opening only one single channel, just to him, and sending the sats to his side. This meant that everybody routed all traffic through his main channels rather than participating themselves in the routing by having many other channels of their own. He could not re-balance either (since there were no routes through any of the small channels to circular re-balance) He ended up having to close all of the channels (which cost him more in base layer transaction fees then what he got from routing) and bump up his minimum channel capacity to prevent people from swarming his node again.
To avoid making the same mistake he did, I didn’t just set my minimum channel capacity very low (10K sats) but I also bumped up my routing fee to 1K stas per million (or 0.1%) with a minimum routing fee of 1 sat. This means if someone opens a 10K sat channel and sends all of the liquidity to my side, the fees I collect are 11 sats. If 100 people swarm my node, and each send out 10K sats, They will consume 1M sats of my inbound liquidity, but I will have collected 1.1K sats in fees (which is enough to do a base layer transaction to add more liquidity to my node). That way I don’t have to close anybody’s channels, and I can continue to collect transaction fees from them as they receive their mining payouts until they are ready to close their channels themselves.
But, unfortunately that led to the problem that you are now encountering. The issue doesn’t affect LND (since you can easily increase your acceptable fees), but Core Lighting is required for Ocean mining, since LND doesn’t yet support Lightning Offers. One way you can get around the problem (though it is a bit technical, unfortunately) is you can open both a Core Lightning node and a LND node on your server. From the LND node, open a channel with a good well-connected node (you can start with mine if you want to begin with a small channel – I recommend using my “PaulsCode LND” node, though, which is easier for me to re-balance, but you can use either). You’ll be able to send from it no problem (using Ride the Lighting, you can specify your max fee rate) to create inbound liquidity. Then open a channel from your LND node back to your Core Lightning node. That channel will be inbound liquidity on the Core Lightning side, so you will be able to start receiving payouts right away. When it eventually fills up on the Core Lightning side, you can just create an invoice from your LND node, and pay it from your Core Lightning node (for zero fees, since it is a direct connection), freeing your inbound liquidity back up.