Solved Permission denied on newly created fs not in fstab.

[smithi]

Setting posix ACLs is mostly used for fine grained permission control, i personally avoid to complicate things even further it there is no real need for it.

Aye.

Just use good old chown -R user:group /mnt/flash for example. One ufs partition on HDD/Flash used for data, simple use case, simple solution.

Agreed, this has become so over-complicated, so far to no avail.

Adding a new directory in / (done as root, as should be obvious) that's for mounting specifically this disk is a solid, simple solution.

 

[smithi]

drwxr-xr-x 7 root wheel 512 Jun 2 00:58

That's missing a name.

gpart: No such geom:

What, with the disk connected? Very weird.

You said at the start that you followed chapter 19 of the handbook, but that clearly shows a) to partition the disk using gpart and b) to set sysctl vfs.usermount=1 so non-root users can mount disks on directories they own.

Furthur, you said "Also, all commands in guide were entered as my user not as root."

Which is not possible; you cannot use gpart in create mode, run newfs nor set sysctls except as root.

You should stick to that handbook section, it's good, here relevant 19.2 and 19.4

You should partition the disk, either as da0p1 (GPT) - or as da0s1 (MBR), your choice - but 'dangerously dedicated' mode is, well, just that.

And you should quit trying whatever anyone (including me!) tells you to try unless you know their advice and experience is useful in FreeBSD, not Linux.

cheers, Ian

 

[LibreQuest]

Copy that, I have many years in Linux. I'm very new to FreeBSD. So, I will start over again with the handbook section 19 on this disk. It's just one disk at the moment. But I do need to get it right so that I can do the same work on the other many disks that I have.

 

[T-Daemon]

Setting posix ACLs is mostly used for fine grained permission control, i personally avoid to complicate things even further it there is no real need for it.

Aye.

Why do you consider using ACLs as complicating things? On the contrary, it's easing things.

Without ACLs:

# sudo mount /dev/da0 /mnt

Only root can write to /mnt, users can not. Grant group wheel members write permission on mount point.

# sudo chmod 775 /mnt

Copy files as user, member of group wheel, to /mnt.

Repeat every time after mounting external disk!

With ACLs enabled and set giving wheel group write permission on directory (here the mount point of the external drive):

# sudo mount /dev/da0 /mnt

Copy files as user, member of group wheel, to /mnt. Once set, ACLs on the mount point directory are retained after unmounting and remounting the external drive, even if the drive is mounted to a different directory (maybe you guys missed that point).

Just use good old chown -R user:group /mnt/flash for example. One ufs partition on HDD/Flash used for data, simple use case, simple solution.

Agreed, this has become so over-complicated, so far to no avail.

You mean

# sudo mount /dev/da0 /mnt
# sudo cp <files> /mnt
# sudo chown -R user:group /mnt

repeat every time the external disk is mounted is less complicated than setting ACLs once, which are persistent until changed?

As for vfs.usermount=1, FreeBSD handbook 19.4.1. Device Configuration

...
Warning

Allowing untrusted users to mount arbitrary media, by enabling vfs.usermount as described below, should not be considered safe from a security point of view. Most file systems were not built to safeguard against malicious devices.

But everyone should use the method they feel comfortable with.

 

[T-Daemon]

ACL doesn't work either...

chown to my user on the mount dir doesn't work either.

Please give exact commands you are using.

 

[smithi]

Why do you consider using ACLs as complicating things? On the contrary, it's easing things.

Without ACLs:

# sudo mount /dev/da0 /mnt

Only root can write to /mnt, users can not. Grant group wheel members write permission on mount point.

# sudo chmod 775 /mnt

Copy files as user, member of group wheel, to /mnt.

Repeat every time after mounting external disk!

Who was suggesting that? We were talking about using a separate mountpoint dir, owned permanently by a given user:group.

That could be, say, /mnt/$username (chown'd once) or a distinct directory, say /dir4purpose (chown"d once) or a directory in the user's tree.

With ACLs enabled and set giving wheel group write permission on directory (here the mount point of the external drive):

# sudo mount /dev/da0 /mnt

Copy files as user, member of group wheel, to /mnt. Once set, ACLs on the mount point directory are retained after unmounting and remounting the external drive, even if the drive is mounted to a different directory (maybe you guys missed that point).

I think we're dealing with skill levels below ACLs, when far simpler solutions are at hand and already documented in the reference handbook.

I'm not suggesting there's a problem with your method, once you understand what's going on at that level.

You mean

# sudo mount /dev/da0 /mnt
# sudo cp <files> /mnt
# sudo chown -R user:group /mnt

repeat every time the external disk is mounted is less complicated than setting ACLs once, which are persistent until changed?

No, I didn't mean anything vaguely like that.

As for vfs.usermount=1, FreeBSD handbook 19.4.1. Device Configuration

"Allowing untrusted users to mount arbitrary media, by enabling vfs.usermount as described below, should not be considered safe from a security point of view."

That's for servers, or at least systems having untrusted users.

LibreQuest will correct me if I'm wrong, but I believe this is a one-user system, or at least only trusted users, in which case vfs.usermount=1 is entirely appropriate.

But everyone should use the method they feel comfortable with.

Of course. I went back to the beginning of thread and noticed problems and mixed advice and am trying to help.

As are you, I'm sure. Let's see what happens next ...

 

[LibreQuest]

Please give exact commands you are using.

I was using the exact commands recommended here in the thread a dozen comments above this.

 

[LibreQuest]

Who was suggesting that? We were talking about using a separate mountpoint dir, owned permanently by a given user:group.

That could be, say, /mnt/$username (chown'd once) or a distinct directory, say /dir4purpose (chown"d once) or a directory in the user's tree.



I think we're dealing with skill levels below ACLs, when far simpler solutions are at hand and already documented in the reference handbook.

I'm not suggesting there's a problem with your method, once you understand what's going on at that level.



No, I didn't mean anything vaguely like that.



"Allowing untrusted users to mount arbitrary media, by enabling vfs.usermount as described below, should not be considered safe from a security point of view."

That's for servers, or at least systems having untrusted users.

LibreQuest will correct me if I'm wrong, but I believe this is a one-user system, or at least only trusted users, in which case vfs.usermount=1 is entirely appropriate.



Of course. I went back to the beginning of thread and noticed problems and mixed advice and am trying to help.

As are you, I'm sure. Let's see what happens next ...

You are correct. This is my private lan. Um, automount works for all the other disks I didn't create a FreeBSD ufs for. Hmm. I'm going to start over again on this disk like I said. I haven't had time to do so yet.

 

[smithi]

You are correct. This is my private lan. Um, automount works for all the other disks I didn't create a FreeBSD ufs for. Hmm. I'm going to start over again on this disk like I said. I haven't had time to do so yet.

Fair enough. Be sure to partition the disk with gpart this time, also newfs; I didn't see you mention that.

In fact if you just followed section 19.2 verbatim, with da0 rather than ada1, you'd be done except one chown.

 

[LibreQuest]

I followed it until mount. But didn't read past it. So the fs etc etc is done on the disk. I've copied data to and from and moved to other machines. I just gotta finish messing with it later.