Can’t Delete Or Move /home On 7.3 Install

Home » CentOS » Can’t Delete Or Move /home On 7.3 Install
CentOS 19 Comments

Tried this in both AWS and GCE as I though it may be a specific cloud vendor issue. SELinux is disabled, lsof | grep home shows nothing, lsattr /home shows nothing. Simply get “Device or resource busy.”

Works just find on 7.2 so I’m kinda at a loss. Scanned over the RHEL
release notes and didn’t see anything. Anyone else have this issue? We move our /home to another mount point and symlink /home to it ..

19 thoughts on - Can’t Delete Or Move /home On 7.3 Install

  • }}

    that is one possibility.

    even greater is op is a ‘user’, not ‘root’.

    _normally_ / most, if not all unix/linux systems, /home is owned by
    ‘root’. which means *everything*, including a ‘user’ home directory is own by ‘root’. therefore a ‘user’ running a normal user can do
    _nothing_ to his/her ‘home’ directory.

    therefore a normal user *must* ‘sudo’ or ‘su’ to make changes to users ‘home’ directory.

    hth.

  • Another possibility is /home is a separate file system. In that case the OP does not want to “move it” but unmount it, change the mount point in /etc/fstab, rmdir /home, and ln -s new_mntpoint to /home. Then mount it again. Probably best done is single user mode.

    jl

  • Jon LaBadie wrote:

    Here’s a question to OP: how did you log into the system? If as *user*, rather than as root, the filesystem is busy because you’re logged on, and in it.

    Missed some of the posts overnight – has anyone asked for the o/p of df -h?

    mark

  • I was most def root. /home isn’t mounted as a separate filesystem. It’s not even tmpfs or btrfs. I was able to boot into single user mode to remove it, but this isn’t possible in an automated fashion. I may just have to start building my own images.

    Still curious to know why I can’t rename or move it. Anyone else try this on a stock 7.3 build?

  • Hello Glen,

    There’s a difference whether you logged in as root or su-ed to root. In the latter case /home is still in use by the user you su-ed from.

    Even though it is not strictly necessary to init 1 you must make sure not a single user that uses /home for their home directory is logged in and no system user accesses files there (f.e. apache configured with home dirs) when attempting to move /home.

    Regards, Leonard.

  • Doing a lsof showed no open files against /home. Something else is locking it, not a user process. Also disabled SELinux, did a init 1, and only way to remove it was via single user by passing init=/sysinit/bin/sh

  • It sounds like /home is being managed by something in the kernel, then.

    Are you exporting /home via NFS or SMB? AutoFS? I’m trying to think what would start at runlevel 1, although if this is c7 that might not be a valid description anymore, perhaps services are being started at
    ‘rescue.target’.

  • This is a base install. If you deploy an instance in ec2 or GCE (ec2
    you can do the free tier) it’s easily repeatable. Even on a RHEL 7.3
    instance. Note you’ll need to allow root and password logins via SSH
    before attempting.

  • I can confirm this.

    The culprit? NetworkManager has /home open. I can’t figure out
    *WHY*.

    # systemctl start NetworkManager.service
    # rmdir /home rmdir: failed to remove ‘/home’: Device or resource busy
    # systemctl stop NetworkManager.service
    # rmdir /home rmdir: failed to remove ‘/home’: Device or resource busy
    # systemctl stop NetworkManager.service
    # rmdir /home rmdir: failed to remove ‘/home’: Device or resource busy
    # systemctl kill NetworkManager.service
    # rmdir /home rmdir: failed to remove ‘/home’: Device or resource busy
    # rmdir /home

    So it takes some time for all the parts of NetworkManager to die, but eventually, they do and you can remove /home.

    Unfortunately, I don’t see any reason why /home would be in use by NM. Very odd.

    —
    Jonathan Billings

    • Wow how thanks buddy!! I spent the entire evening trying to find the problem with /home, while lsof showed nothing.

      What a relief :)

  • Confirmed as well, thanks! What’s really odd is I didn’t see
    *anything* having a lock on /home, nada, zilch. We have a work-around in place for this but I was beating my head against the wall trying to figure it out.

    —
    “replicants are like any other machine. They’re either a benefit or a hazard. If they’re a benefit, it’s not my problem.”

  • NetworkManager.service has ‘ProtectHome=read-only’, which keeps NM from writing there. I presume namespacing /home in this way counts against unmounting it. This is a good security protection for everyone running NM, so I can see it being worth the tradeoff vs. being able to move or remove /home on a live system.

    (It also has ProtectSystem=true, which mounts /usr and /boot read-only as well.)

    If you wanted to change this, drop ProtectHome

  • Yup, verified those options are *not* set in 7.2. For a quick test I
    simply removed them from
    /usr/lib/systemd/system/NetworkManager.service, did a systemctl daemon-reload, restarted NetworkManager, logged back in as root, and was able to whack /home (7.3).

  • While that is a temporary solution, you should do what Matthew Miller says to do, which is put in an override in
    /etc/systemd/system/NetworkManger.service.d/. Otherwise, the next time your NM is updated it will be missing it.

  • Sorry, no “foo” — that was a cut-paste error. And as Jonathan says, make sure to spell NetworkManager right. :)

    sudo systemctl edit NetworkManager

    —
    Matthew Miller

    Fedora Project Leader

  • I blame all the holiday cookies they leave in the break room. Probably have rum in them or something.

    —
    Jonathan Billings

  • This has caused me a right royal pain.

    Updated my gold image that I use for terraform installs and part of my puppet build is to replace /home with a symlink to a NFS mount as all users are on NFS.

    Now breaks and looks like I’ve got to engineer round NetworkManager which will be fun. For me a big breaking change.