0

I have come across a weird error with permissions with an external hard drive I attached to my server. I wanted to enable Transmission to download torrents to a folder on it, but discovered it was unable to create directories due to permission errors.
I tested it myself and verified that the daemon, running as user transmission, can't create directories in a folder it owns with 755 permissions.
I thought it might be some weird inode shenanigans, but an fsck came back clean and everything looks normal.

matoro@matoro-server ~ $ ls -i /run/media/matoro/drive-data total 40 43253761 drwxr-xr-x 5 matoro matoro 4096 Apr 11 2017 backup 11796481 drwxr-xr-x 3 matoro matoro 4096 Oct 28 22:40 iso 37568568 drwxr-xr-x 2 matoro matoro 4096 Apr 23 2017 pending 42336296 drwxr-xr-x 3 matoro matoro 4096 Oct 25 01:26 podcasts 38141969 drwxr-xr-x 39 matoro matoro 12288 Sep 18 22:05 reading 37519377 drwxr-xr-x 3 transmission transmission 4096 Oct 30 17:10 seeding 37490784 drwxr-xr-x 4 matoro matoro 4096 Oct 30 17:09 videos 42336292 drwxr-xr-x 3 matoro matoro 4096 Oct 25 01:23 youtube matoro@matoro-server ~ $ ls -ia /run/media/matoro/drive-data/seeding total 912160 37519377 drwxr-xr-x 3 transmission transmission 4096 Oct 30 17:10 . 2 drwxr-xr-x 11 matoro matoro 4096 Nov 3 14:56 .. 37584902 drwxr-xr-x 3 transmission transmission 4096 Aug 10 2016 'some directory' 37488367 -rw-r--r-- 1 transmission transmission 430297088 Aug 14 2016 some_file matoro@matoro-server ~ $ sudo -u transmission mkdir -v /run/media/matoro/drive-data/seeding/test mkdir: cannot create directory ‘/run/media/matoro/drive-data/seeding/test’: Permission denied 

Here are the relevant mount options:

/dev/sdc3 on /run/media/matoro/drive-data type ext4 (rw,nosuid,nodev,noexec,noatime,data=ordered,uhelper=udisks2) 

What could be causing this? Could it have something to do with ACLs?

1 Answer 1

2

The mkdir command must traverse the directory structure to find the existing directory /run/media/matoro/drive-data/seeding and then add an entry to it. The required permissions are:

  1. x permission on /
  2. x permission on /run
  3. x permission on /run/media
  4. x permission on /run/media/matoro
  5. x permission on /run/media/matoro/drive-data
  6. w and x permission on /run/media/matoro/drive-data/seeding

(and of course they all must be directories, and the one you're creating must not already exist)

I bet you're missing one of these (probably #4 or #5) If the process already had /run/media/matoro/drive-data/seeding as its current directory (which can happen if the ancestor directory permissions change after you enter the directory, or if the process switches uid) then it could mkdir test and succeed with only permission #6 (w and x on the current directory) while mkdir /run/media/matoro/drive-data/seeding/test would require all of the x permissions, even though it refers to the same location.

When you use absolute paths, or relative paths with multiple components, there is an x permission check on every ancestor directory that you mention.

2
  • Yup, looks like #4 was the culprit. My understanding is that the structure of /run should be handled by the init system - what is the best way of going about giving other users access to external drives? Commented Nov 4, 2017 at 2:01
  • 1
    The permission octal 1777 gives everyone write access to shared directories, while reserving delete rights for the file/directory owner. 1755 would reserve write permissions as well. I usually go with 1777 for my shared directories. This also works for files on external drives. Commented Nov 4, 2017 at 6:28

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.