Incremental Backups fail after upgrade to 4.132

I upgraded Virtualmin from 4.12 to 4.132, since then the incremental backups do not work anymore. They fail straight after the first server backup with the following error:

Creating backup for virtual server [HOSTNAME] .. Copying virtual server configuration .. .. done

Backing up Cron jobs ..
.. none defined.

Saving mail aliases ..
.. done

Saving mail and FTP users ..
.. done

Backing up all mail files ..
.. none to backup

Backing up mail and FTP user Cron jobs ..
.. none to backup

Copying Apache virtual host configuration ..
.. done

Copying Apache log files ..
.. done

Copying Logrotate configuration ..
.. done

Dumping MySQL database handsandfeet ..
.. done

Backing up Webmin ACL files ..
.. done

Backing up AWstats configuration file ..
.. done

Creating incremental TAR file of home directory ..

Failed to open /home/[host]/.incremental : Permission denied at /usr/share/webmin/web-lib-funcs.pl line 1397, line 1.

/home/[host] is owned by root, but everything inside is owned by the virtual server's user.

The full backup that runs once a week, works just fine.

Because the last incremental backup before the update worked fine, I suspect the new backup handling does not have enough privileges to handle this.

Thanks!

Kees-Jan

Status: 
Active

Comments

Is /home/[host] the root directory for all your Virtualmin domains, or just the home directory for the domain being backed up?

Hi!

Sorry for responding so late, I somehow didn't receive an update email.

/home is the root directory for my Virtualmin domains, /home/[host] is the home directory for the domain being backed up.

Thanks.

Kees-Jan

Ok, so why is /home/[host] owned by root? Shouldn't it be owned by the domain whose home directory that is?

All my domain home directories are owned by root so SFTP can be used with chroot to prevent domain owners to browse outside of their home directories.

That's going to cause a lot of problems for Virtualmin. Why is root ownership needed for chrooting?

As far as I understand it that is needed for OpenSSH to restrict users to their own home directories. The downside of this configuration is of course that these users are not able to write directly in their own home directories, only in the folders underneath. That is causing the backups to fail because the user cannot write the .incremental file directly in the home directory.

For me it was absolutely fine that root ran the backup process, instead of the Virtualmin server owners, would it be possible to make it an option, backup as root or backup as server owner? I would also be happy to change the home directory ownership if there is another way to restrict Virtualmin server users to their home directories without being able to see files outside of their home directories.

Thanks!

What if you made the .incremental file a symlink to a subdirectory that the user was able to write to?

Also, I'd recommend checking if OpenSSH really needs root ownership of the home dir.

I tried your suggestion to create a symlink to the .incremental file in a subdirectory. Unfortunately the symlink gets deleted during the backup process, so the next time the same error occurs. I am not sure how it was able to delete the symlink though.

I tried different things, but I wasn't able to find a working solution without root owning the directory to chroot.

Can you tell us more about what error you get from SSH when trying to chroot without the home directory being owned by root?

In the SFTP client I just get:

Error: Network error: Software caused connection abort Error: Could not connect to server

Authlog.log gives:

Jan 30 12:06:07 HOST sshd[17259]: Accepted password for [user] from 81.128.146.130 port 19936 ssh2 Jan 30 12:06:07 HOST sshd[17259]: pam_unix(sshd:session): session opened for user [user] by (uid=0) Jan 30 12:06:07 HOST sshd[17295]: fatal: bad ownership or modes for chroot directory "/home/[user]" Jan 30 12:06:07 HOST sshd[17259]: pam_unix(sshd:session): session closed for user [user]

When root owns /home/[user] everything works as it should.

What if you used /home as the root directory instead? SFTP users will still be unable to access other users' directories due to the permissions..

Yes, that is the problem. I cannot have users see each other's files.

In a standard Virtualmin install, user's can access each other's directories under /home though.

Okay, I see. That is probably why I changed it to have it suit my needs. :-)

I can live with that, if it only breaks the incremental backups. Do you think other thinks break (or are broken already) with my setup and Virtualmin doing more as the virtual server's owner?

Thanks.

I'm having the same problem. I'm using SFTP and Chrooting the users to their home directory.

For Chroot to work, each folder leading up to the users home directory needs to be root as the user owner, the users group for group owner, and with 750 chmod.

I have been using this on Centos 6.4-6.6 for a few years without any problems on my backups. after moving to a Centos 7 server, the latest version of Virtualmin/Webmin and now i'm having that problem too.

This method of using chroot so as to isolate regular users who come into the server via Web, FTP, etc, and thereby prevent these users from browsing the entire server filesystem at will, as well as keep them out of one other's home directories, is a hot topic in the hosting world at the present time.

If Cloudmin/Virtualmin/Webmin could seamlessly provide chroot, in all the right places (web, ftp, ssh), to an equal level of isolation and features in this area as CloudLinux currently does, it would be absolutely awesome for the security of the information held on the servers, the server owners, as well as for everyday users of Virtualmin family of server control panels!

So after another update it seems now the Full Backups have been failing with "Failed to open /home/abc/.virtualmin-src for writing : Permission denied"

I've modified my backup settings to do this before the backups "chmod 770 /home/*"

and then after the backup completes "chmod 750 /home/*"

This seems to have taken care of the issues for now.