File Manager: Unknown error (Error 500)

Community Support
41

Switch the users login permission to nologin, you can do this in edit user function.

42

it worked, thank you
@Raphael i think the user should not have permission to change these options but the admin?

43

probaly you’re logged in as admin, then you did a login as user - if you directly login as user, you cant change it.

1 Like
44

ohh ok didnt try that one yes thats fine than :stuck_out_tongue: many thanks

45

@blockademarc sorry for being a bit late here, but of course the AllowGroups directive is the blocker.

do you have a special reason to use it? all it does is limit ssh (and therefore sftp) access to members in that group. so, instead of adding more users or groups there you could also just add the users you want to allow to that sshusers group on the system. that’s how it is supposed to be done when using that directive (users can be in multiple groups, that’s how permissions work) so you would not need to alter your sshd config again :wink:

anyway, just wanted to clarify that because the file manager is using sftp there simply should be no custom/competing rules in your sshd_config that block the users from access :man_shrugging:t2: :smiley:

2 Likes
46

@falzo, thank you for your feedback.
I understand. Thank you for making clear that this was the source of the problem.
My special reason to use it is the security. I use 4 nonstandard settings in my sshd_config (AllowGroups, PermitRootLogin no, Port XXXXX, PasswordAuthentication no). All for security reasons. I only had 1 very special user in this group called sshusers who was allowed to login via ssh to the server. If I understand you correctly your suggestion is: if I think I do need this setting I should put the extra users into this special group (sshusers) instead of adding new groups to the config file, right ? Since I already have done it and any further user created in my beloved :heart:HestiaCP:heart: will belong to the group called hestia-users I guess I am already done with sshd_config.
Thank you once more for your great job and the time you took to explain it !

1 Like
47

We have a setting in the user settings page where you are able/disable SSH access or restrict the Ssh access. There fore there is no need for it setting.

Other setting are fine to use I use them by my self

48

I understand, I do use AllowUsers directive myself. that enforces me to even add every single user to that line in sshd_config whenever I want to have someone be able to access. regardless of the ssh settings in the panel - so even kind of worse than your group directive. but it’s intentional.

so, I did not want to say that you are doing wrong, you just need to be aware or at least keep it in mind :wink:
and true with the hestia-users group this you should be done with it as well, as usual multiple ways to handle it ^^

49

I continued to have issues with Debian 10 and I don’t have any AllowUsers directive. The clue came from @Lupu with allowing access to sftp. :+1:

tail /var/log/auth.log
subsystem request for sftp by user admin failed, subsystem not found

Amended /etc/ssh/sshd_config with the following (once I got the syntax correct):
# override default of no subsystems
# Subsystem sftp-server
Subsystem sftp /usr/lib/openssh/sftp-server

systemctl status sshd

Logout/login from admin and “I’m good to go”. :face_with_head_bandage:

1 Like
50

huh, that’s odd. sftp should already be enabled and the line in /etc/ssh/sshd_config should read

Subsystem sftp internal-sftp

could it be that the line was completely missing? the hestia installer puts it there already… (see lines 931+ from install-debian.sh)

if it’s not internal-sftp hestia will comment out the line you now put in there next time you reboot, as it checks the sftp config each time (though with a minute delay or so)

the whole sftp thing is by no means new with version 1.2 - it’s just the filemanager using it/depending on it now, the config itself has been there before already :wink:

1 Like
51

The benefit of a sleep and (more) coffee…
I had issues during the install/setup of Hestia, where it overwrote sshd_config, changing my pre-assigned port (amongst other settings) and blocking me out of the server. Grrr. I had to access the server via a rescue boot and change the sshd_config. That is likely where the Subsystem returned to the OS default.
Oh well, at least I now know how to ‘fix it’. :wink:

2 Likes
52

For me the solution was to switch to nologin an bash again (per user)
then login was possible

53

I use Hestia and Debian 10 and I got the “unknown error” and found the answer at https://docs.hestiacp.com/admin_docs/filemanager.html#file-manager-gives-unknown-error-message . In my case I solved it by changing #LoginGraceTime 1m to LoginGraceTime 1m in the /etc/ssh/sshd_config file

2 Likes
54

two thumbs up
:+1::+1:

55

For my case changing port to 22 solved the ‘Unknown Error’ issue.

56

I’m also facing same problem

57

Please check:
For my case changing port to 22 solved the ‘Unknown Error’ issue.

Also if you have disabled sftp access to the other users the error will happen. Please check those use cases first

58

I don’t have other users. Only admin user. And ftp port is 22 . But still can’t access

59

WordPress file permissions also got corrupted. Wp rocket is unable to edit htaacces. And site was giving error 500.

I deleted htaacces through rm comment in ssh.

Now site working but permissions are still corrupted

60

We strongly suggest using an “Standard” user for hosting website as it more secure! If hackers are able access to your and execute malicious code the the hackers are able to gain full access to the control pannel!

FTP is by default port 21 not 22.

WordPress file permissions also got corrupted. Wp rocket is unable to edit htaacces. And site was giving error 500.
I deleted htaacces through rm comment in ssh.

Sounds like unpacking the folder as root users. Make sure you set the correct permissions. It should be admin:admin

1 Like