Problems with working with business who thinks they are the Product Owners

I feel like the managers don't have the authority to address the issue or help with it. The SM has also tried with them, and I was informed that the collaboration with the previous PO also didn't work. What should be done?

What are the consequences of these problems for the organization? Is there a clear penalty, and is it being felt each Sprint?

Honestly, it sounds like you have stepped into a hornets nest only to find a few snakes lurking in the midst.  I am not sure I would want to be in your place.  

But, if I were, I think I would spend a lot of time in discussions with the Services team. Not through a formal meeting. Just casual conversations in any way I could.  This isn't as much an issue with Scrum as it is a distrust in the organizational order. Get to know them and let them get to know you.  Show interest in their work and needs. This will help them start to trust that you are concerned.  Start asking them questions about the items that they are creating so that you "can better understand what is going on".  This isn't a Scrum issue. It is a trust issue and unfortunately they don't have any for you or your team's ability to do what they need. Taking @Ian's approach, start making those things he mentions very visible and apparent to them. When they complain that the team did not deliver what they put into the Sprint, help them understand that it was because the other Services team mates put in competing things and there is only so much that can be done.  Help them to understand the process that your team uses to evaluate, order, complete work so that it is not a "black box" to them. 

Your Scrum Master should be able to help with some of this by helping the Services organization understand how the Scrum framework works.  And I don't mean by writing up emails or documentation that is posted somewhere on your internal network.  I mean by doing the same social networking that you need to do.  But that is assuming that your Scrum Master is actually fulfilling the roles outlined in the Scrum Guide and not following a job description written for a project manager. 

Remember that the Scrum Guide does not define any job descriptions or titles. It defines 3 distinct accountabilities that need to be fulfilled in order for the framework to be successful.  Any job title can fulfill those responsibilities but they need to be according to the Scrum Guide. 

In general best way is to treat this problem as a part of your overal product vision. Road map it.

1. Accept that situation is the way it is
2. Analyse what negative, and may be positive effects this situation brings
3. See the clear deviations from Scrum guide
4. Create the map of stakeholders and team members based on characters, attitude toward Scrum, attitude towards yourself and each other
5. Create a plan to communicate with both, team and stakeholders to address the negative side effects of current status quo, the real accountabilities of your role as product owner, their role
6. Choose best way to facilitate productive and positive interactions with all people involved based on the characters map: it can be informal meeting, one to one conversation, some joint event to build trust, workshop or conference involving stakeholders, directly addressing issue at retrospective, else
7. Unless this hurts your position in the company try to use both Sprint review and retrospective to address those issues. Ensure those meetings are scheduled every sprint disregard if there is good attendance or not

Be aware of who is your ally, who is an opponent and who are indifferent in all steps you take, and try to empathize with their behavior looking up the root cause. Be transparent(open) and try to ask that from others; then inspect and adapt your plan. Good luck