• Status: Solved
  • Priority: Low
  • Security: Public
  • Views: 147
  • Last Modified:

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 ?
0
frankhelk
Asked:
frankhelk
  • 3
2 Solutions
 
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

0
 
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 ?
0
 
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.
0
 
frankhelkAuthor Commented:
Best workaround ...
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now