Could write to shared drive, now I can't?

Zitat von Ziradog

I am running OMV 3.0.87 on a Raspberry Pi 3. I am using the NAS to store music for my music servers. I had some difficulty setting it up initially, and was unable to write to the shared drive from my Windows 10 pc until I went into Windows Explorer and gave the share a drive letter. It worked great for a week.

So today I went to put some more music on the share and got "Destination Folder Access Denied - You need permission to perform this action". I went back and re-checked everything I did initially, no luck. I am logged into the OMV as admin, if that matters, but that too is the same as what I did when it worked. I can share the settings I used but not sure which ones are relevant? I am doing all this through the GUI as my Linux skills are pretty minimal (basically limited to what I learned setting up 2 music servers).

Thanks for any help.

Due to a SMB1 security attack, good ole M$ made changes in their critical update cycle, to Windows clients, where the SMB1 protocol isn't used.

Take a look at the following client max protocol line in SMB/CIF shares, at the bottom, in "Extra Options". As I understand it, the SMB3 protocol is for Windows 7 clients and above. It wouldn't hurt to give it a try.

The Samba server will need to be restarted. (Or reboot your box.)

Try it at the top. It's a protocol argument so it shouldn't affect the rest.
(I'm assuming that the text is parsed top to bottom, like a program, so it should be read first.)
_____________________________________________

Taking into account other considerations:
These days I'm even leery about doing Samba updates. You might want to think about cloning your boot drive on a regular basis and, definitely, before doing an update. This is one of the reasons why I prefer to boot from USB drives. They're easy to clone.

Zitat von Ziradog

I am running OMV 3.0.87 on a Raspberry Pi 3. I am using the NAS to store music for my music servers. I had some difficulty setting it up initially, and was unable to write to the shared drive from my Windows 10 pc until I went into Windows Explorer and gave the share a drive letter. It worked great for a week.

So today I went to put some more music on the share and got "Destination Folder Access Denied - You need permission to perform this action". I went back and re-checked everything I did initially, no luck. I am logged into the OMV as admin, if that matters, but that too is the same as what I did when it worked. I can share the settings I used but not sure which ones are relevant? I am doing all this through the GUI as my Linux skills are pretty minimal (basically limited to what I learned setting up 2 music servers).

Thanks for any help.

OK, let's go back and review the above.

It's not clear from "where" you're trying to write to the music share. Is it from a Windows client (7, 8, 10, other)? You said you're logged into OMV as "admin". The only place where "admin" and a password works, is on the Web GUI login page. Where are you using the "admin" log in to access the music share? Are you being prompted when attempting to access the share and using admin / passwpord as a credential?

On the permissions end of it, in the base share (in OMV, under Access Rights Management, Shared Folders):
Highlight the Music folder and click on ACL. At the bottom, you'll see what they're calling "Extra Options". Actually, that box shows Linux basic permissions. (The box at the top is Extended Permissions.) In any case, where it says "Others" hit the drop down and make it Read/Write/Execute.

In the SMB/CIF (Samba) share for "Music":
In the "Public" setting, select "Guests Allowed" and make sure the "Read Only" switch is not green (or off).
__________________________________

Finally, I don't know how you've set up your Windows users but, if you want OMV's shared folders to be accessible to Windows users (without having to provide credentials) you'll need to create OMV users with the same user names and passwords as your Windows users. They'll need to be members of OMV's "users" group. (Being added to the "users" group happens by default when a new user is created.) When a shared folder is created the "Group" setting is, typically, "users". In the same line, if Read/Write/Execute is selected, your users will have write access to shares.
(This also requires that the Samba network share doesn't have "Read Only" set.)

__________________________________

Since SMB connections are a two ended protocol negotiation:
For the Windows client end of it, here's a link to an M$ article that will tell you how to enable SMB3, if it's not already activated. -> SMB

Sorry, I wasn't ignoring you. I just got back after a few days out of town. I"m back until Monday.

Have you reinstalled yet? If not, take a look at my Music share following. When I click on Music, my ACL button is not greyed out.

After clicking on Music, if your ACL button is greyed out, install the resetperms plugin, shown below.
(It will provide you with a way of taking back control of permissions.)

If you can get to the ACL screen, note the following. With the permissions shown below (it's wide open), coupled with "Guests Allowed" and "Read Only off" on the Samba share, you should be able to write to your Music share.

_______________________________________________________________________-

Assuming your ACL button is greyed out, after installing the resetperms plugin, in Shared Folders, you'll have a new Tab which says Reset Permissions.

Use the following to Reset Permissions on your Music Folder. (Again, note it's wide open.)

Let me know how it goes.

Zitat von Ziradog

Ok, I started with a clean microSD card. Downloaded & installed OMV. I used this tutorial to set up a simple shared drive using an old 8 gb flash drive for storage: https://www.cnet.com/how-to/ra…pi-as-cheap-nas-solution/. Note that it did not have me set up any Users, and for permissions I gave Guests Read & Write Access.And it worked fine, I could write to it from 2 different Windows 10 machines on my network, one the family machine mentioned above that has no password, one a laptop that I set up a new User & Password on.

Then I shut down OMV, moved it, and restarted it.

Now I cannot write to it from either pc.

I missed the above post. The last post I wrote has, obviously, been overtaken by events.

(I really need to write a "Getting Started With OMV" guide, but it's going to have to wait until this Fall / Winter.)
____________________________________________________________

If you're still interested in getting this to run - explain to me what you mean by;

Then I shut down OMV, moved it, and restarted it.

Zitat von Ziradog

Ok, I started with a clean microSD card. Downloaded & installed OMV. I used this tutorial to set up a simple shared drive using an old 8 gb flash drive for storage: https://www.cnet.com/how-to/ra…pi-as-cheap-nas-solution/. Note that it did not have me set up any Users, and for permissions I gave Guests Read & Write Access.And it worked fine, I could write to it from 2 different Windows 10 machines on my network, one the family machine mentioned above that has no password, one a laptop that I set up a new User & Password on.

Then I shut down OMV, moved it, and restarted it.

Now I cannot write to it from either pc.

In my own defense, realize that it's difficult to understand a forum member's level of Linux knowledge from a posted problem. In some of the above, I may have assumed too much.
_____________________________________________________

I followed up on the link you provided above and that shed some light on how and what you're doing.

If you're willing to try it again, to do one more rebuild, please make the following change when you get to the creation of your shared folder. (Highlighted, yellow, below.)

As mentioned before, the SMB/CIF share (a.k.a Samba Share) should be Public: "Guests Allowed" with "Read Only" off (grey, not green).

Given the procedure in the link you provided:
With the change shown above, I think this will work for you.

Well, I have to throw another disclaimer in here as well. First, I completely cut the cord with Microsoft when W10 came out. In my opinion, there's really nothing new about W10, versus iterations all the way back to Win7. In all versions since W7, the OS has offered noting more than "Windows dressing". (From another aspect, I actually see W10 as dangerous to privacy in that the user agreement - as of W10 - is stacked in M$'s favor.) OK, I'll get of the soap box now.

Second, M$ is throwing wrenches into all of this with their constant dic*ing around with their version of SMB (Server Messaging Block). While SMB is a universal protocol, M$ acts as if they own it and they alter it at will. (And as you might imagine, compatibility with open source is not their highest consideration.) Obviously, this causes a few problems out of the gate, until the open source community can catch up with the changes.

Adding to the above, their security updates can (and do) change how their clients handle network shares and network traffic in general. They have a lot of undocumented "features".

So in the bottom line, with W10 in the mix, I'm not sure how this will work out, but it's worth a try.
__________________________________________________________________

One other thing; for Samba to work correctly, the workgroup on OMV and your W10 machine should to be the same. Typically, it's workgroup . However, I can't see where you'd have had access at all, or at any point, if this setting wasn't right.

**With permissions wide open "Everyone Read Write", Guests allowed, etc.:
**That line I had you add to SMB extra options (max protocol =), if it's there, remove it. It might be time to look at the W10 end of this.
___________________________________________________________________

Look at this link to start Windows Power Shell as an admin or "elevated": Power Shell

Then look at this link for disabling the SMB2 and 3 "client" protocols, using power shell.
(Note this is a copy and paste operation, and it will be easy to re-enable them.)

Here's the link - > Disable SMB2/3
(Note that Windows 10 is not, specifically, mentioned so use the "cmdlet" for Windows 8, in power shell.)

As I read the article:

To enable SMBv1 on the SMB client,:
sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc.exe config mrxsmb10 start= auto

To disable SMBv2 and SMBv3 on the SMB client
sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc.exe config mrxsmb20 start= disabled

After the changes, a reboot is required.
____________________________________________

After testing to see if your can get to the network shares on your R-PI, you can make a decision as to whether, or not, to keep things this way. It can be reversed as follows:

To enable SMBv2 and SMBv3 on the SMB client:
sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc.exe config mrxsmb20 start= auto

Let me know how it goes.

Zitat von Ziradog

While I digest those links, do you want me to do this on my original install, the second install, or a new install?

I too wonder about the Windows side. One interesting thing I noted is that the tutorial I linked (and others) say that when mapping the drive on the Windows machine, it will ask for login credentials. It did not, and I could not see a way to make it ask for them.

When you map a remote network share, from a Windows machine (so that it looks like a local drive with its own Drive letter, credentials are for the other end (in your case OMV/Linux). Further, credentials that would apply "if" the permission you set for the remote share is "Others = NONE". In that case, if you had a Linux user defined and in the "users" group, you would need to put that user name and password in at the credentials prompt. In your case, since Everyone has read and write, Linux will not prompt you for credentials. When Everyone can read and write the share, they're not needed.
__________________________________________

I'd rather you experiment with the last OMV build, where you have the external hard drive connected, a shared folder is created, Everyone has Read and Write, and the SMB share is set to Guests Allowed with Read Only set to off.
__________________________________________

Since I have 10 Samba shares going, with various clients reading and writing them with no issues (Win7, Win8, Vista, Linux Mint 18, etc.,), I'm of the opinion that your problem (with wide open permissions no less) may be a Win10 issue.

I'll be out of town until this coming Friday.