• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue New FTP user becomes owner of all files of the webspace

Felix

New Pleskian
Server operating system version
AlmaLinux 8.7 (Stone Smilodon)
Plesk version and microupdate number
Plesk Obsidian v18.0.47_build1800221020.08 os_RedHat el8
Not sure if this is a bug or a feature, but it feels wrong.

I am in the progress to migrate to a new server that runs Plesk Obsidian 18.0.47.
I have a system user on a domain called user1.
All files of the domain and subdomain are owned by this user. This is good.
I now add a new FTP user (user2) that should only be able to access a certain folder on the domain. So I set its home directory to this folder.
When I save the user, ALL files of the complete domain are now owned by user2.
Furthermore, I am not more able to switch the permission back when setting the system user back to user1 (as it still seems to be user1).
When trying to change the system user to something different, say user3, I get an error message (that I dont remember now).
When I now reboot the server, I can set the system user to user3, and right afterwards back to user1 and all permissions are back to normal.
And user2 still has access to the folder for which it was created.

Hope the steps are clear to reproduce it.

It really feels like a bug, especially because a reboot is necessary to fix it. Let me know if there are any more information necessary or if I should file a bug report.

Best,
Felix
 
I don't think that's suppose to happen. However I am unable to reproduce the issue on my server. For me the domains system user remains to owner of all files and directories. Including the home directory set for additional FTP users. So this might be an issue specific to your server?

Best advice I can give is to open a support ticket with Plesk so they can investigate the issue directly on your server.
 
Last edited:
When trying to change the system user to something different, say user3, I get an error message (that I dont remember now).
When I now reboot the server, I can set the system user to user3, and right afterwards back to user1 and all permissions are back to normal.
The error message that you might have seen is related to updating a user account that is currently owning a process. While there are processes running on that account, it is not possible to change the account. When you reboot the server, the user for sure does not execute anything, that is why you can then do the update. To update a user account without the need to reboot, simply set the web space to "deactivated". This will halt all such processes. You can immediately proceed with user acount changes. Once you are done, switch the web space back to "active".

Regarding the additional FTP user and the account user: The (system) account user has FTP privileges, but it is much more than just some FTP user. An FTP user however has only FTP privileges. Adding an FTP user will not change the ownership of files other than the ones that descend from the FTP user's home directory. I think what you could check is whether the FTP home directory was set correctly. When you set it to "/" (your system user's root) and then do FTP transactions on that directory, sure new files or updated files will be owned by the FTP user. Like @Kaspar I cannot confirm a bug, but if you can reproduce the issue, it would be kind if you could please file a report here:
 
This might be just a cosmetic issue. When Plesk adds more users to a domain, they all have the same user and group id (so they each can access the same files without permission/owner problems). Such users still have separate entries for home directory, shell (/bin/false for ftp-only users) and password in /etc/passwd resp /etc/shadow.
 
Hei there.
Thanks @Peter Debik and @Kaspar for the super quick reply! Thanks as well to @mow for chipping in.
The error message that you might have seen is related to updating a user account that is currently owning a process. While there are processes running on that account, it is not possible to change the account. When you reboot the server, the user for sure does not execute anything, that is why you can then do the update. To update a user account without the need to reboot, simply set the web space to "deactivated". This will halt all such processes. You can immediately proceed with user acount changes. Once you are done, switch the web space back to "active".
Sounds pretty much right. I kinda remember that the error message was about process owning.
I cant test this now, as the server is under full load at the moment.

However, before opening this thread I was able to reproduce this behaviour (in total it happened twice).
I also checked the file permissions via ssh and they really had changed on all webspace files and folders (regarding @mow s comment).
I did not check the permissions of the other folders, like /etc/passwd or alike...

Not sure if this is important, but my setup is one parent domain and several subdomains. The new FTP users home is the home directory of one of the subdomains.

In the next week or so I will setup another server as a backup for this one and it will be configured exactly the same way.
If the same problem happens again, I will let you know and open a report.
Let me know if there is a specific test that you would like me to do, in case I can reproduce the problem.

Best,
Felix
 
I also checked the file permissions via ssh and they really had changed on all webspace files and folders (regarding @mow s comment).
Did you check the numeric ids (ls -lan) and cross-check with the user ids (id user1; id user2 ...)?
 
Did you check the numeric ids (ls -lan) and cross-check with the user ids (id user1; id user2 ...)?
No, I did not. Only did
Code:
ls -la
. I will try this the next time I encounter this problem.
But even if the ids would be the same, the only thing that is visible in the plesk panel is the user name, so it probably will cause confusion for every other user that encounters this bug/problem...
 
Hei there.
I have now started to setup the second server and the same happened again.
I took some prints, but I am not sure how much they would help...

And I checked the numeric ids, and @mow is right, they stay the same.

Best,
Felix
 
Hi Felix,

I have the exactly some issue .

I use Plesk from version 7 never seen such a thing.

I have many Plesk WebServer with CentOS, this bug is specific with AlmaLinux.

 
Hi Kaspar,

I can agree.

But for me is not suitable.
As workaround I have removed the three additional ftp user (and I will migrate service related to them to something other than ftp protocol)

I can't work in a shell where I chown mainuser:psacln and the system tell me that the owner is subuser:psacln .
Sooner or later I make some trouble.
I understand that it is not easy to fix on the system side otherwise the Plesk Team would have already done it.

Thanks for your support

Regards

Fabrizio
 
For what it's worth, I can't replicate this on Alma, but I'm running 9.1 already.

Product version: Plesk Obsidian 18.0.52.1
OS version: AlmaLinux 9.1 x86_64
Build date: 2023/04/28 12:00
Revision: e360fb7feaab0cb90c1223f9c8801f854f24ca35
 
But for me is not suitable.
As workaround I have removed the three additional ftp user (and I will migrate service related to them to something other than ftp protocol)

I can't work in a shell where I chown mainuser:psacln and the system tell me that the owner is subuser:psacln.
Sooner or later I make some trouble.
[...]
If you put it that way one could argue it's not a cosmetic issue but actually a bug after all. So I encourage to submit a detailed bug report about this issue here, so developers can at least investigate the issue and perhaps solve it. Who knows :)
 
Have you tried reordering the entries in /etc/passwd? It should use the first match for a uid ...
 
Hei there.
I just was bitten again by this problem.
And it actually is pretty serious, in my opinion.

We have the main application running via pm2. It runs under one of the ftp users (so it does not have root permissions).
We now have added a new ftp user and this KILLED the pm2 process, running under the other ftp user.

Manually restarting the process under the first user restarts the app but it is now listed under the second ftp users name in the process list.
This would not really be a problem, but is very confusing.

Nevertheless, we have now removed the second FTP user and the pm2 process was again killed.

Luckily, we have been connected via ssh at the time when this happened, but our app was offline for some time even though...

I really feel like this is a problem and should be addressed.

Best,
Felix
 
Have you tried reordering the entries in /etc/passwd? It should use the first match for a uid ...
Hi,

Not yet, but if you have read previous post, I believe this is not a solution .
If I try connect to the subscription for example from FileZilla with ftp protocol, it report the real correct permission.
This proves, that is not a problem of account ordering, in my opinion .

Thanks for the help.

Regards
 
Back
Top