Big problem user permission changed to root!

I recently logged in via sftp to change some files I get “permission denied” so I log into my vps to see why and all my files are now root:root ??? What happened, why would it change?

Using winscp and debian10

How did you login? What exactly did you changed? There is no reason to set root:root as permission, if you dont have logged yourself in with root. This is a sftp feature, which hasnt a direct relation to hestia - we just provide the configured parts.

I only longed in via user, not admin or root. But even if I did login with root and change certain files it would only change those files, not everything.

How can I change this back?

Please provide step by step informations and what you’re doing. It sounds not like a hestia issue

I can only upload one image. How to do I put my user back in place of all these files?? It will take to long to go 1 by 1.

$: /home/dssn

drwxr-xr-x+ 11 root root 4096 Aug 4 21:54 .
drwxr-xr-x 5 root root 4096 Aug 5 05:54 …
-rw-r–r-- 1 root root 23 Aug 4 21:54 .bash_aliases
-rw-r–r-- 1 dssn dssn 220 Apr 18 2019 .bash_logout
-rw-r–r-- 1 dssn dssn 3526 Apr 18 2019 .bashrc
drwxr-xr-x 2 dssn dssn 4096 Aug 4 21:41 .cache
drwxr-xr-x 2 dssn dssn 4096 Aug 4 21:41 .composer
drwxr-xr-x 5 root root 4096 Aug 4 21:41 conf
drwxr-xr-x 2 dssn dssn 4096 Aug 4 21:41 .config
drwxr-xr-x 2 dssn dssn 4096 Aug 4 21:41 .local
drwxr-x–x 3 root root 4096 Aug 4 21:55 mail
-rw-r–r-- 1 dssn dssn 807 Apr 18 2019 .profile
drwxr-xr-x 2 dssn dssn 4096 Aug 13 06:16 .ssh
drwxrwx–x 2 dssn dssn 4096 Aug 14 19:54 tmp
drwxr-x–x 6 dssn dssn 4096 Aug 12 02:49 web

when I go to /home/dssn/web

drwxr-xr-x+ 11 root root 4096 Aug 4 21:54 …

dr-xr-x–x 9 dssn dssn 4096 Aug 12 05:54 domain.tld

Next in /home/dssn/web/domain

drwxr-x–x 9 dssn www-data 4096 Aug 6 08:20 public_html

/home/dssn/web/domain/public_html

root2

Everything is owned by root, it has to be hestia because I do not use root I do everything from the control panel, ports/firewall, only upload and download I use sftp.

how did you uploaded the files? how to use a easy chown user:user * -R inside the public_html directory to fix your issue?

1 Like

Can you post /etc/ssh/sshd_config? in case you are using sftp and not ftp
What shell is enabled for dssn user?
grep dssn /etc/passwd

chown user:user * -R inside the public_html directory to fix your issue?

Thank you!

dssn = hestiacp user name
ds = regular user on debian

[email protected]:~$ grep dssn /etc/passwd
root:x:0:0:root:/root:/bin/bash
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
systemd-timesync:x:101:102:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
dssn:x:1001:1001:email_gmail.com:/home/dssn:/sbin/nologin
    #Port 22
    #AddressFamily any
    #ListenAddress 0.0.0.0
    #ListenAddress ::

    #HostKey /etc/ssh/ssh_host_rsa_key
    #HostKey /etc/ssh/ssh_host_ecdsa_key


    # Ciphers and keying
    #RekeyLimit default none

    # Logging
    #SyslogFacility AUTH
    #LogLevel INFO

    # Authentication:

    #LoginGraceTime 1m
    PermitRootLogin yes
    #StrictModes yes
    #MaxAuthTries 6
    #MaxSessions 10

    #PubkeyAuthentication yes

    # Expect .ssh/authorized_keys2 to be disregarded by default in future.
    #AuthorizedKeysFile     .ssh/authorized_keys .ssh/authorized_keys2

    #AuthorizedPrincipalsFile none

    #AuthorizedKeysCommand none
    #AuthorizedKeysCommandUser nobody

    # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
    #HostbasedAuthentication no
    # Change to yes if you don't trust ~/.ssh/known_hosts for
     HostbasedAuthentication
    #IgnoreUserKnownHosts no
    # Don't read the user's ~/.rhosts and ~/.shosts files
    #IgnoreRhosts yes

    # To disable tunneled clear text passwords, change to no here!
    PasswordAuthentication yes
    #PermitEmptyPasswords no

    # Change to yes to enable challenge-response passwords (beware issues with
    # some PAM modules and threads)
    ChallengeResponseAuthentication no

    # Kerberos options
    #KerberosAuthentication no
    #KerberosOrLocalPasswd yes
    #KerberosTicketCleanup yes
    #KerberosGetAFSToken no

    # GSSAPI options

    #GSSAPIAuthentication no
    #GSSAPICleanupCredentials yes
    #GSSAPIStrictAcceptorCheck yes
    #GSSAPIKeyExchange no

    # Set this to 'yes' to enable PAM authentication, account processing,
    # and session processing. If this is enabled, PAM authentication will
    # be allowed through the ChallengeResponseAuthentication and
    # PasswordAuthentication.  Depending on your PAM configuration,
    # PAM authentication via ChallengeResponseAuthentication may bypass
    # the setting of "PermitRootLogin without-password".
    # If you just want the PAM account and session checks to run without
    # PAM authentication, then enable this but set PasswordAuthentication
    # and ChallengeResponseAuthentication to 'no'.
    UsePAM yes

    #AllowAgentForwarding yes
    #AllowTcpForwarding yes
    #GatewayPorts no
    X11Forwarding yes
    #X11DisplayOffset 10
    #X11UseLocalhost yes
    #PermitTTY yes
    PrintMotd no
    #PrintLastLog yes
    #TCPKeepAlive yes
    #PermitUserEnvironment no
    #Compression delayed
    #ClientAliveInterval 0
    #ClientAliveCountMax 3
    #UseDNS no
    #PidFile /var/run/sshd.pid
    #MaxStartups 10:30:100
    #PermitTunnel no
    #ChrootDirectory none
    #VersionAddendum none

    # no default banner path
    #Banner none
    # Allow client to pass locale environment variables
    AcceptEnv LANG LC_*

    # override default of no subsystems
    Subsystem sftp internal-sftp

    # Example of overriding settings on a per-user basis
    #Match User anoncvs
    #       X11Forwarding no
    #       AllowTcpForwarding no
    #       PermitTTY no
    #       ForceCommand cvs server

    DebianBanner no

    # Hestia SFTP Chroot
    Match User sftp_dummy99,admin,dssn
    ChrootDirectory %h
        X11Forwarding no
        AllowTCPForwarding no

Are the accounts chrooted?

Edit*

conf folder is still root, it won’t let me change it to dssn.

/home/dssn
drwxr-xr-x 5 root root 4096 Aug 4 21:41 conf

chown: changing ownership of ‘conf’: Operation not permitted

hestia users, yes. manualy created system users, no.

this is correct, a user should not change anything inside of conf, the permission belongs to root. Only touch the confs when you’re 100% sure about what you’re doing!