That's smart and good that you ask before doing anything if you don't understand.

Unix standard file permissions (and macOS is technically based on Unix) are:

• Read (can read the file, or in the case of a directory/folder, read the directory contents)
• Write (can write to a file, or in the case of a directory/folder, create a new file in a directory)
• Execute (can execute a file as a program, or in the case of a directory/folder use the file in a pathname to open/close it for read/write operations).

Directories or folders are simply a special type of file, so these rules apply.

These permissions are applied to 3 classes of users for every file:

• The owner (usually the user that created it)
• A named group of users associated with the file.
• Everyone else

Here's the explanation of what you see from your output

• d - the file is a directory or folder,
  
• The file owner has read/write/execute permissions,
• The group associated with the file/directory has read and execute permissions only,
• Anyone other than the owner or users included in the named group have read and execute permissions only.

Because users other than root do not have write permissions, any attempt by a user other than root (such as when you run a Fusion virtual machine) to add a file to /private/tmp will be met with an operating system error 13 (which is what you see in the Fusion log).

• The owner of the directory is "root".
• The group associated with the director is "wheel"l

The chown command (short for "change owner") will allow the changing of the owner or primary group of a file/directory. In your case, this is not necessary because the /private/tmp directory has the correct owner and group settings.

Given what we've seen, the fix for your problem is to use the chmod (short for "change mode") to change the "file mode" or permissions of the /private/tmp directory to the correct values. The correct values for /private/tmp are:

• the owner (u), group(g), and everyone else(o) have read, write and execute/access (rwx) privileges to the directory 
• the "sticky bit" is set on the directory (+t) The "sticky bit" is a security feature that restricts the deletion of a file in the directory to the the owner of the file only (in most cases that's the user that created it). Other users can't delete the file even if they have write permissions to the directory or file in the directory. 

The following 2 commands are equivalent and will perform the desired changes. Pick whichever one makes more sense to you as they do the same thing.

sudo chmod 1777 /private/tmp
sudo chmod u:rwx,g:rwx,o:rwx,+t /private/tmp

Either of these should result in a "ls -ald /private/tmp" returning the proper permissions of "drwxrwxrwt".

Hopefully this explains what's going on and that it makes you comfortable in what you should do to fix this.

Were any software updates or "maintenance utilities" run on your system between the time that it worked and the time that it stopped working? Do you have any software that updates itself behind the scenes (such as Google Chrome) and may have performed an update while you weren't looking?