Mounting a ramfs via fstab changes mountpoint permissions - how to prevent that ?

On SLES 12.2 I do the following as root user:

mkdir -p /some/directory/ramdisk
chown -R simpleuser:users /some
chmod 777 /some/directory
chmod 777 /some/directory/ramdisk

Open in new window

Then I add this to /etc/fstab:
ramfs /some/directory/ramdisk ramfs defaults 0 0

Open in new window

followed by
mount /some/directory/ramdisk

Open in new window

What I expect is a ramfs mounted to /some/director/ramdisk, owned by simpleuser and users, with permissions set to 777.

Surprisingly, after rebooting the machine, the owner of /some/director/ramdisk is root:root, and the permissions have changed to something more restrictive. I deem that more of a feature  than a bug, but that behaviour is really annoying in the environment I use it in.

Currently I do an explicit change of ownership and permissions prior to starting the application that uses the ramdisk (in the respective script, with sudo), but I deem that not very elegant.

Any hint what causes the changes, and how to prevent them ?
LVL 14
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

David FavorLinux/LXD/WordPress/Hosting SavantCommented:
This is correct behavior.

For this to work across reboots, you must move your mount directives into /etc/fstab.

Also, best use tmpfs, rather than ramfs, as tmpfs rolls over to swap space if it's space is exceeded. With a ramfs file system, your app will simply crash, if memory is exceeded.

Here's an example of a 2G tmpfs file system + also mount options for running high speed ext4 with MariaDB/MySQL direct i/o databases...

net11 # cat /etc/fstab
# <file system>	<mount point>	<type>	<options>	<dump>	<pass>
/dev/md4	/	ext4	errors=remount-ro,noatime,dioread_nolock	0	1
/dev/md2	/boot	ext4	errors=remount-ro,relatime	0	1
/dev/sda3	swap	swap	defaults	0	0
/dev/sdb3	swap	swap	defaults	0	0
proc		/proc	proc	defaults		0	0
sysfs		/sys	sysfs	defaults		0	0
devtmpfs	/dev	devtmpfs	rw	0	0
none     /tmp    tmpfs   rw,noatime,mode=1777,size=2G             0 0

Open in new window

frankhelkAuthor Commented:
Unfortunately (for that aspect) I've preferred ramfs over tempfs for good reasons and after long consideration ... the application I did that for is a bit picky with access time for the respective files, so I'll need to circumvent swapping as sure as possible.

On the other side, the application ist the only one to write there, and the size of the created files is well restricted - there's no risk of excessive data volume and the machine has plenty of RAM available. Therefore the risk of freezing the machine due to a full RAM is neglectible.

Any further hint how to prevent the permissions and ownership changes ?
frankhelkAuthor Commented:
I've found no solution to that exact problem - I now circumvent it by just adjusting ownership and permissions after booting up the machine, prior to running the desired applican which uses the ramfs.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
frankhelkAuthor Commented:
Best workaround ...
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.