USB 3.0 HD write permissions

[David Cavalli]

I've read multiple other threads here, but haven't been able to get everything working. The most frustrating part is that most of it works, but my depth of knowledge seems to be one part short. Here's my hardware and configuration information I believe relevant:
(Asus) Asus RT-AC68U, Merlin v384.8.2, USB 3.0 Seagate external HD - Windows formatted
(Blitz) Windows 10
(PiMC) Raspberry Pi 3 B+, Raspbian Stretch v9

The Asus has a HD on the USB3. I can read/write/modify it from Windows on my Blitz machine. When mounted rw on my PiMC, it can read but not write.

I've tried multiple versions of my original post, but it keeps getting blocked for some reason. Writing this post just to get things started. Read all forum posts and can't get last part done. Can put in whatever other info needed, but shortened this post so it is not blocked again.

Thanks!

 

[ColinTaylor]

You're going to have to explain what you mean by "When mounted rw on my PiMC, it can read but not write." Are you plugging the drive into a Raspberry Pi and are unable to write to it? - That would be an issue with the Pi not the router.

Maybe you're talking about network shares, in which case what protocol are you using, SMB/CIFS(Samba)?, NFS?

What command are you using to "mount" this drive on the Pi?

 

[David Cavalli]

You're going to have to explain what you mean by "When mounted rw on my PiMC, it can read but not write." Are you plugging the drive into a Raspberry Pi and are unable to write to it? - That would be an issue with the Pi not the router.

Maybe you're talking about network shares, in which case what protocol are you using, SMB/CIFS(Samba)?, NFS?

What command are you using to "mount" this drive on the Pi?

I had all this in my original detail, but it kept blocking me from posting it. Here's the FSTAB entry from PiMC mounting Asus:

Asus:/mnt/Backup-DAC/Media /mnt/Media nfs rw,soft,intr,retrans=2,noauto,x-systemd.automount
Asus:/mnt/Backup-DAC/Public /mnt/Public nfs rw,soft,intr,retrans=2,noauto,x-systemd.automount

Thanks for the quick response!

 

[David Cavalli]

Also, if it matters, I have a 5 bay external mount on PiMC as well, in the fstab. Those drives all read/write just fine:


UUID=48484FBE484FAA10 /mnt/Orico1 ntfs noatime,defaults,auto,umask=000,users,rw 0 0
UUID=B076BBD476BB9A14 /mnt/Orico2 ntfs noatime,defaults,auto,umask=000,users,rw 0 0
UUID=A6423D75423D4B77 /mnt/Orico3 ntfs noatime,defaults,auto,umask=000,users,rw 0 0
UUID=AA10EAEA10EABD07 /mnt/Orico4 ntfs noatime,defaults,auto,umask=000,users,rw 0 0
UUID=983C9E9C3C9E754A /mnt/Orico5 ntfs noatime,defaults,auto,umask=000,users,rw 0 0

 

[ColinTaylor]

What do your NFS settings look like on the Asus?

 

[David Cavalli]

Not sure exactly what you're asking, so I'll guess you mean:

<see .png> for the settings in the Asus Samba section:

If I haven't guessed right in what you want to know, let me know in detail and I'll provide. Thanks!

 

[David Cavalli]

Tried to generate results from PiMC using ls, but it kept blocking my posts. Only when I edited that out did it let me post the prior page. To manually describe it, I have "drwx" permissions for all with root/root as the ownership.

 

[repeater]

I had same issue on my Mac. I transferred a TB of pics to my external HDD and could not write to the folders delete. I ended up transferring everything over the network to folders I created on the router. Takes longer and probably the easy way but it worked. I'm sure you'll get a far more technical way of doing it here soon from a save member.

 

[David Cavalli]

Thanks for the work-around, repeater. I -can- manipulate the data on the drives via my Blitz Windows machine already with the current permission set. Took a while, but found posts here that gave me pieces that (eventually) worked. What I need is for my RPi machine to do it, because I want to automate various activity moving files around, with my TV ones being pushed to the Asus directory to make available in Plex. Have done it manually for years, but now that I've automated (almost) everything, this one permission is the only thing standing in the way.

Figured out that even though I couldn't post the directory results in the post manually, I can snapshot it. For some reason, when this data was copy/pasted, it blocked me. Here's the png:

 

[ColinTaylor]

Not sure exactly what you're asking, so I'll guess you mean:

<see .png> for the settings in the Asus Samba section:

If I haven't guessed right in what you want to know, let me know in detail and I'll provide. Thanks!

No that's not it. In your previous post I can see your Pi is using NFS not Samba. So I need to see how you have configured NFS on the router. In your screen shot it's the next tab to the right, "NFS Exports". In there make sure you have entries for the folders you want to share and the permissions are at least "rw,sync" as per the wiki.

 

[David Cavalli]

That's it! Yes! It works! Minor issue remains, but major hurdle leaped!

I forgot I used NFS after my cifs mount line didn't work. The original fstab still has this entry:
#//Asus/Media /mnt/Media cifs credentials=/home/pi/.smbcredentials,uid=1000,gid=1000,x-systemd.automount 0 0

I had read all the other parts of the file and only just learned about the jffs configs part and thought I had that all done there. From your wiki page, I read it and entered rw,sync as you pointed out. That's what was missing! I see that I can maybe play around with a /jffs/configs/exports.add file so that my configuration is more easiliy recreatable, but for now, the main part works.

One minor quibble still, in my snapshot. Created directories, touched a file. Both worked. Then I used 'vi' for test. Strange message came up. Let me create a test file just fine, but the screenshot showed some weird error message upon start. Saved with vi, and test existed just fine, but so did a shadow file called test~. Looks like it leaves other scrubby files on there too, from the 'swap', but this doesn't stop me from my main objective.

I'm off to write the cron script on PiMC to automate my rsync command. Early manual script runs are working perfectly!

Thank you VERY much for your detail and patience in your responses. I really did try to resolve all my problems on my own, but this one somehow is the one that got away. Thanks for getting me there. I love this new router and the Merlin f/w and my home IT situation is so superior to what I had before.

One final time, thanks again! I truly appreciate it.

--David

 

[ColinTaylor]

The .swp file is the standard temporary file that vi creates. My guess is that some previous attempt to edit your file failed (probably because of permissions) and left behind a zero-byte copy of the temporary file. For example:

E325: ATTENTION
Found a swap file by the name ".xxx.swp"
          owned by: root   dated: Tue Jan 29 01:03:46 2019
         [cannot be read]
While opening file "xxx"

(1) Another program may be editing the same file.  If this is the case,
    be careful not to end up with two different instances of the same
    file when making changes.  Quit, or continue with caution.
(2) An edit session for this file crashed.
    If this is the case, use ":recover" or "vim -r xxx"
    to recover the changes (see ":help recovery").
    If you did this already, delete the swap file ".xxx.swp"
    to avoid this message.

"xxx" [New File]
Press ENTER or type command to continue

Try deleting that file (".test.swp") through SSH and then try again.

 

[David Cavalli]

Nope. Tried vi on 3 new files. Same behavior for all. My guess is that there's some weird permission problem the way the file is created. Solution? Don't need to 'vi' on any files there. Just found the problem when trying to create a file and directory to test the original issue described. No biggie.

The .swp file is the standard temporary file that vi creates. My guess is that some previous attempt to edit your file failed (probably because of permissions) and left behind a zero-byte copy of the temporary file. For example:

E325: ATTENTION
Found a swap file by the name ".xxx.swp"
          owned by: root   dated: Tue Jan 29 01:03:46 2019
         [cannot be read]
While opening file "xxx"

(1) Another program may be editing the same file.  If this is the case,
    be careful not to end up with two different instances of the same
    file when making changes.  Quit, or continue with caution.
(2) An edit session for this file crashed.
    If this is the case, use ":recover" or "vim -r xxx"
    to recover the changes (see ":help recovery").
    If you did this already, delete the swap file ".xxx.swp"
    to avoid this message.

"xxx" [New File]
Press ENTER or type command to continue

Try deleting that file (".test.swp") through SSH and then try again.

 

[Zonkd]

Am I understanding this thread correctly @ColinTaylor ?

I see @David Cavalli set 3 different logins on the router:
1. cavalli1021
2. David
3. Media.
Presumably each device logins in with a different account... on the PiMC logs in as Media and the Windows PC logs in as cavalli1021 and/or David...? So the problem is directory read/write permissions specified for each account in the web GUI aren't being inherited by files created inside them?

Example: PC logged in as David does touch file.txt to Public directory. PicMC logged in as Media cannot edit file.txt despite having rw permission for the Public directory?

If I'm understanding correctly then this is a nuisance problem I've been dealing with on my mates router but haven't put effort into solving when I'm over there. I vaguely recall the sole problem being ownership. I just made a habit of recursively chown'ing the entire Media directory after uploading new video files from my PC logged in as User. That way I can delete them later from the TV logged in as tv or phone logged in as User2. The easiest solution would be to login with a single account on all devices. I'm not there right now and I can't remember what ownership I assigned or if I determined there would be a tradeoff with security... chown root:root? I probably should have checked if there was some way of doing it with groups.

 

[ColinTaylor]

Presumably each device logins in with a different account... on the PiMC logs in as Media and the Windows PC logs in as cavalli1021 and/or David...? So the problem is directory read/write permissions specified for each account in the web GUI aren't being inherited by files created inside them?

No. The Pi was using NFS not Samba so users and permissions are handled by a completely different mechanism.

 

[David Cavalli]

No. The Pi was using NFS not Samba so users and permissions are handled by a completely different mechanism.

Right. The Pi mounted it with NFS just fine. I use the Pi (successfully) to control another 5 HD array with Samba, but that's a different story.

Am I understanding this thread correctly @ColinTaylor ?

I see @David Cavalli set 3 different logins on the router:
1. cavalli1021
2. David
3. Media.
Presumably each device logins in with a different account.

The cavalli1021 account was created simply as a login to the router. I had no idea that it would have ramifications at the time I initialized it.
The David account was created because that's my Windows account information. When you have the same account/pw, permissions just "work". The David account was intended to be 'rw' permissions, so I can manipulate the HD (and Pi) resources as an admin with full rwx permissions easily.
The Media account was created for external media players (Pivos Aios, Chromecast on other laptopts, etc.) so that they ONLY have 'r' access. They should have access to read/play my media files, but NOT administrate them.

Hope that clears up how/why I set it up the way I did. Lots of subsystems interacting here. Things finally starting to come together with my ultimate integration of all my media-oriented machines.

Thanks!

 

[David Cavalli]

Almost everything is working perfectly. The configuration is almost exactly the same as before, with some minor modifications. I've changed the Asus login from cavalli1021 to cavalli successfully. I've even added an fstab entry for mounting my remote cloud machine. Unfortunately, just as my project is about to be completed, the Asus USB HD has another write issue. I know is the Asus HD, because I substituted using the write to my Orico HD also mounted by the Pi and it worked great. Can describe the FULL details of the project and what's exactly failing if that is the only way to go.

I have another request along these lines, which might solve my ultimate problem, after reading the responses that made the NFS mount work. It does MOST of the things, but not all. My new thought is that if I mounted it with cifs in fstab, it might work great. That way, it would be easy to use the permissions set in the web page for the mounted drive.

The working NFS mount in /etc/fstab currently reads:
Asus:/mnt/Backup-DAC/Media /mnt/Media nfs rw,soft,intr,retrans=2,noauto,x-systemd.automount

The cifs mount that fails in /etc/fstab reads:
//Asus/Media /mnt/Media cifs credentials=/home/pi/.smbcredentials,uid=1000,gid=1000,x-systemd.automount 0 0

The .smbcredentials contents are:
domain=Servalan
username=Media
password=<pw> as it was set in the web page for this initial purpose.

Any help that can get me up and running would be greatly appreciated. This has been very frustration and being SO close to the final issue, I request the help of the web forum here.

Thanks!

 

[ColinTaylor]

I'm not sure what problem you're expecting us to solve here. If it's the "Asus USB HD has another write issue" then you'll have to provide some sort of information, i.e. log files, error messages, etc.

 

[David Cavalli]

My Asus DOES have another write problem. The solution I was hoping to try was using the Pi to mount it with Samba instead of NFS. I believe the NFS permissions aren't working, and that if I used credentials on a Samba mounted drive, that might work. I just don't know what's wrong with my Samba /etc/fstab entry and that was the initial question.

The problem I can describe easily enough, if resolving permission problems with NFS is easier. Without reading above config already described, here's a simplified configuration:
1) Seedbox, a Linux machine in the cloud, pulls down media files.
2) Asus + HD, the ultimate local destination for my media files.
3) Raspberry Pi MC, the brains behind the media center (Plex, Sonarr), with archival media storage (USB Orico 5 bay HDs)

The Pi mounts in /mnt the Seedbox, the Asus, and the local Orico drives, on /mnt/Seedbox, /mnt/Media and /mnt/Orico# respectively. All machines have .ssh configurations for remote access.

I'm running Sonarr on the Pi, which controls Transmission (running on Seedbox) to acquire media files, then pulls them down when completed automatically. When it tries to write these files to the Asus, it has 'write errors', saying it can't open the directory. When I temporarily redirect Sonarr to write in a /mnt/Orico drive, the operation completes flawlessly. I assumed the issue is a permissions one regarding the Asus, when talking to the remote machine.

In general, the Pi has worked great to read/write anywhere I like. I can 'vi' a file on /mnt/Media without issue. That was the previously celebrated success from this thread. What is NOT working is the only write to /mnt/Media that matters. Copying a file from /mnt/Seedbox/x.mkv to /mnt/Media/TV has write permission failures. No idea why. It's not just Sonarr that fails. Here's some text from a direct 'cp' command from the Pi manually doing what Sonarr is trying to achieve:

pi@PiMC:/mnt/BuyVM/zDL/transmission $ ls
19021405.Michael van Gerwen vs Mensur Suljovic.mp4
pi@PiMC:/mnt/BuyVM/zDL/transmission $ cp *.mp4 /mnt/Media/*deo/TV
cp: cannot create regular file '/mnt/Media/My Video/TV/19021405.Michael van Gerwen vs Mensur Suljovic.mp4': Operation not permitted
pi@PiMC:/mnt/BuyVM/zDL/transmission $

Here's the same command when copying the file to my Orico drive:

pi@PiMC:/mnt/BuyVM/zDL/transmission $ ls /mnt/Orico5
My Moviez/ $RECYCLE.BIN/ System Volume Information/ zTemp/
pi@PiMC:/mnt/BuyVM/zDL/transmission $ cp *.mp4 /mnt/Orico5/zTemp
pi@PiMC:/mnt/BuyVM/zDL/transmission $ ll /mnt/Orico5/zTemp total 89144
-rwxrwxrwx 1 root root 91280402 Feb 16 17:48 19021405.Michael van Gerwen vs Mensur Suljovic.mp4*
pi@PiMC:/mnt/BuyVM/zDL/transmission $

Proves to me that the Seedbox mount isn't an issue. Reads just fine going to the Orico. I know the Asus writes in general, but that 'vi' problem I posted earlier seems to be related. I have general access to do things on the Asus drive. As such:

pi@PiMC:~ $ cd /mnt/Media/zDL
pi@PiMC:/mnt/Media/zDL $ echo date >> testfile
pi@PiMC:/mnt/Media/zDL $ ll
total 4
-rwxrwxrwx 1 root root 5 Feb 16 17:52 testfile*
pi@PiMC:/mnt/Media/zDL $

Which brings me back to the initial problem. I know that I can write "in general" to the Asus HD. I just can't do it in any meaningful way for the entire purpose of having it.

Hope that helps get started. Happy to do anything to generate logs for you. I can just simulate the problem.

Thanks again for the help, time and patience!

 

[David Cavalli]

The /etc/fstab file, in case it helps. Renamed to .txt only so it can be uploaded.

Thanks!