Short answer: you can't. Ports below 1024 can be opened only by root. As per comment - well, you can, using CAP_NET_BIND_SERVICE, but that approach, applied to java bin will make any java program to be run with this setting, which is undesirable, if not a security risk.
The long answer: you can redirect connections on port 80 to some other port you can open as normal user.
Run as root:
# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
As loopback devices (like localhost) do not use the prerouting rules, if you need to use localhost, etc., add this rule as well (thanks @Francesco):
# iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-ports 8080
NOTE: The above solution is not well suited for multi-user systems, as any user can open port 8080 (or any other high port you decide to use), thus intercepting the traffic. (Credits to CesarB).
EDIT: as per comment question - to delete the above rule:
# iptables -t nat --line-numbers -n -L
This will output something like:
Chain PREROUTING (policy ACCEPT)
num target prot opt source destination
1 REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 redir ports 8088
2 REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 8080
The rule you are interested in is nr. 2, so to delete it:
# iptables -t nat -D PREROUTING 2
Best Answer
It's because sysrq-trigger is emergency only, and does not have a lot (any) of intelligence.
Looking in kernel source, at fs/super.c:do_emergency_remount(), it seems it will remount readonly filesystems by its order in the list (which is the same as you see when you do "cat /proc/mounts" for example). That is unfortunate, as it will most probably remount readonly your parent filesystem first, and then it will try to umount loopback filesytem, which would trigger writting (of superblock and any remaining modified data/metadata) to parent filesystem, which is already readonly, and hence fails with -EROFS.
The solution is use regular tools to umount and remount R/O instead of sysrq-trigger, for example using:
(which would umount all that it can, and remount rootfs R/O)
Or manually running in correct order:
If you need to use /proc/sysrq-trigger (why?), then you can either try to make kernel see the ordering you want (if that is possible at all, I haven't looked that deep) or modify the kernel to do the ordering from last-to-first (instead of first-to-last). It is perhaps not perfect (maybe for some more complex setups it would be wrong too), but it would be in most (if not all) cases better than current solution. I'd hazard it might even get into mainline kernel if you try to push it, as walking that particular list at that particular place is not performance critical, so cache misses etc. from walking the list backwards are not an issue.
BTW, you don't see the errors for VFAT (if it has not been modified lately), because VFAT (due to its simplicity) does not need to write modified superblock on umount back to disk.