As has been stated in other answers, the three numbers determine access permission in this order:
- the owner (match UID)
- members of the files' GID (excluding the owner)
- any UID not covered by the previous two specifications.
So you can have a file that actually grants more access to people other than the group or owner of the file:
[dave@store01 tmp]$ touch this
[dave@store01 tmp]$ sudo chmod 007 this
[dave@store01 tmp]$ ls -l this
-------rwx 1 dave users 0 Jan 20 22:15 this
[dave@store01 tmp]$ cat this
cat: this: Permission denied
The exception to this is root. Any file that root has root control over can't be denied to root(*).
[root@store01 tmp]# touch that
[root@store01 tmp]# chmod 007 that
[root@store01 tmp]# ls -l that
-------rwx 1 root root 0 Jan 20 22:17 that
[root@store01 tmp]# cat that
[root@store01 tmp]#
In your specific case, chmod'ing the directory to 777 will mean that anyone who can access the directory will have full access to everything. It may be simplest to grant 777 access to the target directory, do your upload, then immediately lock the directory down. You do NOT want to leave your system that way.
I would personally try to understand what UID is involved with the failed transaction and see if granting different ownership or group access would work better, depending both on what I immediately wanted to do and what I might want to do in the future.
--
(*) = using this mechanism. Things get more complicated with ACLs and extended attributes, but that's beyond this question's scope