Linux moving /Var to Nas device

Operating Systems & Open Source Linux
1

Hi. I have a question if it is possible to move a /var directory off system to a nas device and have it connect back over cifs?

2

It might make more sense to use NFS but yes it can be done. You may run in to issues if the NAS goes offline or you get a stale handle or something like that.

3

thanks for the info, in your fstab do you have to use a uuid or am I good with the ip?

4

UUID identifies local partitions.

You need to use a stable network identifier. A static (or reserved) IP works, the NAS name should work, too.

5

There’s a variety of stuff that goes in /var. In particular, /var/log; how do you diagnose problems, if the logs can’t be seen?

I suggest you identify what’s taking up space in there, and either move it out of /var (for example, some databases put their data in /var/lib by default and can be set up to put it somewhere else), or put just that part of /var on the NAS. Also, watch out for docker; on my work system /var/lib/docker shows as 29 GB, but docker is using btrfs a lot and there’s not really 29 GB in there.

2 Likes
6

Thanks for the information.

Ive set the cifs share in fstab all is working well.
//IP/Lan/Folder /mnt/FOLDER cifs …

Ive copied /var over to the nas i got a few errors but carried on.
sudo cp -R /var/ /mnt/FOLDER/var

i setup the /var change in fstab
/mnt/FOLDER /var none bind 0 0

now the file structure looks a bit funny I have /var with in /var is this because I used the “bind” option and i had those few errors when copying?

7

Contents in /var are vital to a running Linux system and contains files that will be changed while the process of copying the folder contents is running.

The “safe” way to migrate /var is to shut down computer, boot a live image, then copy var and modify fstab from there.

With this in mind, it’s important to assess if hosting /var remotely is a great idea. In most (almost all) cases it’s not.

2 Likes
8

This is a bad idea.

The files created and held open under /var before the bind mount is applied can remain open, getting written to, filling up your local partition with logrotate unable to clean them up.

In the pre-systemd days, rsyslogd hanging because of an inability to write out its logs would cause the whole system to hang. Not sure if that’s the case now.

You’ll find lots of advice NOT to mess with the top-level /var folder:

If /usr or /var is partitioned separately from the rest of the root volume, the boot process becomes much more complex because these directories contain boot-critical components. In some situations, such as when these directories are placed on an iSCSI drive or an FCoE location, the system may either be unable to boot, or it may hang with a Device is busy error when powering off or rebooting.

This limitation only applies to /usr or /var, not to directories under them. For example, a separate partition for /var/www works without issues.