[opensuse] Permissions, systemd and automount
I am trying to use x-systemd.automount,noauto in /etc/fstab to set up automount of disks. For the most part it works fine. I am struggling with permissions. When the disk is, say, CIFS, I can add uid=roger to /etc/fstab and the files will belong to roger. This is because the file system itself does not have user ownership of individual files. Or at least the CISF driver makes it so. If I want this to work with ext4, this seems not to work as I would like. The problem is the top-level mount point. I do not seem to have any control over the permissions. So if a user inserts a disk, they cannot make any files in the top level of the disk. But that is what I need. When we were not using automount, the mount point's permissions were whatever the disk file had. They were not changed by the mount command. Autofs sets the permissions to rwx------. We really want to use autofs. If the disks are not inserted and they are in /etc/fstab, the system will not boot. Autofs solves this nicely. Any ideas on how to sort out permissions when systemd is managing autofs? I have googled, but all seems to discuss when you set up autofs yourself. I can do that. But we are trying to make this less complicated for the people who are managing the systems. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-02-28 16:01, Roger Oberholtzer wrote:
I am trying to use x-systemd.automount,noauto in /etc/fstab to set up automount of disks. For the most part it works fine. I am struggling with permissions.
When the disk is, say, CIFS, I can add uid=roger to /etc/fstab and the files will belong to roger. This is because the file system itself does not have user ownership of individual files. Or at least the CISF driver makes it so.
FAT doesn't have "users", and for NTFS the Linux driver doesn't support them.
If I want this to work with ext4, this seems not to work as I would like.
You can not se uid/gid on Linux filesystem via mount options, as the filesystem has them written in the metadata.
The problem is the top-level mount point. I do not seem to have any control over the permissions. So if a user inserts a disk, they cannot make any files in the top level of the disk. But that is what I need. When we were not using automount, the mount point's permissions were whatever the disk file had. They were not changed by the mount command. Autofs sets the permissions to rwx------.
We really want to use autofs. If the disks are not inserted and they are in /etc/fstab, the system will not boot. Autofs solves this nicely.
Any ideas on how to sort out permissions when systemd is managing autofs? I have googled, but all seems to discuss when you set up autofs yourself. I can do that. But we are trying to make this less complicated for the people who are managing the systems.
Not related at all. Mount the disk by your preferred method, then use chmod and chown to change the permissions normally. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Wed, Feb 28, 2018 at 4:08 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Any ideas on how to sort out permissions when systemd is managing autofs? I have googled, but all seems to discuss when you set up autofs yourself. I can do that. But we are trying to make this less complicated for the people who are managing the systems.
Not related at all.
Not sure what you mean. I meant that having the user add this to the /etc/fstab entry that they want automounted when accessed makes is easier for the untrained user: x-systemd.automount,noauto Editing a number of automount files and making parts of the mount directories is beyond their capabilities. We have bigger fish to fry with our users...
Mount the disk by your preferred method, then use chmod and chown to change the permissions normally.
The users should not be changing the permissions on files. At least not via a command they have to run. Then they could just as well mount the thing by hand and we skip the autofs thing. Desktops like KDE sort this out for USB disks. So there is no technical reason this cannot be done. In our case, these are SATA disks in removable drive bays, and we expect them to show up in a specified place when they are inserted. They are used for data backup. The more idiot-proof we can make this the better. I know, they will just build bigger idiots. But it keeps us in a job... -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Feb 28, 2018 at 6:23 PM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Wed, Feb 28, 2018 at 4:08 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Any ideas on how to sort out permissions when systemd is managing autofs? I have googled, but all seems to discuss when you set up autofs yourself. I can do that. But we are trying to make this less complicated for the people who are managing the systems.
Not related at all.
Not sure what you mean. I meant that having the user add this to the /etc/fstab entry that they want automounted when accessed makes is easier for the untrained user:
x-systemd.automount,noauto
Editing a number of automount files and making parts of the mount directories is beyond their capabilities. We have bigger fish to fry with our users...
Mount the disk by your preferred method, then use chmod and chown to change the permissions normally.
The users should not be changing the permissions on files. At least not via a command they have to run. Then they could just as well mount the thing by hand and we skip the autofs thing.
Desktops like KDE sort this out for USB disks.
Show me how it works for you in KDE with ext4 on USB disk.
So there is no technical reason this cannot be done.
Why bother with file permissions at all then? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Feb 28, 2018 at 4:31 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Wed, Feb 28, 2018 at 6:23 PM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Wed, Feb 28, 2018 at 4:08 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Any ideas on how to sort out permissions when systemd is managing autofs? I have googled, but all seems to discuss when you set up autofs yourself. I can do that. But we are trying to make this less complicated for the people who are managing the systems.
Not related at all.
Not sure what you mean. I meant that having the user add this to the /etc/fstab entry that they want automounted when accessed makes is easier for the untrained user:
x-systemd.automount,noauto
Editing a number of automount files and making parts of the mount directories is beyond their capabilities. We have bigger fish to fry with our users...
Mount the disk by your preferred method, then use chmod and chown to change the permissions normally.
The users should not be changing the permissions on files. At least not via a command they have to run. Then they could just as well mount the thing by hand and we skip the autofs thing.
Desktops like KDE sort this out for USB disks.
Show me how it works for you in KDE with ext4 on USB disk.
I'm not saying that it works great. But KDE at least mounts the disk as the user who is logged in. If they have permissions within the file system is a different matter. At the top level of an ext4 disk, the permissions are of the directory on which it is mounted. Underneath that it is in the disk's own file system. But not at the top level. You can play with that. Just make the directory in which you mount an ext4 disk rwxrwxrwx. Then, any user can add a file or directory in the top level. If they make a directory, it will belong to them, and so they can make changes within that directory. Things that do not belong to them follow the expected permissions actions. So I would be happy it I could either get the mount directory to belong to the user who initiated the mount, or to have it set to some permissions that I can control. Neither seem possible with autofs via systemd.
Why bother with file permissions at all then?
For our use (the removable backup disk), that would not be a problem. We would not want the whole system that way. But some file systems would be fine. In fact, I'm not asking for no permissions. I just need control over the permissions of the mount directory. The permissions in the file system are fine. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
28.02.2018 18:43, Roger Oberholtzer пишет:
On Wed, Feb 28, 2018 at 4:31 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Wed, Feb 28, 2018 at 6:23 PM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Wed, Feb 28, 2018 at 4:08 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Any ideas on how to sort out permissions when systemd is managing autofs? I have googled, but all seems to discuss when you set up autofs yourself. I can do that. But we are trying to make this less complicated for the people who are managing the systems.
Not related at all.
Not sure what you mean. I meant that having the user add this to the /etc/fstab entry that they want automounted when accessed makes is easier for the untrained user:
x-systemd.automount,noauto
Editing a number of automount files and making parts of the mount directories is beyond their capabilities. We have bigger fish to fry with our users...
Mount the disk by your preferred method, then use chmod and chown to change the permissions normally.
The users should not be changing the permissions on files. At least not via a command they have to run. Then they could just as well mount the thing by hand and we skip the autofs thing.
Desktops like KDE sort this out for USB disks.
Show me how it works for you in KDE with ext4 on USB disk.
I'm not saying that it works great. But KDE at least mounts the disk as the user who is logged in.
Again, show me how KDE does it for USB disk *with ext4 on it*. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.21.1802282040110.696@Telcontar.valinor> On Wednesday, 2018-02-28 at 20:37 +0300, Andrei Borzenkov wrote:
28.02.2018 18:43, Roger Oberholtzer пишет:
On Wed, Feb 28, 2018 at 4:31 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Wed, Feb 28, 2018 at 6:23 PM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Wed, Feb 28, 2018 at 4:08 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Any ideas on how to sort out permissions when systemd is managing autofs? I have googled, but all seems to discuss when you set up autofs yourself. I can do that. But we are trying to make this less complicated for the people who are managing the systems.
Not related at all.
Not sure what you mean. I meant that having the user add this to the /etc/fstab entry that they want automounted when accessed makes is easier for the untrained user:
The option "uid" is simply ignored because it not possible to apply it.
x-systemd.automount,noauto
Editing a number of automount files and making parts of the mount directories is beyond their capabilities. We have bigger fish to fry with our users...
Mount the disk by your preferred method, then use chmod and chown to change the permissions normally.
The users should not be changing the permissions on files. At least not via a command they have to run. Then they could just as well mount the thing by hand and we skip the autofs thing.
Well, you have no other way.
Desktops like KDE sort this out for USB disks.
Show me how it works for you in KDE with ext4 on USB disk.
I'm not saying that it works great. But KDE at least mounts the disk as the user who is logged in.
Again, show me how KDE does it for USB disk *with ext4 on it*.
I have one stick with ext4 on it. I'm on XFCE, so I mount it with "Thunar", and look at the permissions with a terminal: cer@Telcontar:~> l /media total 12 drwxr-xr-x 3 root root 4096 Feb 28 20:03 ./ drwxr-xr-x 38 root root 4096 Feb 4 13:44 ../ drwxr-xr-x 4 cer cer 4096 Jul 25 2017 Ext4Flash/ <========== - -rw-r--r-- 1 root root 0 Jun 16 2013 not_mounted cer@Telcontar:~> I remove (both logically and physically) it and open a new full graphical session as another user, this time with Gnome. I look at the permissions: cer-g@Telcontar:~> l /media total 12 drwxr-xr-x 3 root root 4096 Feb 28 20:06 ./ drwxr-xr-x 38 root root 4096 Feb 4 13:44 ../ drwxr-xr-x 4 cer cer 4096 Jul 25 2017 Ext4Flash/ <=== - -rw-r--r-- 1 root root 0 Jun 16 2013 not_mounted cer-g@Telcontar:~> As you see, the ownership remains unaltered, it belongs to the first user. I'll try a KDE session now. [...] Well, neither KDE nor Plasma are on the list of sessions, this is strange. I'll try installing things in YaST. [...] Marking "KDE Plasma 5 Desktop". Do I need "KDE Desktop Environment"? I'll tick just in case - huh, only adds "patterns-openSUSE-kde_plasma - KDE Plasma 5 Desktop" and "patterns-openSUSE-kde - KDE Desktop Environment", but no packages. [...] Ok, now I'm in Plasma. I plug in the stick a third time, look at the permisions, and... surprise? cer-g@Telcontar:~> l /media total 12 drwxr-xr-x 3 root root 4096 Feb 28 20:28 ./ drwxr-xr-x 38 root root 4096 Feb 4 13:44 ../ drwxr-xr-x 4 cer cer 4096 Jul 25 2017 Ext4Flash/ <== - -rw-r--r-- 1 root root 0 Jun 16 2013 not_mounted cer-g@Telcontar:~> jstar /tmp/p Nope, no surprise for me, the permissions are the same. The permissions of the mount point do not change. Just in case, I look at the mount point after "safely removal": cer@Telcontar:~> l /media total 8 drwxr-xr-x 2 root root 4096 Feb 28 20:33 ./ drwxr-xr-x 38 root root 4096 Feb 4 13:44 ../ - -rw-r--r-- 1 root root 0 Jun 16 2013 not_mounted cer@Telcontar:~> The permissions of the mount point are "remembered" from the last time across different users if the filesystem is ext4 (or any Linux filesystem, but I'm not goint to test). There remains to see what are the permissions on a newly formatted stick, but I don't have one available. I might reformat this one. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqXBqIACgkQtTMYHG2NR9VNvQCeL8+R6hUwAZ1wvJlulbtJkI/H OWwAn20wVSQSEbP9c+eE9ButSWqX8bTN =48j9 -----END PGP SIGNATURE-----
On Wed, Feb 28, 2018 at 6:37 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Again, show me how KDE does it for USB disk *with ext4 on it*.
As a start, the mount directory belongs to the user. I just plugged in a ext4 USB disk, and the mount point in /run/media/roger/ is: drwxr-xr-x 2 roger users 8192 Feb 1 2017 DriveA It's mounted on a directory that belongs to me, that is also located in a directory that belongs to me. If course if there are things in the drive that do not belong to me, I can do nothing. It is the mount point itself that I am concerned about. I don't want this thread to be about KDE. It is about trying to make systemd automount work as I need. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 1, 2018 at 10:53 AM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Wed, Feb 28, 2018 at 6:37 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Again, show me how KDE does it for USB disk *with ext4 on it*.
As a start, the mount directory belongs to the user. I just plugged in a ext4 USB disk, and the mount point in /run/media/roger/ is:
drwxr-xr-x 2 roger users 8192 Feb 1 2017 DriveA
And your claim is that owner and permissions come from KDE automounter and not from filesystem on this disk? Mount it manually, without use of KDE automounter, and show permissions in this case.
It's mounted on a directory that belongs to me, that is also located in a directory that belongs to me.
And how is it related to permissions of root inode on mounted filesystem which is what controls access after it has been mounted?
If course if there are things in the drive that do not belong to me, I can do nothing.
It is the mount point itself that I am concerned about.
Mouunt point permissions are irrelevant after it has been mounted over.
I don't want this thread to be about KDE. It is about trying to make systemd automount work as I need.
You said that KDE does the right thing and I simply try to understand what "the right thing" is. So far you still did not explain it nor demonstrated that "the right thing" is controller by the program used to mount disk. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 1, 2018 at 10:57 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Thu, Mar 1, 2018 at 10:53 AM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Wed, Feb 28, 2018 at 6:37 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Again, show me how KDE does it for USB disk *with ext4 on it*.
As a start, the mount directory belongs to the user. I just plugged in a ext4 USB disk, and the mount point in /run/media/roger/ is:
drwxr-xr-x 2 roger users 8192 Feb 1 2017 DriveA
And your claim is that owner and permissions come from KDE automounter and not from filesystem on this disk? Mount it manually, without use of KDE automounter, and show permissions in this case.
It's mounted on a directory that belongs to me, that is also located in a directory that belongs to me.
And how is it related to permissions of root inode on mounted filesystem which is what controls access after it has been mounted?
If course if there are things in the drive that do not belong to me, I can do nothing.
It is the mount point itself that I am concerned about.
Mouunt point permissions are irrelevant after it has been mounted over.
Not true for the top level. If the directory before the mount has 0777 (all rwx), after the mount those will be the permissions for the root of the mounted volume. With those permissions, ANYONE can make a folder or file in the top level. Existing files and all in the mounted volume of course are controlled by the permissions in the mounted volume. But the top level directory is different in this significant respect. Automount via systemd is setting the top level to 0700, with the owner as root. So no one else can do anything in the top level directory. In fact, a non-root user who owns a file in the top level like this cannot even delete this file that belongs to them because they don't have permissions on the top level directory.
I don't want this thread to be about KDE. It is about trying to make systemd automount work as I need.
You said that KDE does the right thing and I simply try to understand what "the right thing" is. So far you still did not explain it nor demonstrated that "the right thing" is controller by the program used to mount disk.
With KDE, the directory that contains the mount point belongs to the user who mounted it. It does not belong to root. Autofs via systemd makes the top level directory belong to root - no matter who mounted it. I would even be happy if the top level permissions were 0775. Then the user could join the group. But there are no group permissions at all. You have to be root. With removable media, this is an antiquated concept. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 1, 2018 at 5:16 PM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
If the directory before the mount has 0777 (all rwx), after the mount those will be the permissions for the root of the mounted volume.
localhost:~ # ls -ld /mnt drwxrwxrwx 1 root root 0 Dec 6 03:16 /mnt localhost:~ # mount /dev/sdb1 /mnt localhost:~ # ls -ld /mnt drwx------ 1 test root 8 Feb 28 10:08 /mnt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 1, 2018 at 3:24 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Thu, Mar 1, 2018 at 5:16 PM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
If the directory before the mount has 0777 (all rwx), after the mount those will be the permissions for the root of the mounted volume.
localhost:~ # ls -ld /mnt drwxrwxrwx 1 root root 0 Dec 6 03:16 /mnt localhost:~ # mount /dev/sdb1 /mnt localhost:~ # ls -ld /mnt drwx------ 1 test root 8 Feb 28 10:08 /mnt
# ls -ld /backup/ drwxrwxrwx 2 root root 4096 Mar 1 15:37 /backup/ # mount /dev/sdb1 /backup/ # ls -ld /backup/ drwxrwxrwx 2 root root 4096 Mar 1 15:37 /backup/ This is a newly formatted ext4 volume. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 1 Mar 2018 15:49:15 +0100 Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Thu, Mar 1, 2018 at 3:24 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Thu, Mar 1, 2018 at 5:16 PM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
If the directory before the mount has 0777 (all rwx), after the mount those will be the permissions for the root of the mounted volume.
localhost:~ # ls -ld /mnt drwxrwxrwx 1 root root 0 Dec 6 03:16 /mnt localhost:~ # mount /dev/sdb1 /mnt localhost:~ # ls -ld /mnt drwx------ 1 test root 8 Feb 28 10:08 /mnt
# ls -ld /backup/ drwxrwxrwx 2 root root 4096 Mar 1 15:37 /backup/ # mount /dev/sdb1 /backup/ # ls -ld /backup/ drwxrwxrwx 2 root root 4096 Mar 1 15:37 /backup/
This is a newly formatted ext4 volume.
So whilst it is mounted, change its permissions (i.e. chmod whatever /backup) and its owner if you wish. Then unmount it. Check again what the permissions of the mount point are. Then mount it again and check what the permissions of its top-level directory are again. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 1, 2018 at 5:00 PM, Dave Howorth <dave@howorth.org.uk> wrote:
On Thu, 1 Mar 2018 15:49:15 +0100 Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Thu, Mar 1, 2018 at 3:24 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Thu, Mar 1, 2018 at 5:16 PM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
If the directory before the mount has 0777 (all rwx), after the mount those will be the permissions for the root of the mounted volume.
localhost:~ # ls -ld /mnt drwxrwxrwx 1 root root 0 Dec 6 03:16 /mnt localhost:~ # mount /dev/sdb1 /mnt localhost:~ # ls -ld /mnt drwx------ 1 test root 8 Feb 28 10:08 /mnt
# ls -ld /backup/ drwxrwxrwx 2 root root 4096 Mar 1 15:37 /backup/ # mount /dev/sdb1 /backup/ # ls -ld /backup/ drwxrwxrwx 2 root root 4096 Mar 1 15:37 /backup/
This is a newly formatted ext4 volume.
So whilst it is mounted, change its permissions (i.e. chmod whatever /backup) and its owner if you wish. Then unmount it. Check again what the permissions of the mount point are. Then mount it again and check what the permissions of its top-level directory are again.
This did not seem to do as I expected on an ext4 partition: mount /backup cd /backup chmod a+rwx . After a remount, the permissions are not a+rw Sigh. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Thu, Mar 1, 2018 at 5:00 PM, Dave Howorth <dave@howorth.org.uk> wrote:
On Thu, 1 Mar 2018 15:49:15 +0100 Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Thu, Mar 1, 2018 at 3:24 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Thu, Mar 1, 2018 at 5:16 PM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
If the directory before the mount has 0777 (all rwx), after the mount those will be the permissions for the root of the mounted volume.
localhost:~ # ls -ld /mnt drwxrwxrwx 1 root root 0 Dec 6 03:16 /mnt localhost:~ # mount /dev/sdb1 /mnt localhost:~ # ls -ld /mnt drwx------ 1 test root 8 Feb 28 10:08 /mnt
# ls -ld /backup/ drwxrwxrwx 2 root root 4096 Mar 1 15:37 /backup/ # mount /dev/sdb1 /backup/ # ls -ld /backup/ drwxrwxrwx 2 root root 4096 Mar 1 15:37 /backup/
This is a newly formatted ext4 volume.
So whilst it is mounted, change its permissions (i.e. chmod whatever /backup) and its owner if you wish. Then unmount it. Check again what the permissions of the mount point are. Then mount it again and check what the permissions of its top-level directory are again.
This did not seem to do as I expected on an ext4 partition:
mount /backup cd /backup chmod a+rwx .
After a remount, the permissions are not a+rw
Sigh.
Just a wild guess - I've never used automount on root, only at least one level down, e.g. /home and such. Might it be worth a try to use /mnt/backup ? (for instance). -- Per Jessen, Zürich (-2.2°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2018-03-01 at 17:13 +0100, Roger Oberholtzer wrote:
On Thu, Mar 1, 2018 at 5:00 PM, Dave Howorth <dave@howorth.org.uk> wrote:
On Thu, 1 Mar 2018 15:49:15 +0100 Roger Oberholtzer <> wrote:
On Thu, Mar 1, 2018 at 3:24 PM, Andrei Borzenkov <> wrote:
On Thu, Mar 1, 2018 at 5:16 PM, Roger Oberholtzer <> wrote:
If the directory before the mount has 0777 (all rwx), after the mount those will be the permissions for the root of the mounted volume.
No.
localhost:~ # ls -ld /mnt drwxrwxrwx 1 root root 0 Dec 6 03:16 /mnt localhost:~ # mount /dev/sdb1 /mnt localhost:~ # ls -ld /mnt drwx------ 1 test root 8 Feb 28 10:08 /mnt
As expected.
# ls -ld /backup/ drwxrwxrwx 2 root root 4096 Mar 1 15:37 /backup/ # mount /dev/sdb1 /backup/ # ls -ld /backup/ drwxrwxrwx 2 root root 4096 Mar 1 15:37 /backup/
This is a newly formatted ext4 volume.
If this happens and /backup is not a LINUX filesystem, something changed them.
So whilst it is mounted, change its permissions (i.e. chmod whatever /backup) and its owner if you wish. Then unmount it. Check again what the permissions of the mount point are. Then mount it again and check what the permissions of its top-level directory are again.
This did not seem to do as I expected on an ext4 partition:
mount /backup cd /backup chmod a+rwx .
After a remount, the permissions are not a+rw
Initial state: the mount point does not exist. Telcontar:~ # l /media total 8 drwxr-xr-x 2 root root 4096 Mar 1 11:57 ./ drwxr-xr-x 38 root root 4096 Feb 4 13:44 ../ - -rw-r--r-- 1 root root 0 Jun 16 2013 not_mounted I insert the stick, and mount it via desktop: Telcontar:~ # l /media total 12 drwxr-xr-x 3 root root 4096 Mar 1 18:34 ./ drwxr-xr-x 38 root root 4096 Feb 4 13:44 ../ drwxr-xr-x 4 cer cer 4096 Jul 25 2017 Ext4Flash/ <==== - -rw-r--r-- 1 root root 0 Jun 16 2013 not_mounted I change its permissions: Telcontar:~ # chmod g-r-x /media/Ext4Flash/ Telcontar:~ # umount /media/Ext4Flash/ Telcontar:~ # l /media total 8 drwxr-xr-x 2 root root 4096 Mar 1 18:35 ./ drwxr-xr-x 38 root root 4096 Feb 4 13:44 ../ - -rw-r--r-- 1 root root 0 Jun 16 2013 not_mounted I mount it again: Telcontar:~ # l /media total 12 drwxr-xr-x 3 root root 4096 Mar 1 18:35 ./ drwxr-xr-x 38 root root 4096 Feb 4 13:44 ../ drwx---r-x 4 cer cer 4096 Jul 25 2017 Ext4Flash/ - -rw-r--r-- 1 root root 0 Jun 16 2013 not_mounted Telcontar:~ # The permissions are those I changed. They keep, on newly created mount point. Stick removed: Telcontar:~ # l /media total 8 drwxr-xr-x 2 root root 4096 Mar 1 18:42 ./ drwxr-xr-x 38 root root 4096 Feb 4 13:44 ../ - -rw-r--r-- 1 root root 0 Jun 16 2013 not_mounted I create mount point: Telcontar:~ # md /media/Ext4Flash/ Telcontar:~ # l /media total 12 drwxr-xr-x 3 root root 4096 Mar 1 18:43 ./ drwxr-xr-x 38 root root 4096 Feb 4 13:44 ../ drwxr-xr-x 2 root root 4096 Mar 1 18:43 Ext4Flash/ - -rw-r--r-- 1 root root 0 Jun 16 2013 not_mounted Change permissions of mountpoint: Telcontar:~ # chmod g-r-x,o-r-x /media/Ext4Flash/ Telcontar:~ # l /media total 12 drwxr-xr-x 3 root root 4096 Mar 1 18:43 ./ drwxr-xr-x 38 root root 4096 Feb 4 13:44 ../ drwx------ 2 root root 4096 Mar 1 18:43 Ext4Flash/ - -rw-r--r-- 1 root root 0 Jun 16 2013 not_mounted Telcontar:~ # mount it via desktop: Telcontar:~ # l /media total 16 drwxr-xr-x 4 root root 4096 Mar 1 18:45 ./ drwxr-xr-x 38 root root 4096 Feb 4 13:44 ../ drwx------ 2 root root 4096 Mar 1 18:43 Ext4Flash/ drwxr-xr-x 4 cer cer 4096 Jul 25 2017 Ext4Flash1/ - -rw-r--r-- 1 root root 0 Jun 16 2013 not_mounted Telcontar:~ # Ah, ok, it created a new mountpoint. Try manually. Telcontar:~ # mount | grep Ext4Flash /dev/sdf1 on /media/Ext4Flash1 type ext4 (rw,nosuid,nodev,relatime,block_validity,delalloc,barrier,user_xattr,acl,uhelper=udisks2) Telcontar:~ # Telcontar:~ # umount /media/Ext4Flash1 Telcontar:~ # mount -v /dev/sdf1 /media/Ext4Flash mount: /dev/sdf1 mounted on /media/Ext4Flash. Telcontar:~ # l /media total 12 drwxr-xr-x 3 root root 4096 Mar 1 18:46 ./ drwxr-xr-x 38 root root 4096 Feb 4 13:44 ../ drwxr-xr-x 4 cer cer 4096 Jul 25 2017 Ext4Flash/ - -rw-r--r-- 1 root root 0 Jun 16 2013 not_mounted Telcontar:~ # See? the mount point permissions get changed the instant I mount something on it to those of the something. They override what the mountpoint has. Also, notice the date, here and on Ext4Flash1/ above. Now I umount: Telcontar:~ # l /media total 12 drwxr-xr-x 3 root root 4096 Mar 1 18:46 ./ drwxr-xr-x 38 root root 4096 Feb 4 13:44 ../ drwx------ 2 root root 4096 Mar 1 18:43 Ext4Flash/ - -rw-r--r-- 1 root root 0 Jun 16 2013 not_mounted Telcontar:~ # They recover their previous status. Even the date. I try to force an uid: Telcontar:~ # mount -v -o uid=2000 /dev/sdf1 /media/Ext4Flash mount: wrong fs type, bad option, bad superblock on /dev/sdf1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. Telcontar:~ # mount -v -o uid=1000 /dev/sdf1 /media/Ext4Flash mount: wrong fs type, bad option, bad superblock on /dev/sdf1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. Telcontar:~ # Lets see the log: Telcontar:~ # tail /var/log/messages <1.4> 2018-03-01 18:45:18 Telcontar org.gtk.vfs.UDisks2VolumeMonitor 5731 - - disc.c:424: error opening file BDMV/index.bdmv <1.4> 2018-03-01 18:45:18 Telcontar org.gtk.vfs.UDisks2VolumeMonitor 5731 - - disc.c:424: error opening file BDMV/BACKUP/index.bdmv <3.6> 2018-03-01 18:46:04 Telcontar smartd 1542 - - Device: /dev/sdc [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 105 to 107 <3.5> 2018-03-01 18:46:29 Telcontar udisksd 5297 - - Cleaning up mount point /media/Ext4Flash1 (device 8:81 is not mounted) <0.4> 2018-03-01 18:46:41 Telcontar kernel - - - [139827.580395] EXT4-fs (sdf1): warning: mounting unchecked fs, running e2fsck is recommended <0.6> 2018-03-01 18:46:41 Telcontar kernel - - - [139827.584482] EXT4-fs (sdf1): mounted filesystem without journal. Opts: (null) <1.4> 2018-03-01 18:46:41 Telcontar org.gtk.vfs.UDisks2VolumeMonitor 5731 - - disc.c:424: error opening file BDMV/index.bdmv <1.4> 2018-03-01 18:46:41 Telcontar org.gtk.vfs.UDisks2VolumeMonitor 5731 - - disc.c:424: error opening file BDMV/BACKUP/index.bdmv <0.3> 2018-03-01 18:48:33 Telcontar kernel - - - [139939.297469] EXT4-fs (sdf1): Unrecognized mount option "uid=2000" or missing value <0.3> 2018-03-01 18:48:39 Telcontar kernel - - - [139944.977119] EXT4-fs (sdf1): Unrecognized mount option "uid=1000" or missing value Telcontar:~ # Telcontar:~ # mount -v -o fmask=0117 /dev/sdf1 /media/Ext4Flash mount: wrong fs type, bad option, bad superblock on /dev/sdf1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. Telcontar:~ # <0.3> 2018-03-01 18:51:06 Telcontar kernel - - - [140092.124212] EXT4-fs (sdf1): Unrecognized mount option "fmask=0117" or missing value Lets say it again: no mount option will modify the mount permissions of the root directory of an ext4 filesystem. This is the intended behaviour. You can only change it by script that runs chmod on mount. It is possible that KDE has a format program that when it formats a stick as ext4 from the user, it sets appropriate permissions for that user. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqYQFIACgkQtTMYHG2NR9UwGgCfRFPi5+MaOxH9MegNdR6HtzU6 CkQAn3cnl3QSlf7H2H3IW8JXYFRnHyUl =/baR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
01.03.2018 17:49, Roger Oberholtzer пишет:
On Thu, Mar 1, 2018 at 3:24 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Thu, Mar 1, 2018 at 5:16 PM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
If the directory before the mount has 0777 (all rwx), after the mount those will be the permissions for the root of the mounted volume.
localhost:~ # ls -ld /mnt drwxrwxrwx 1 root root 0 Dec 6 03:16 /mnt localhost:~ # mount /dev/sdb1 /mnt localhost:~ # ls -ld /mnt drwx------ 1 test root 8 Feb 28 10:08 /mnt
# ls -ld /backup/ drwxrwxrwx 2 root root 4096 Mar 1 15:37 /backup/ # mount /dev/sdb1 /backup/ # ls -ld /backup/ drwxrwxrwx 2 root root 4096 Mar 1 15:37 /backup/
And is /dev/sdb1 (still) mounted on /backup at this point? grep -E 'backup|sdb1' /proc/self/mountinfo stat /backup before and after your commands?
This is a newly formatted ext4 volume.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Thu, Mar 1, 2018 at 10:57 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Mouunt point permissions are irrelevant after it has been mounted over.
With KDE, the directory that contains the mount point belongs to the user who mounted it. It does not belong to root. Autofs via systemd makes the top level directory belong to root - no matter who mounted it.
Not sure what version you are using. Here (Tumbleweed, Plasma5) I just added an external USB disk with some system partition of a test install. I went to the device notifier and clicked there to mount it. woodstock:~% cd /run/media/pit/ woodstock:pit% l total 0 drwxr-x---+ 3 root root 60 Mar 1 15:18 ./ drwxr-xr-x 3 root root 60 Mar 1 14:01 ../ drwxr-xr-x 1 root root 156 Feb 8 15:41 8289f59c-2839-45a3-a122-f4393ff9b4fd/ woodstock:pit% cd 8289f59c-2839-45a3-a122-f4393ff9b4fd/ woodstock:8289f59c-2839-45a3-a122-f4393ff9b4fd% touch test touch: cannot touch 'test': Permission denied (that was a btrfs FS, but I get the same with en ext4) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 1, 2018 at 3:30 PM, Peter Suetterlin <pit@astro.su.se> wrote:
Roger Oberholtzer wrote:
On Thu, Mar 1, 2018 at 10:57 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Mouunt point permissions are irrelevant after it has been mounted over.
With KDE, the directory that contains the mount point belongs to the user who mounted it. It does not belong to root. Autofs via systemd makes the top level directory belong to root - no matter who mounted it.
Not sure what version you are using. Here (Tumbleweed, Plasma5) I just added an external USB disk with some system partition of a test install. I went to the device notifier and clicked there to mount it.
woodstock:~% cd /run/media/pit/ woodstock:pit% l total 0 drwxr-x---+ 3 root root 60 Mar 1 15:18 ./ drwxr-xr-x 3 root root 60 Mar 1 14:01 ../ drwxr-xr-x 1 root root 156 Feb 8 15:41 8289f59c-2839-45a3-a122-f4393ff9b4fd/
woodstock:pit% cd 8289f59c-2839-45a3-a122-f4393ff9b4fd/
woodstock:8289f59c-2839-45a3-a122-f4393ff9b4fd% touch test touch: cannot touch 'test': Permission denied
(that was a btrfs FS, but I get the same with en ext4)
I'm running Leap 42.3. In my case, /run/media/roger belongs to me (roger), and anything that gets mounted there (like a USB disk) has roger as the owner of the mount point. Nothing belongs to root. Of course, something in the mounted volume may belong to root. But not the top level. KDE is, of course, not the most consistent environment around. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Thu, Mar 1, 2018 at 3:30 PM, Peter Suetterlin <pit@astro.su.se> wrote:
woodstock:~% cd /run/media/pit/ woodstock:pit% l total 0 drwxr-x---+ 3 root root 60 Mar 1 15:18 ./ drwxr-xr-x 3 root root 60 Mar 1 14:01 ../ drwxr-xr-x 1 root root 156 Feb 8 15:41 8289f59c-2839-45a3-a122-f4393ff9b4fd/
I'm running Leap 42.3. In my case, /run/media/roger belongs to me (roger), and anything that gets mounted there (like a USB disk) has roger as the owner of the mount point. Nothing belongs to root. Of course, something in the mounted volume may belong to root. But not the top level.
Hmm, ok, so this seems to have changed. In TW it is handled via ACLs, (see the '+' at the end of the permissions): woodstock:/run/media% getfacl pit # file: pit # owner: root # group: root user::rwx user:pit:r-x group::--- mask::r-x other::--- But I don't have a 42.3 around (well, only headless servers....) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2018-03-01 at 15:30 +0100, Peter Suetterlin wrote:
Roger Oberholtzer wrote:
On Thu, Mar 1, 2018 at 10:57 AM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Mouunt point permissions are irrelevant after it has been mounted over.
With KDE, the directory that contains the mount point belongs to the user who mounted it. It does not belong to root. Autofs via systemd makes the top level directory belong to root - no matter who mounted it.
Not sure what version you are using. Here (Tumbleweed, Plasma5) I just added an external USB disk with some system partition of a test install. I went to the device notifier and clicked there to mount it.
woodstock:~% cd /run/media/pit/ woodstock:pit% l total 0 drwxr-x---+ 3 root root 60 Mar 1 15:18 ./ drwxr-xr-x 3 root root 60 Mar 1 14:01 ../ drwxr-xr-x 1 root root 156 Feb 8 15:41 8289f59c-2839-45a3-a122-f4393ff9b4fd/
woodstock:pit% cd 8289f59c-2839-45a3-a122-f4393ff9b4fd/
woodstock:8289f59c-2839-45a3-a122-f4393ff9b4fd% touch test touch: cannot touch 'test': Permission denied
(that was a btrfs FS, but I get the same with en ext4)
That is the expected behaviour. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqYOEUACgkQtTMYHG2NR9WTvgCfcbjypASvSUKJHUV1gNDB+ZVn XDwAnRKPMFSYq4qch7z/I0yHd3rtuF6z =KvzE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2018-03-01 at 08:53 +0100, Roger Oberholtzer wrote:
On Wed, Feb 28, 2018 at 6:37 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Again, show me how KDE does it for USB disk *with ext4 on it*.
As a start, the mount directory belongs to the user. I just plugged in a ext4 USB disk, and the mount point in /run/media/roger/ is:
drwxr-xr-x 2 roger users 8192 Feb 1 2017 DriveA
It's mounted on a directory that belongs to me, that is also located in a directory that belongs to me. If course if there are things in the drive that do not belong to me, I can do nothing.
It is the mount point itself that I am concerned about.
I don't want this thread to be about KDE. It is about trying to make systemd automount work as I need.
See the post in which I proved this is not so. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqX3T8ACgkQtTMYHG2NR9VX0wCeKpK8rfnGkm69XU+RWenyBP44 u+oAn2ah9swmve1fD+uxvmkOtjST6QQO =Z+I2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/03/18 02:53 AM, Roger Oberholtzer wrote:
On Wed, Feb 28, 2018 at 6:37 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Again, show me how KDE does it for USB disk *with ext4 on it*. As a start, the mount directory belongs to the user. I just plugged in a ext4 USB disk, and the mount point in /run/media/roger/ is:
drwxr-xr-x 2 roger users 8192 Feb 1 2017 DriveA
It's mounted on a directory that belongs to me, that is also located in a directory that belongs to me. If course if there are things in the drive that do not belong to me, I can do nothing.
It is the mount point itself that I am concerned about.
I don't want this thread to be about KDE. It is about trying to make systemd automount work as I need.
From there on, please do check your man pages, as there is a chain of events, and you get to the udisku2 rule for dealing with that. udisks & udisks-daemon
There are two point here. The first, as I've said before is that a symlink from, say, /home/roger/USB to /run/media/roger/ is going to be useful in this case where the USB stick is automated there upon insertion. The second is about 'why it is dynamically mounted there?' Well, I insert a a usebstick with a ResiserFS backup of ~anton/ on it and it gets moutned # mount | grep sdb1 # mount | grep sdb1 /dev/sdb1 on /run/media/anton/ab669d53-2101-4353-ba5c-908a380e4cd6 type reiserfs (rw,nosuid,nodev,relatime,uhelper=udisks2) /dev/sdb1 on /var/run/media/anton/ab669d53-2101-4353-ba5c-908a380e4cd6 type reiserfs (rw,nosuid,nodev,relatime) Well that tells me something: uhelper=udisks2 But it is also present at /dev/disk/by-uuid/ab669d53-2101-4353-ba5c-908a380e4cd6 -> ../../sdb1 But what about that "uhelper=udisks2"? That tells me that it is a udisk2 rule based operation. I see in the logs that the insertion causes a kernel event trigger and that cascades -- well check your own logs for this as its a bit long winded to post here - and hands it to udisk2. The relevant line is: 2018-03-01T10:58:37.113152-05:00 main kernel: [13822.668328] usb 3-4: New USB device found, idVendor=05dc, idProduct=c75c What matters is that it gets handled by /lib/udev/rules.d/80-udisks2.rules: SUBSYSTEMS=="usb", ENV{ID_VENDOR_ID}=="05dc",ENV{ID_MODEL_ID}=="b049", ENV{ID_INSTANCE}=="0:1", ENV{ID_DRIVE_FLASH_SD}="1" polkit & polkitd And I find that KDE4 is quite consistent in all this as a top level UI since it is not KDE that is actually handling it :-) All KDE does is see the signal and let you start a browser - or not. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
Any ideas on how to sort out permissions when systemd is managing autofs? I have googled, but all seems to discuss when you set up autofs yourself. I can do that. But we are trying to make this less complicated for the people who are managing the systems.
Just to straighten out one thing - they are really two different systems. There is autofs and there is the systemd equivalent. I believe the latter is not quite as advanced as autofs, but that's probably irrelevant in this context. They basically lead to the same thing - automatic execution of 'mount' or 'umount'.
The problem is the top-level mount point. I do not seem to have any control over the permissions. So if a user inserts a disk, they cannot make any files in the top level of the disk.
Maybe a drawing would make this more visible? Which disks are your users inserting/removing? usb, sata hotplug?
But that is what I need. When we were not using automount, the mount point's permissions were whatever the disk file had. They were not changed by the mount command. Autofs sets the permissions to rwx------.
You should be able to see the exact mount command that is being issued, maybe with some debug option for systemd? -- Per Jessen, Zürich (-2.9°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 28 Feb 2018 16:01:08 +0100 Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
We really want to use autofs. If the disks are not inserted and they are in /etc/fstab, the system will not boot. Autofs solves this nicely.
That's the default behaviour, but as ever, there are options ... Add nofail to the mount instructions for that disk/filesystem and the system will boot. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 28 Feb 2018 16:01:08 +0100 Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
I am trying to use x-systemd.automount,noauto in /etc/fstab to set up automount of disks. For the most part it works fine. I am struggling with permissions.
[snip]
The problem is the top-level mount point. I do not seem to have any control over the permissions.
According to https://www.freedesktop.org/software/systemd/man/systemd.automount.html you do. It seems the option is called DirectoryMode. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Feb 28, 2018 at 4:58 PM, Dave Howorth <dave@howorth.org.uk> wrote:
On Wed, 28 Feb 2018 16:01:08 +0100 Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
I am trying to use x-systemd.automount,noauto in /etc/fstab to set up automount of disks. For the most part it works fine. I am struggling with permissions.
[snip]
The problem is the top-level mount point. I do not seem to have any control over the permissions.
According to https://www.freedesktop.org/software/systemd/man/systemd.automount.html you do. It seems the option is called DirectoryMode.
This is the type of thing I was looking for. But I think it is not all as one expects. The systemd mount options for /etc/fstab are described in the man page for systemd.mount. Unfortunately, the DirectoryMode option is not recognized in /etc/fstab. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Wed, Feb 28, 2018 at 4:58 PM, Dave Howorth <dave@howorth.org.uk> wrote:
On Wed, 28 Feb 2018 16:01:08 +0100 Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
I am trying to use x-systemd.automount,noauto in /etc/fstab to set up automount of disks. For the most part it works fine. I am struggling with permissions.
[snip]
The problem is the top-level mount point. I do not seem to have any control over the permissions.
According to
https://www.freedesktop.org/software/systemd/man/systemd.automount.html
you do. It seems the option is called DirectoryMode.
This is the type of thing I was looking for. But I think it is not all as one expects.
The systemd mount options for /etc/fstab are described in the man page for systemd.mount. Unfortunately, the DirectoryMode option is not recognized in /etc/fstab.
It isn't a fstab option, it goes in a systemd unit file. -- Per Jessen, Zürich (-5.3°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Roger Oberholtzer wrote:
On Wed, Feb 28, 2018 at 4:58 PM, Dave Howorth <dave@howorth.org.uk> wrote:
On Wed, 28 Feb 2018 16:01:08 +0100 Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
I am trying to use x-systemd.automount,noauto in /etc/fstab to set up automount of disks. For the most part it works fine. I am struggling with permissions.
[snip]
The problem is the top-level mount point. I do not seem to have any control over the permissions.
According to
https://www.freedesktop.org/software/systemd/man/systemd.automount.html
you do. It seems the option is called DirectoryMode.
This is the type of thing I was looking for. But I think it is not all as one expects.
The systemd mount options for /etc/fstab are described in the man page for systemd.mount. Unfortunately, the DirectoryMode option is not recognized in /etc/fstab.
It isn't a fstab option, it goes in a systemd unit file.
The mount unit is auto-generated, but you can (presumably) still override it with a drop-in config. If you have a mount unit called "ober-holtzer.mount" for mounting something on "/ober/holtzer", you create ober-holtzer.mount.d/override.conf : [automount] directorymode=1234 (loosely from memory, I might have missed something) -- Per Jessen, Zürich (-5.3°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 1, 2018 at 8:34 AM, Per Jessen <per@computer.org> wrote:
The mount unit is auto-generated, but you can (presumably) still override it with a drop-in config.
If you have a mount unit called "ober-holtzer.mount" for mounting something on "/ober/holtzer", you create ober-holtzer.mount.d/override.conf :
[automount] directorymode=1234
(loosely from memory, I might have missed something)
Where are these files stored? I have some autofs network drives mounted via this mechanism and I don't seem to find the directory. I don't see anything in /usr/lib/systemd. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
The base directory for ANY and ALL machine specific mods and additions to systemd configs SHOULD be /etc/systemd/system/ Yes, you could mod the original files under /usr/...., BUT that would be lost with the next update of these files via package management. Been there, done it, lost the mod, learned my lession. - Yamaban. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 1, 2018 at 9:16 AM, Yamaban <foerster@lisas.de> wrote:
The base directory for ANY and ALL machine specific mods and additions to systemd configs SHOULD be /etc/systemd/system/
I have a number of file systems automounted via systemd and /etc/fstab. I am looking for wherever systemd put the info on these, as I gather that is where the override would go. I don't see any references to these mounts in /etc/systemd/system/ -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 1 Mar 2018 09:21, Roger Oberholtzer wrote:
On Thu, Mar 1, 2018 at 9:16 AM, Yamaban wrote:
The base directory for ANY and ALL machine specific mods and additions to systemd configs SHOULD be /etc/systemd/system/
I have a number of file systems automounted via systemd and /etc/fstab. I am looking for wherever systemd put the info on these, as I gather that is where the override would go. I don't see any references to these mounts in /etc/systemd/system/
The "on the fly" generated configs from systemd reside somewhere under /run/systemd/... (, and /run is a tmpfs, that gets re-created every time the machine boots). BUT, they are generated based on the system files from /usr/.... AND the overrides from /etc/.... - Yamaban. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Thu, Mar 1, 2018 at 9:16 AM, Yamaban <foerster@lisas.de> wrote:
The base directory for ANY and ALL machine specific mods and additions to systemd configs SHOULD be /etc/systemd/system/
I have a number of file systems automounted via systemd and /etc/fstab. I am looking for wherever systemd put the info on these, as I gather that is where the override would go. I don't see any references to these mounts in /etc/systemd/system/
systemctl | grep mount followed by systemctl cat <mount-unit> Auto-generated stuff is probably in /run/systemd/generator somewhere. AFAIK, you still override from /etc/systemd/system/. -- Per Jessen, Zürich (-5.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Uh, saw this subthread too late... Roger Oberholtzer wrote:
On Thu, Mar 1, 2018 at 9:16 AM, Yamaban <foerster@lisas.de> wrote:
The base directory for ANY and ALL machine specific mods and additions to systemd configs SHOULD be /etc/systemd/system/
I have a number of file systems automounted via systemd and /etc/fstab. I am looking for wherever systemd put the info on these, as I gather that is where the override would go. I don't see any references to these mounts in /etc/systemd/system/
You'll need both an .automount and a .mount unit file. One (existing) example would be (at least on my TW) /usr/lib/systemd/system/proc-sys-fs-binfmt_misc.automount /usr/lib/systemd/system/proc-sys-fs-binfmt_misc.mount So you'd have to write them, place them in /etc/systemd/system and enable them in the respective runlevels.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 1, 2018 at 9:36 AM, Peter Suetterlin <pit@astro.su.se> wrote:
Uh, saw this subthread too late... Roger Oberholtzer wrote:
On Thu, Mar 1, 2018 at 9:16 AM, Yamaban <foerster@lisas.de> wrote:
The base directory for ANY and ALL machine specific mods and additions to systemd configs SHOULD be /etc/systemd/system/
I have a number of file systems automounted via systemd and /etc/fstab. I am looking for wherever systemd put the info on these, as I gather that is where the override would go. I don't see any references to these mounts in /etc/systemd/system/
You'll need both an .automount and a .mount unit file. One (existing) example would be (at least on my TW)
These exist. For example (CIFS systemd automount via /etc/fstab): -rw-r--r-- 1 root root 226 Mar 1 09:35 media-mma\x2dsql\x2d1-data1.automount # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8) Before=remote-fs.target [Automount] Where=/media/mma-sql-1/data1 TimeoutIdleSec=1min -rw-r--r-- 1 root root 410 Mar 1 09:35 media-mma\x2dsql\x2d1-data1.mount # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8) [Mount] What=//serammmarst01-a.ramse.ramboll-group.global.network/data1 Where=/media/mma-sql-1/data1 Type=cifs Options=soft,credentials=/etc/cifs.creds.ramse,workgroup=RAMBOLL,sec=ntlm,vers=3.02,rw,noauto,x-systemd.automount,x-systemd.idle-timeout=60,nofail,uid=roger I would expect that the DirectoryMode option should be in the .automount file. But I guess it should go in an override file. And that is what I am trying to figure out. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
These exist. For example (CIFS systemd automount via /etc/fstab):
-rw-r--r-- 1 root root 226 Mar 1 09:35 media-mma\x2dsql\x2d1-data1.automount
# Automatically generated by systemd-fstab-generator
[Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8) Before=remote-fs.target
[Automount] Where=/media/mma-sql-1/data1 TimeoutIdleSec=1min
[snip] I would expect that the DirectoryMode option should be in the .automount file. But I guess it should go in an override file. And that is what I am trying to figure out.
For that one, I would suggest: /etc/systemd/system/media-mma\x2dsql\x2d1-data1.automount.d/override.conf I was not aware of the .automount units, I use the oldfashioned autofs :-) -- Per Jessen, Zürich (-5.5°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 1, 2018 at 10:07 AM, Per Jessen <per@computer.org> wrote:
For that one, I would suggest:
/etc/systemd/system/media-mma\x2dsql\x2d1-data1.automount.d/override.conf
I was not aware of the .automount units, I use the oldfashioned autofs :-)
For the most part if works great. I see that the /run/systemd/generator directory is deleted and made new each time systemd starts (including a daemon-reload). So the override information would go away. Perhaps there is a place where these can be placed that is more permanent? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Thu, Mar 1, 2018 at 10:07 AM, Per Jessen <per@computer.org> wrote:
For that one, I would suggest:
/etc/systemd/system/media-mma\x2dsql\x2d1-data1.automount.d/override.conf
I was not aware of the .automount units, I use the oldfashioned autofs :-)
For the most part if works great.
I see that the /run/systemd/generator directory is deleted and made new each time systemd starts (including a daemon-reload). So the override information would go away. Perhaps there is a place where these can be placed that is more permanent?
/etc/systemd/system/ Afaik, the override info is taken into account by the auto-generator. -- Per Jessen, Zürich (-5.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 1, 2018 at 10:07 AM, Per Jessen <per@computer.org> wrote:
Roger Oberholtzer wrote:
These exist. For example (CIFS systemd automount via /etc/fstab):
-rw-r--r-- 1 root root 226 Mar 1 09:35 media-mma\x2dsql\x2d1-data1.automount
# Automatically generated by systemd-fstab-generator
[Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8) Before=remote-fs.target
[Automount] Where=/media/mma-sql-1/data1 TimeoutIdleSec=1min
[snip] I would expect that the DirectoryMode option should be in the .automount file. But I guess it should go in an override file. And that is what I am trying to figure out.
For that one, I would suggest:
/etc/systemd/system/media-mma\x2dsql\x2d1-data1.automount.d/override.conf
I was not aware of the .automount units, I use the oldfashioned autofs :-)
-- Per Jessen, Zürich (-5.5°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I have made the override file, and I see that it is being used. "systemctl cat backup.automount" reports: # /run/systemd/generator/backup.automount # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8) Before=local-fs.target [Automount] Where=/backup TimeoutIdleSec=1min # /etc/systemd/system/backup.automount.d/override.conf [Automount] DirectoryMode=0777 Nonetheless, the directory has 0700 for permissions after the mount. It looks like DirectoryMode is not used. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
I have made the override file, and I see that it is being used.
:D
# /etc/systemd/system/backup.automount.d/override.conf [Automount] DirectoryMode=0777
Nonetheless, the directory has 0700 for permissions after the mount. It looks like DirectoryMode is not used.
Hmm, the manpage indeed only says that the mode is used if mountpoint directories are created. And that the default is 755. That one you do not see either. And IMHO this is because this is what the permission on the filesystem of the disk is. I'd really like to see you mounting this disk anywhere, and getting a 777 permission and/or different UID as owner. Can't you just set the proper permission of those disk when creating the FS? I don't assume your users are doing this? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 1, 2018 at 3:43 PM, Peter Suetterlin <pit@astro.su.se> wrote:
Roger Oberholtzer wrote:
I have made the override file, and I see that it is being used.
:D
# /etc/systemd/system/backup.automount.d/override.conf [Automount] DirectoryMode=0777
Nonetheless, the directory has 0700 for permissions after the mount. It looks like DirectoryMode is not used.
Hmm, the manpage indeed only says that the mode is used if mountpoint directories are created. And that the default is 755. That one you do not see either. And IMHO this is because this is what the permission on the filesystem of the disk is.
I just tried this when the mount point does not exist. The mount directory is not created. It has to already exist. When I do 'cd /backup', I get this error: 'cd: /backup: No such file or directory'. Normally, 'cd /backup' causes it to be mounted. I suspect here is a way systemd sets things up differently that when one configures automount directly.
I'd really like to see you mounting this disk anywhere, and getting a 777 permission and/or different UID as owner.
Can't you just set the proper permission of those disk when creating the FS? I don't assume your users are doing this?
I'll bite. If you create a new partition (ext4), how do you set the permissions in the disk itself for the top directory? That is, so the permissions of the mount point come from the disk and not the directory on which it is mounted? I tried this while /backup was mounted: cd /backup chmod 0755 . After a remount, the permissions are what the directory on which it was mounted had. Not 0755. Something is missing somewhere...
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Thu, Mar 1, 2018 at 3:43 PM, Peter Suetterlin <pit@astro.su.se> wrote:
Roger Oberholtzer wrote:
I have made the override file, and I see that it is being used.
:D
# /etc/systemd/system/backup.automount.d/override.conf [Automount] DirectoryMode=0777
Nonetheless, the directory has 0700 for permissions after the mount. It looks like DirectoryMode is not used.
Hmm, the manpage indeed only says that the mode is used if mountpoint directories are created. And that the default is 755. That one you do not see either. And IMHO this is because this is what the permission on the filesystem of the disk is.
I just tried this when the mount point does not exist. The mount directory is not created. It has to already exist. When I do 'cd /backup', I get this error: 'cd: /backup: No such file or directory'. Normally, 'cd /backup' causes it to be mounted.
Not sure - the manpage states Where= Takes an absolute path of a directory of the automount point. If the automount point does not exist at time that the automount point is installed, it is created. That is, you might have to reload or even re-exec systemd to get it created.
I'll bite. If you create a new partition (ext4), how do you set the permissions in the disk itself for the top directory?
By mounting it, and changing it....
That is, so the permissions of the mount point come from the disk and not the directory on which it is mounted?
I'm not able to reproduce your result with the freshly formated ext4. I always get the permissions from the FS on the disk. What is your umask when formating? I created a 2GB file, made an ext4 on it (no further options), did 'chmod 777 /mnt' and mounted it there: gate:~ # mount image /mnt gate:~ # ls -ld /mnt drwxr-xr-x 3 root root 4096 Mar 1 16:05 /mnt gate:~ # umount /mnt gate:~ # ls -ld /mnt drwxrwxrwx 1 root root 0 May 10 2017 /mnt This is a 42.3 machine.
I tried this while /backup was mounted:
cd /backup chmod 0755 .
After a remount, the permissions are what the directory on which it was mounted had. Not 0755.
Something is missing somewhere...
To me it sounds like there is a separate script somewhere that does a mount-and-chmod. Maybe check the udev rules? No, rather not, that would likely be disk specific. Does 'systemctl list-units -t mount' list anything suspicious? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Thu, Mar 1, 2018 at 9:36 AM, Peter Suetterlin <pit@astro.su.se> wrote:
You'll need both an .automount and a .mount unit file. One (existing) example would be (at least on my TW)
These exist. For example (CIFS systemd automount via /etc/fstab):
-rw-r--r-- 1 root root 226 Mar 1 09:35 media-mma\x2dsql\x2d1-data1.automount
# Automatically generated by systemd-fstab-generator
.....
I would expect that the DirectoryMode option should be in the .automount file. But I guess it should go in an override file. And that is what I am trying to figure out.
Well, you do not need the fstab entry, you can as well only use those two files, and put them in /etc/systemd/system. But following the manpage, anything in there will override the other files. So you should be able to have both, the auto-generated and the /etc file, where the latter then can contain only additional settings. Without the fstab, it would have to contain all info (which might be preferable, as then everything is in one place...) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/03/18 03:01 AM, Roger Oberholtzer wrote:
On Thu, Mar 1, 2018 at 8:34 AM, Per Jessen <per@computer.org> wrote:
The mount unit is auto-generated, but you can (presumably) still override it with a drop-in config.
If you have a mount unit called "ober-holtzer.mount" for mounting something on "/ober/holtzer", you create ober-holtzer.mount.d/override.conf :
[automount] directorymode=1234
(loosely from memory, I might have missed something)
Where are these files stored? I have some autofs network drives mounted via this mechanism and I don't seem to find the directory. I don't see anything in /usr/lib/systemd.
He said that the mount init - well units actually - are autogenerated. They are autogenerated by /usr/lib/systemd/system-generators/systemd-fstab-generator and can be found in /run/systemd/generator/ Well actually the local-fs.target has a long list of requires from that generator, but the *.mount files are at the bottom of it. So you get, for example, from the entry in /etc/fstab for mounting a separate /tmp: # more /run/systemd/generator/local-fs.target.requires/tmp.mount # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8) Before=local-fs.target Requires=systemd-fsck@dev-disk-by\x2dlabel-TMP.service After=systemd-fsck@dev-disk-by\x2dlabel-TMP.service [Mount] What=/dev/disk/by-label/TMP Where=/tmp Type=ext4 Options=noexec,nosuid,nodev and # more /run/systemd/generator/tmp.mount # Automatically generated by systemd-fstab-generator [Unit] SourcePath=/etc/fstab Documentation=man:fstab(5) man:systemd-fstab-generator(8) Before=local-fs.target Requires=systemd-fsck@dev-disk-by\x2dlabel-TMP.service After=systemd-fsck@dev-disk-by\x2dlabel-TMP.service [Mount] What=/dev/disk/by-label/TMP Where=/tmp Type=ext4 Options=noexec,nosuid,nodev -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I really appreciate all the discussion. I can summarize. The task: - I want to automount a SATA disk in a hot swap removable drive bay. - The disk can be any format: ext4, vfat, ntfs - I would prefer to use the systemd automount facility where I place the needed information in /etc/hosts. - The actions are to be performed by a normal user without root permissions. The disk should be mounted as the result of something like: cd /backup - The user who mounted the disk should have write access to the top level directory. This is non-negotiable. Without this, the user needs root permissions to change the top level directory permissions. What does work: - systemd arranges for the disk to be automounted. - When the user access the disk mount point, the disk is mounted. - It is working for all file system types. The problem: - The directory on which the disk is mounted is not always writable by the user who initiated the mount. - Adding a DirectoryMode= to a systemd override file (it cannot be set in /etc/fstab) gets the option added to the automount unit file for this file system. However, the mount directory does not have these permissions when the disk is automounted. Status: I have been testing with ext4. It was said that if I mount the file system, change the permissions of the mount point (i.e., the top level directory), these permissions would be used on subsequent mounts. I do not see that this is happening. The file system top level permissions are not what I expect. This is on an up-to-date Leap 42.3 system. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
I have been testing with ext4. It was said that if I mount the file system, change the permissions of the mount point (i.e., the top level directory), these permissions would be used on subsequent mounts. I do not see that this is happening. The file system top level permissions are not what I expect.
This is on an up-to-date Leap 42.3 system.
I think the main issue is that noone here is able to reproduce your results when mounting. So something is different for you. Could you post the fstab entry you use, and maybe the override file? (BTW, I assume 'which mount' resolves to /usr/bin/mount from util-linux, yes?) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2018-03-02 at 07:53 +0100, Roger Oberholtzer wrote:
I really appreciate all the discussion. I can summarize.
The task:
- I want to automount a SATA disk in a hot swap removable drive bay.
- The disk can be any format: ext4, vfat, ntfs
- I would prefer to use the systemd automount facility where I place the needed information in /etc/hosts.
- The actions are to be performed by a normal user without root permissions. The disk should be mounted as the result of something like: cd /backup
- The user who mounted the disk should have write access to the top level directory. This is non-negotiable. Without this, the user needs root permissions to change the top level directory permissions.
It is simply impossible, except on vfat, ntfs, or exfat. This is non-negotiable. :-) In ext4, xfs, btrfs, etc, the permissions of the base directory are changed only by root with standard chmod/chown tools on the *mounted* filesystem. It is possible, though, that there is a formating tool, which runs as root, that changes the permissions to be accessible to the user that runs the desktop at that time who called the format tool using some su/sudo variant.
What does work:
- systemd arranges for the disk to be automounted.
- When the user access the disk mount point, the disk is mounted.
- It is working for all file system types.
The problem:
- The directory on which the disk is mounted is not always writable by the user who initiated the mount.
As documented.
- Adding a DirectoryMode= to a systemd override file (it cannot be set in /etc/fstab) gets the option added to the automount unit file for this file system. However, the mount directory does not have these permissions when the disk is automounted.
Of course not.
Status:
I have been testing with ext4. It was said that if I mount the file system, change the permissions of the mount point (i.e., the top level directory), these permissions would be used on subsequent mounts. I do not see that this is happening. The file system top level permissions are not what I expect.
We can not reproduce this. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqZPnUACgkQtTMYHG2NR9X4hQCfWyWy1ZtoqxhuuaopUBR0P4mN tcAAnA+zdatvjt9uje+6b+d4976VFHtL =/yub -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Mar 2, 2018 at 1:07 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday, 2018-03-02 at 07:53 +0100, Roger Oberholtzer wrote:
I really appreciate all the discussion. I can summarize.
The task:
- I want to automount a SATA disk in a hot swap removable drive bay.
- The disk can be any format: ext4, vfat, ntfs
- I would prefer to use the systemd automount facility where I place the needed information in /etc/hosts.
- The actions are to be performed by a normal user without root permissions. The disk should be mounted as the result of something like: cd /backup
- The user who mounted the disk should have write access to the top level directory. This is non-negotiable. Without this, the user needs root permissions to change the top level directory permissions.
It is simply impossible, except on vfat, ntfs, or exfat. This is non-negotiable. :-)
Never say never! And recall that I do not want this for existing files or directories. It is only for the top level directory for things that do not exist there yet. I think I will try the suggestion in answer 21 described on https://askubuntu.com/questions/25071/how-to-run-a-script-when-a-specific-fl... I'm just waiting to get access to a system. Probably on Monday. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 2 Mar 2018 15:49:48 +0100 Roger Oberholtzer wrote:
On Fri, Mar 2, 2018 at 1:07 PM, Carlos E. R. wrote:
On Friday, 2018-03-02 at 07:53 +0100, Roger Oberholtzer wrote:
I really appreciate all the discussion. I can summarize.
The task:
- I want to automount a SATA disk in a hot swap removable drive bay.
- The disk can be any format: ext4, vfat, ntfs
- I would prefer to use the systemd automount facility where I place the needed information in /etc/hosts.
- The actions are to be performed by a normal user without root permissions. The disk should be mounted as the result of something like: cd /backup
- The user who mounted the disk should have write access to the top level directory. This is non-negotiable. Without this, the user needs root permissions to change the top level directory permissions.
It is simply impossible, except on vfat, ntfs, or exfat. This is non-negotiable. :-)
Never say never! And recall that I do not want this for existing files or directories. It is only for the top level directory for things that do not exist there yet.
I don't see a problem with this. As long as the directory above the mount point has rwxrwxrwx, and the root of the mounted filesystem is also rwxrwxrwx then anybody should be able to create anything in the root of the mounted filesystem. Both those modes can be set in the usual way by root using chmod whilst the filesystem is mounted for the first time.
I think I will try the suggestion in answer 21 described on https://askubuntu.com/questions/25071/how-to-run-a-script-when-a-specific-fl...
I'm just waiting to get access to a system. Probably on Monday.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2018-03-02 at 15:49 +0100, Roger Oberholtzer wrote:
On Fri, Mar 2, 2018 at 1:07 PM, Carlos E. R. <> wrote:
On Friday, 2018-03-02 at 07:53 +0100, Roger Oberholtzer wrote:
I really appreciate all the discussion. I can summarize.
The task:
- I want to automount a SATA disk in a hot swap removable drive bay.
- The disk can be any format: ext4, vfat, ntfs
- I would prefer to use the systemd automount facility where I place the needed information in /etc/hosts.
- The actions are to be performed by a normal user without root permissions. The disk should be mounted as the result of something like: cd /backup
- The user who mounted the disk should have write access to the top level directory. This is non-negotiable. Without this, the user needs root permissions to change the top level directory permissions.
It is simply impossible, except on vfat, ntfs, or exfat. This is non-negotiable. :-)
Never say never! And recall that I do not want this for existing files or directories. It is only for the top level directory for things that do not exist there yet.
I think I will try the suggestion in answer 21 described on https://askubuntu.com/questions/25071/how-to-run-a-script-when-a-specific-fl...
I'm just waiting to get access to a system. Probably on Monday.
Running a script to run chmod/chown on mount is the way to go. But it is not mounting with the permisions of the user that mounts, which is your question. But another is placing those users on the backup group and giving that group write access. You only do that once per backup disk. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqZoc4ACgkQtTMYHG2NR9VavgCeJETzRoWpDC8oOGbjL77J+oLF rhIAnjjj8rJ6VMFXLrnmwdmjOwreU/4N =aZ6T -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Mar 2, 2018 at 8:11 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
Running a script to run chmod/chown on mount is the way to go. But it is not mounting with the permisions of the user that mounts, which is your question.
Agreed. That is what I would really like. I don't see how to do this. So I will have to settle for more permissive permissions.
But another is placing those users on the backup group and giving that group write access. You only do that once per backup disk.
A group is perhaps a good idea. These systems only have one user (who is never root). But at least with a group the intentions are more clear. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2018-03-04 at 10:53 +0100, Roger Oberholtzer wrote:
On Fri, Mar 2, 2018 at 8:11 PM, Carlos E. R. <> wrote:
Running a script to run chmod/chown on mount is the way to go. But it is not mounting with the permisions of the user that mounts, which is your question.
Agreed. That is what I would really like. I don't see how to do this. So I will have to settle for more permissive permissions.
The link you posted contains instructions for that, did you try?
But another is placing those users on the backup group and giving that group write access. You only do that once per backup disk.
A group is perhaps a good idea. These systems only have one user (who is never root). But at least with a group the intentions are more clear.
I think that it would be easy to do. And you can use that group to give access on the hard disk to the files to backup (acls, perhaps). - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqb9DgACgkQtTMYHG2NR9WNfwCfRn0SyDoQiJC6I47wLPUNi25m I0gAnitEnMh1MrSXtj8931ezI+B31Cvg =KQ48 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Mar 4, 2018 at 2:27 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
The link you posted contains instructions for that, did you try?
I did not see anything that knew who caused the disk to be mounted. Just that it had been mounted. The udisk example was a user script, but it ran as that user. So it could not change permissions. Did I miss something? I will be trying the systemd thing today when I get access to a system. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I made a file called /etc/systemd/system/backup.service that contains this: [Unit] Description=RST backup disk setup Requires=backup.mount After=backup.mount [Service] Type=oneshot ExecStart=/usr/bin/chown rst:users /backup ; /usr/bin/chmod 0755 /backup [Install] WantedBy=backup.mount Then I ran systemctl enable backup.service Now when I do a mount, the mount point belongs to rst:users, and the permissions are 0775. These may change. But I see that I can now manipulate these properties! Perhaps not a 100% solution in that it would be great if it know who caused the automount. But it gets done what I need to get done. On Mon, Mar 5, 2018 at 7:54 AM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Sun, Mar 4, 2018 at 2:27 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
The link you posted contains instructions for that, did you try?
I did not see anything that knew who caused the disk to be mounted. Just that it had been mounted. The udisk example was a user script, but it ran as that user. So it could not change permissions. Did I miss something?
I will be trying the systemd thing today when I get access to a system.
-- Roger Oberholtzer
-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 28/02/18 10:01 AM, Roger Oberholtzer wrote:
Any ideas on how to sort out permissions when systemd is managing autofs? I have googled, but all seems to discuss when you set up autofs yourself. I can do that. But we are trying to make this less complicated for the people who are managing the systems.
This might be part of a solution. Back in my NFS days I had ~/Documents symlinked to /mnt/NFS/anton/Documents and that was set to be a NFS mount on demand Now I have ~anton/USB symlinked to /var/run/media/anton/ When I put a USB stick in my front panel KDE mounts it and it appears under ~anton/USB I know this isn't mount-on-demand :-) Maybe I'm a dinosaur, but I'm conformable with 'autofs' to my mount-on-demand and it can work with both remote (NAS, NFS) and local file systems. Perhaps you need to use this to achieve what you want rather than the systemd automount? I say this as a systemd advocate. https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.ref... you should also look at pam_mount which offers a different set of capabilities including user configurable mounting: · Users can define their own list of volumes without having to change (possibly non-writable) global config files. The module also supports mounting local filesystems of any kind the normal mount utility supports, with extra code to make sure certain volumes are set up properly because often they need more than just a mount call, such as encrypted volumes. This includes SMB/CIFS, FUSE, dm-crypt and LUKS. Individual users may define additional volumes to mount if allowed by pam_mount.conf.xml (usually ~/.pam_mount.conf.xml). The volume keyword is the only valid keyword in these per-user configuration files. If the luserconf parameter is set in pam_mount.conf.xml, allowing user-defined volume, then users may mount and unmount any volume they own at any mount point they own. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
I am trying to use x-systemd.automount,noauto in /etc/fstab to set up automount of disks. For the most part it works fine. I am struggling with permissions.
When the disk is, say, CIFS, I can add uid=roger to /etc/fstab and the files will belong to roger. This is because the file system itself does not have user ownership of individual files. Or at least the CISF driver makes it so.
Correct. Same is true for other filesystems that don't have such a uid/gid structure.
If I want this to work with ext4, this seems not to work as I would like.
No, because you cannot overrule the setting of an ext4 (or btrfs or....) filesystem when mounting it.
The problem is the top-level mount point. I do not seem to have any control over the permissions. So if a user inserts a disk, they cannot make any files in the top level of the disk. But that is what I need. When we were not using automount, the mount point's permissions were whatever the disk file had. They were not changed by the mount command. Autofs sets the permissions to rwx------.
This is likely *not* autofs, but the systemd implementation of automounting. Autofs leaves the TLD as it is defined on the disk. So you'd have to hunt for permission settings of the systemd automount. And/or maybe some tmpfiles magic?
We really want to use autofs. If the disks are not inserted and they are in /etc/fstab, the system will not boot. Autofs solves this nicely.
I assume you do not use kde device mounter? That one does honor fstab, too. E.g., for my sdcard reader I have /dev/mmcblk0p1 /media/sdcard auto noauto,user,shortname=lower,uid=1000 0 0 in my /etc/fstab. Clicking on the KDE device notifier 'mount' button will mount it on /media/sdcard, not the default /run/media/<user>/uuid. Though this probably doesn't help in your case. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Feb 28, 2018 at 6:57 PM, Peter Suetterlin <pit@astro.su.se> wrote:
No, because you cannot overrule the setting of an ext4 (or btrfs or....) filesystem when mounting it.
Inside the file system we cannot override. But the permissions of the mount point directory itself - which are NOT in the mounted file system but are in the file system on which the drive is mounted - does control what can be done in the top level of the mount point. And that is what I am after. When we used /etc/fstab to mount directly, the directory on which the disk was mounted had to exist in advance, and we controlled the permissions of that directory when we created it. The mount via /etc/fstab did not change those permissions. When systemd is setting up /etc/fstab entries to be handled by autofs, we seem to have lost control over the permission of the mount directory. This is a show stopper. Unless we created a directory on the disk (where we control the directory permissions) and everything had to happen in that sub-directory. But this seems ridiculous.
This is likely *not* autofs, but the systemd implementation of automounting. Autofs leaves the TLD as it is defined on the disk.
systemd uses autofs. It just sets up the autofs files based on /etc/fstab and various files scattered all over the place in a sloppy fashion. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Wed, Feb 28, 2018 at 6:57 PM, Peter Suetterlin <pit@astro.su.se> wrote:
No, because you cannot overrule the setting of an ext4 (or btrfs or....) filesystem when mounting it.
Inside the file system we cannot override. But the permissions of the mount point directory itself - which are NOT in the mounted file system but are in the file system on which the drive is mounted - does control what can be done in the top level of the mount point. And that is what I am after. When we used /etc/fstab to mount directly, the directory on which the disk was mounted had to exist in advance, and we controlled the permissions of that directory when we created it.
This is strange, because it didn't work for me either, (also) the TLD permissions of a mounted disk had always been overwriting the permissions of the mount point directory.
The mount via /etc/fstab did not change those permissions. When systemd is setting up /etc/fstab entries to be handled by autofs, we seem to have lost control over the permission of the mount directory.
See the other reply (Andrei?), and man systemd.automount, DirectoryMode should be able to do this. Haven't tried though...
This is a show stopper. Unless we created a directory on the disk (where we control the directory permissions) and everything had to happen in that sub-directory. But this seems ridiculous.
To me it seems more logical to have the TLD protected, but I'm sure you now what you want (and why) :)
This is likely *not* autofs, but the systemd implementation of automounting. Autofs leaves the TLD as it is defined on the disk.
systemd uses autofs.
It's at least not mentioning it in the manpage, which mentions "...about a file system automount point controlled and supervised by systemd" Is really the automount daemon running? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 1, 2018 at 10:34 AM, Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Wed, Feb 28, 2018 at 6:57 PM, Peter Suetterlin <pit@astro.su.se> wrote:
No, because you cannot overrule the setting of an ext4 (or btrfs or....) filesystem when mounting it.
Inside the file system we cannot override. But the permissions of the mount point directory itself - which are NOT in the mounted file system but are in the file system on which the drive is mounted - does control what can be done in the top level of the mount point.
No, they do not - at least after something was mounted on top of mount point. All this thread is about permissions on *mounted* filesystem. If your problem is permissions *before* it is mounted over - then please show them. But then it would also not work as you wish with FAT and you said yourself that FAT works correctly. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 1 Mar 2018 08:34:31 +0100 Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Wed, Feb 28, 2018 at 6:57 PM, Peter Suetterlin <pit@astro.su.se> wrote:
No, because you cannot overrule the setting of an ext4 (or btrfs or....) filesystem when mounting it.
Inside the file system we cannot override. But the permissions of the mount point directory itself - which are NOT in the mounted file system but are in the file system on which the drive is mounted - does control what can be done in the top level of the mount point.
I don't think so. I regularly set the permissions of the mount point to dr-x------ so that NOBODY has write permission to the directory and therefore cannot accidentally write data onto the parent disk before the real filesystem is mounted. After the filesystem is mounted it has whatever permissions were set for that filesystem, and root can change them in the normal way. Note, this is not a crippled fat filesystem with no user permissions, nor does it happen to be ext4, if that matters. But I would be very surprised if ext4 behaved differently. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 28 Feb 2018 16:01:08 +0100, Roger Oberholtzer wrote:
I am trying to use x-systemd.automount,noauto in /etc/fstab to set up automount of disks. For the most part it works fine. I am struggling with permissions.
When the disk is, say, CIFS, I can add uid=roger to /etc/fstab and the files will belong to roger. This is because the file system itself does not have user ownership of individual files. Or at least the CISF driver makes it so.
If I want this to work with ext4, this seems not to work as I would like.
The problem is the top-level mount point. I do not seem to have any control over the permissions. So if a user inserts a disk, they cannot make any files in the top level of the disk. But that is what I need. When we were not using automount, the mount point's permissions were whatever the disk file had. They were not changed by the mount command. Autofs sets the permissions to rwx------.
We really want to use autofs. If the disks are not inserted and they are in /etc/fstab, the system will not boot. Autofs solves this nicely.
This is not an answer to the question, but in /etc/fstab you can add noauto option to mount options. In this case the system will boot even if the drives are not present. You can mount the drives then manually. I have lines like this in my fstab: /dev/md6 /mnt/p6 ext3 noauto,users,defaults 1 2 Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
Andrei Borzenkov
-
Anton Aylward
-
Carlos E. R.
-
Dave Howorth
-
Istvan Gabor
-
Per Jessen
-
Peter Suetterlin
-
Roger Oberholtzer
-
Yamaban