Tested on the current master branch, commit a10619bf1d482e189fc3f0dceed5ef459b410667
Running Slurm in a single node test config, on Ubuntu 20.04 with kernel 5.4.0-73-generic.

$ cat /etc/slurm/job_container.conf
BasePath=/var/run/slurm
AutoBasePath=true


When starting a new job, it has access to a per-job filesystem mounted in /tmp:
$ srun --pty bash
$ findmnt /tmp
TARGET SOURCE             FSTYPE OPTIONS
/tmp   tmpfs[/slurm/8/.8] tmpfs  rw,nosuid,nodev,noexec,relatime,size=32594660k,mode=755

And from this job you can write to /tmp:
$ echo $(hostname) > /tmp/test ; cat /tmp/test
ioctl

From another terminal running in the root mount namespace, you can indeed see that there is a mount for this filesystem:
$ findmnt -R /run/slurm  
TARGET             SOURCE                 FSTYPE OPTIONS
/run/slurm         tmpfs[/slurm]          tmpfs  rw,nosuid,nodev,noexec,relatime,size=32594660k,mode=755
└─/run/slurm/8/.ns nsfs[mnt:[4026532561]] nsfs   rw


Now, if you stop slurmd normally while the job is still running, /run/slurm will be unmounted:
$ findmnt -R /run/slurm ; echo $?
1

And then, restarting slurmd will create new mounts, but with a different mount namespace (4026532561 vs 4026532562):
$ findmnt -R /run/slurm
TARGET             SOURCE                 FSTYPE OPTIONS
/run/slurm         tmpfs[/slurm]          tmpfs  rw,nosuid,nodev,noexec,relatime,size=32594660k,mode=755
└─/run/slurm/8/.ns nsfs[mnt:[4026532562]] nsfs   rw


As a result, /tmp is not usable from the existing job anymore:
$ ls /tmp
ls: cannot open directory '/tmp': Permission denied