1

I've mounted a samba share to /mnt/nas with an fstab entry. I can read everything, but sudo is required to write to it (permission denied on touch test.txt but not sudo touch.txt). I tried:

chown -R user:user /mnt/nas and chown -R user /mnt/nas

of course as root and with my username. When I don't specify the group, I get an error about being unable to read lost+found, which I don't think I should care about. ls -l does not show write permissions for my user either way.

The question Samba non-root user can't write to share 's accepted answer just tells me to change permissions, which is unhelpful.

This: Mount issues with Samba under non-root user just tells me to read man pages, which I have tried. I have been unable to find an answer.

I assume there's nothing magical about my SMB share and I'm just doing a bad job with the chown command. What should I be doing differently?

6
  • Have you tried changing the permissions on the Samba server? itself? Aug 26, 2020 at 0:20
  • @NasirRiley ssh'd in everything works fine.
    – user304684
    Aug 26, 2020 at 0:59
  • What do you mean "everything works fine"? Did you do anything? Are you able to write to the share as a regular user? Aug 26, 2020 at 1:14
  • @NasirRiley Yes, sorry, I am able to write to the share.
    – user304684
    Aug 26, 2020 at 1:16
  • Then post what you did as an answer and accept it so that others know. Aug 26, 2020 at 1:17

1 Answer 1

1

I found the following on the mount man page:

Mount options for smbfs Just like nfs, the smbfs implementation expects a binary argument (a struct smb_mount_data) to the mount system call. This argument is constructed by smbmount(8) and the current version of mount (2.12) does not know anything about smbfs.

Which lead me to the smbmount man page:

WARNING: smbmount is deprecated and not maintained any longer. mount.cifs (mount -t cifs) should be used instead of smbmount.

Which lead me to the mount.cifs man page:

mount.cifs mounts a Linux CIFS filesystem. It is usually invoked indirectly by the mount(8) command when using the "-t cifs" option.

File And Directory Ownership And Permissions The core CIFS protocol does not provide unix ownership information or mode for files and directories. Because of this, files and directories will generally appear to be owned by whatever values the uid= or gid= options are set, and will have permissions set to the default file_mode and dir_mode for the mount. Attempting to change these values via chmod/chown will return success but have no effect.

When the client and server negotiate unix extensions, files and directories will be assigned the uid, gid, and mode provided by the server. Because CIFS mounts are generally single-user, and the same credentials are used no matter what user accesses the mount, newly created files and directories will generally be given ownership corresponding to whatever credentials were used to mount the share.

If the uid's and gid's being used do not match on the client and server, the forceuid and forcegid options may be helpful. Note however, that there is no corresponding option to override the mode. Permissions assigned to a file when forceuid or forcegid are in effect may not reflect the the real permissions.

When unix extensions are not negotiated, it's also possible to emulate them locally on the server using the "dynperm" mount option. When this mount option is in effect, newly created files and directories will receive what appear to be proper permissions. These permissions are not stored on the server however and can disappear at any time in the future (subject to the whims of the kernel flushing out the inode cache). In general, this mount option is discouraged.

It's also possible to override permission checking on the client altogether via the noperm option. Server-side permission checks cannot be overriden. The permission checks done by the server will always correspond to the credentials used to mount the share, and not necessarily to the user who is accessing the share.

This explains why your attempts to chown don't do anything.

I've never actually mounted or configured an smb share, so I'm kind of guessing, but it seems like the fstab entry should probably look something like this:

//SERVER/sharename /mnt/mountpoint cifs _netdev,username=myuser,password=mypass,uid=xxx,gid=xxx 0 0

Where you populate the uid with your user's ID, and the GID with your user's id. (NOTE that you may need forceuid and forcegid)

The username and password options are used for authentication to the samba share.

Another (and probably the best) option would be to setup a proper usershare:

Arch Wiki - Samba Usershare

You must log in to answer this question.