There are currently two solutions: one misunderstands the installation used by the original poster (OP); the other suggests using sudo to perform the installation. The former is irrelevant; the second goes against the advice of the installation instructions, which say,
we recommend installing it as a normal user, except perhaps on MacOSX; as I’m installing it on Ubuntu, not Mac, I don’t want to do it as root.
What I did instead was note that it was directory /usr/local/texlive/2018/ that was the problem: the installer didn’t have write access to /usr/local/. I thought that if the installer had write access to it, the problem would be solved. But I didn’t want to make that directory writeable to by anything and everything: it belongs to root, after all, for a reason. So what I did was:
sudo mkdir /usr/local/texlive sudo chmod a+w /usr/local/texlive
This creates a directory, /usr/local/texlive, with the same permissions as its problematic parent folder. The chmod command changes the /usr/local/texlive directory only to writeable by everyone. This is possibly too much, but it allowed the installer to do its thing. It might be a good idea to change the permissions back how they were originally, which is drwxr-xr-x:
sudo chmod 755 /usr/local/texlive
This might prevent further updates, but, according to the output of tlmgr update --self --all:
tlmgr update --self --all TeX Live 2018 is frozen forever and will no longer be updated. This happens in preparation for a new release.
Fair enough: it is 2019, after all. If this were not the case, the permissions could be changed again in the future to allow TeX Live to be updated again.
I’m not sure if this is the best solution to this problem, but it works, and it meant I didn’t have to install as root. I’m not sure if these two methods are equivalent or not. Presumably, all the other files installed by the installer belong to root, if sudo was used; otherwise to the user, that is, me.