Simple SMB question: Does the user on the client machine matter?

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Simple SMB question: Does the user on the client machine matter?

      do user accounts on the client machine matter? (not the credentials used to login to Samba, but the actual user account on the client machine)

      I ask because I am having trouble writing/modifying files in my mounted samba directory from my user account, but can modify files as root. The shared folder is setup on OMV with Read/Write/Execute permissions for everyone but when I mount the share I can only modify folders as root.

      Any help troubleshooting the problem would be much appreciated.
    • SMB (Samba) and Simple in the same line.... :)

      Yes, client credentials matter. When a client machine tries to access a Samba share on a LAN, it presents (as logged in on the client) the username and password to the Samba Server. If "Guests Allowed" is set on the SMB share, AND "Others" have write on the shared folder, almost all can write the share. (I said "almost" because there are exceptions.)
      In any case, if the permissions on the shared folder are restrictive, "Guests Allowed", as set on the SMB network share, can not override that.

      When it comes to Linux permissions, there's a difference between "Others" (Linux) and the rough equivalent "Everyone" (in Windows).

      In Linux (basic permissions) there are three accesses; Owner, Group, and Others. In Linux "Others" are ALL users or groups who are not the Owner or in the Users Group specified. This means that the users group permission can be used to deny access to the group specified. In other words, it's possible to grant access to everyone NOT in the users group. This would be an unusual case, but it can exist. **Windows doesn't work like that. The least restrictive access to any resource is honored and "Everyone" is, literally, everyone. Accordingly, "Everyone" is a trump card that overrides other restrictions.**

      One could use extended Linux permissions but that doesn't always work as it should. It can get weird.
      (OMV shows extended permissions as boxes, by a specific user name, that are checked for read or write.)
      ___________________________________________________________

      There are a few ways to clear up the SMB problem:

      I'd get the reset perms plugin and make sure (force) the shared folder to Everyone Read/Write. (Without splitting hairs on the word "Everyone" in this context, the plugin will clear all potential access blocks at the folder/file level.) Then, check the SMB share to insure "Guests Allowed" is selected.

      (OR)

      A more secure method would be to add user names and passwords, to OMV, that match the user names and passwords that you use to log onto your Windows clients. (Don't forget that OMV user names and passwords are case sensitive.)
      When created, these users will be added automatically to the default group in OMV, "users". When these Windows credentials are supplied to the OMV server when the SMB share is accessed, they'll match and access would be granted.

      Check your shared folder permissions and insure that the users group has read/write, and make sure the SMB share has "Guests Allowed".

      Hope this helps.

      Video Guides :!: New User Guide :!: Docker Guides :!: Pi-hole in Docker
      Good backup takes the "drama" out of computing.
      ____________________________________
      Primary: OMV 3.0.99, ThinkServer TS140, 12GB ECC, 32GB USB boot, 4TB+4TB zmirror, 3TB client backup.
      OMV 4.1.13, Intel Server SC5650HCBRP, 32GB ECC, 16GB USB boot, UnionFS+SNAPRAID
      Backup: OMV 4.1.9, Acer RC-111, 4GB, 32GB USB boot, 3TB+3TB zmirror, 4TB Rsync'ed disk

      The post was edited 3 times, last by flmaxey: edit2 ().