Set up upload permissions for a share folder on server via ssh

Question

I have set up a headless home file server using Ubuntu Server 17.04. I access it over WiFi using SSH from my laptop running standard Ubuntu 17.04. I have found that SSH (SFTP) is sufficient for my needs for serving files (e.g. music and photographs) for my home network.

Now I would like to be able to upload files to a folder on my server's hard drive /dev/sda1, which is currently mounted as /media/a. It uses the ext4 Linux filesystem and I mounted it using the command sudo mount /dev/sda1 /media/a.

I can run SSH commands from the terminal (by logging in with ssh username@servername) and I can access the files via the GUI on my laptop (files > other locations > connect to server > sftp://username@servername). However when I try to create a new folder (say) it says

Error creating new folder: permission denied.

I tried setting the permissions on an upload folder (newly created via my ssh session) with sudo chmod o=rwx /media/a/upload. However, when I now try to create a folder there via the GUI on my laptop, it says

Error creating new folder: unknown reason.

How can I upload files to my server from my laptop?

EDIT: Here is the contents of my /etc/ssh/sshd_config file, as requested:

#   $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem   sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server

EDIT: The following is the output of the various commands requested in the comments

username@servername:~$ findmnt /media/a

TARGET   SOURCE    FSTYPE OPTIONS
/media/a /dev/sdc1 ext4   rw,relatime,data=ordered
username@servername:~$ namei -lx /media/a
f: /media/a
Drwxr-xr-x root root /
drwxr-xr-x root root media
Drwxr-xr-x root root a
username@servername:~$ id
uid=1000(user) gid=1000(user) groups=1000(user),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),111(lxd),116(sambashare),117(lpadmin)
username@servername:~$ getfacl /media/a
getfacl: Removing leading '/' from absolute path names
# file: media/a
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

username@servername:~$ mkdir -v /media/a/upload
mkdir: cannot create directory ‘/media/a/upload’: Permission denied

Answer 1

It looks like you want a "sticky" directory like /tmp in which every user with write access can create entries but they can't change the directory itself or delete entries created by other users. The sticky bit has the octal mask 1000 or the symbol t.

To set the "sticky" or "restricted deletion" flag:

sudo chmod +t /media/a

To set the "sticky" flag and allow everyone to create directory entries:

sudo chmod a=rwxt /media/a

---

The manual page of unlink(2) describes the effect of the sticky flag on directories in its error condition section:

EPERM or EACCES: The directory containing pathname has the sticky bit (S_ISVTX) set and the process's effective UID is neither the UID of the file to be deleted nor that of the directory containing it, and the process is not privileged (Linux: does not have the CAP_FOWNER capability).

See also

• What is the “t” letter in the output of “ls -ld /tmp”?
• How does the sticky bit work?

Answer 2

Although restricting deletion of unowned folders as David suggests is possibly a good idea for your usage case, it's not the root cause of your issue.

The o= switch for chmod indicates others (not user, not group member), not everyone. I don't think that's what you have in mind. To set read and write for you, you want to use the u= switch as in sudo chmod u=rwx /media/a/upload

Of course this assumes that you have write access to the parent directory Which your question indicates you do not. You need write permission to a directory in order to create a directory in it which is why you cannot mkdir -v /media/a/upload as you only have read and execute permissions to /media/a/

Note that since permissions apply to (U)ser (G)roup and (O)thers if you want fine access control you'll need to change the user or group or both from it's current root:root ownership. more on chown below.

If my user name was ivan and I wanted rwx access for me only on the media/a/upload directory I would issue the following commands.

sudo chown ivan /media/a/upload (which would leave the group status unchanged) or more generically

sudo chown username:groupname /media/a/upload

followed by

sudo chmod u=rwx /media/a/upload

Since others have access via the x permission to /media/a/ you should be allowed to traverse that directory allowing the change of ownership and permission settings on /media/a/upload/

For more on chown see man chown or https://linux.die.net/man/1/chown For more on chmod see man chmod or https://en.wikipedia.org/wiki/Chmod or https://linux.die.net/man/1/chmod

Sources:

man chown

man chmod

https://en.wikipedia.org/wiki/Chmod

Edit: The Change folder permissions and ownership post goes into great detail on this topic.