UPDATE: Bug confirmed. Updating system caused R/W CIFS shares to no longer be writeable.

[mudshark]

Some months ago I tried adding a secure WebDAV share but could never access it as it never accepted my password (insecure WebDAV worked OK).
I was told there was an open bug issue with... was it the certificates or with WebDAV itself.. and that I should wait for an update to try again. I waited for 2 updates, I think!

I tried to add a WebDAV share yesterday and it too will not work if set to require https access. So I stopped the service and deleted the share I created thinking all would be OK but it is not.

My CIFS shares can no longer be written to from PCs. I tried rolling back to an earlier boot config... No help.

You can see the problem in the screen shots below.

I need to correct my volume settings now, but I do not know what all the settings in that now-wrong dialog box should be!
Can someone please help me reset permissions on my volume?

Thx all!

 

[cyberjock]

I'm using webdav (secure with https) and those settings you have there are exactly the settings I have for my webdav dataset. /shrug

I am using the latest FreeNAS build though. ;)

 

[mudshark]

That volume is *not* a dedicated "WebDAV" dataset.
That is the entire storage pool from which any and all shares (including CIFS) are served.
I can worry about the secure/insecure access later but for now I need the entire "RAID10" storage pool made accessible again according to settings under "Sharing".

 

[cyberjock]

Well, if you overwrote all the volume permissions with those, then you've got a hell of a lot of permissions to fix. Sorry, but that kind of problem goes far beyond the scope of what I can easily discuss in the forums.

You're going to have to fix the settings to work for CIFS while simultaneously providing appropriate permissions for WebDAV. This is *very* advanced permissioning because CIFS uses ACLs and WebDAV uses Unix permissions.

But, you have a larger problem.

Sharing out via CIFS and WebDAV simultaneously can corrupt your files. So you really need to pick one or the other and use that one exclusively. Yyou can make the "other" read-only, but doing anything else is risky. This is why I have a dataset specifically for WebDAV only.

 

[mudshark]

*I* didn't personally overwrite permissions. Before enabling WebDAV it was not like that. (There was no user or group named that.)
I am *not* now (nor have I ever) shared out anything simultaneously on both WebDAV and CIFS. The only WebDAV share I created (under sharing>webdav) I've since deleted.
All WebDAV shares were deleted + services stopped and still the dataset permissions did not revert to whatever they were before this.
This is the first I've heard that a WebDAV share ought to be on it's own dataset.

So, does it look to you then like I'll have to wipe everything and re-install (this time, creating TWO datasets under the "mnt" point), or is there another way to correct the curruption in the permissions that happened when I turned on webdav?

Thx

 

[SweetAndLow]

there isn't any corruption in the permissions. They are just configured for webdav since you setup that dataset to be a webdav dataset. If you want to revert back to cifs you need to create a cifs share and check the box that say to create sane cifs permissions and set recursively. If you had any special modifications to your permissions that you made along the way you will have to redo that but for the most part things should be working.

 

[mudshark]

I did not initially setup that dataset for webdav; for months it's been running great as a host for many CIFS shares only.
I was told to NOT setup webdav until after an U/G to the newest patch.
I patched FreeNAS then 1- started the webdav service and 2- created a webdav share.
It seems as though THAT is when the permissions changed on the entire dataset in spite of what was already set there.

OK, so dataset permissions aren't corrupted but they are still now wrong. The CIFS shares I've had all along are still there, just now they are read-only from the PCs and if possible I do want to revert the CIFS shares to working.

You say I "need to create [new] CIFS share(s)"... Does that mean I must destroy the ones that are still there?
= It would seem like all I'd need to do is correct the permissions on the now wrongly permissioned dataset (screen shot above) recursively. No special modifications were made at all.

Follow-up question since it seems as though I *may not* need to fully rebuild the installation:
= Is it possible to create a new "dataset" on the existing "mnt" point along-side the existing "RAID10" (CIFS) dataset?

Thx
RG

 

[cyberjock]

Ok, so a few things:

1. If you start using webdav and you specify a location, a zpool root or otherwise, then webdav tries to take ownership of the files. *if* you chose the whole pool, that is how the permissions got borked. So that would explain the predicament you are in.
2. Normally I recommend doing datasets for CIFS for a bunch of reasons (just go with me on this). If you want to do webdav, then I'd recommend you do a separate dataset for webdav for various reason (again, just go with me on this).
3. You can definitely create new datasets and move/copy files to it. A reinstall is not going to "fix" this as the permissions are on the zpool. To fix the permissions you are going to have to go to the CLI and fix them, or destroy the zpool and restore from backup while setting permission up as you go.

Note that if you try to set permissions for the whole pool recursively with one command that is basically a 'give me full permission to everything' so you can fix the permissions in Windows for CIFS, you risk overwriting the permissions of jails that may exist on the pool. This will breaks the jails and you have no chance of undoing that.

So yes, you are in a bind, and the fixes aren't necessarily quick and easy, but all of your data is there and safe. You just need to mess with permissions to "undo" what they are currently set to.

 

[mudshark]

Thank you so very much! That does clear up things.
Everything is backed up in 2 places right now and nothing there is time or mission critical so I may just do a fresh install incorporating this info with what I was already doing.
Thx again
RG

 

[mudshark]

Aarrrgh!!! Rebuilt server and had a similar problem so I rebuilt it AGAIN and won't do anything until I see what I'm missing.

Here's what I intend to do:
1 Create volume (so far so good, eh?)
2 Create a zpool dataset under the volume
3 Create WebDAV share in the zpool (start WebDAV service)
4 Create all the CIFS shares on the volume (but not under the WebDAV zpool)
/end

Did I leave anything out?

 

[SweetAndLow]

To setup webdav:
1. create pool
2. create webdav dataset under the root dataset
3. create webdav share and point it to webdav dataset. Check the recursive box if you want to make everything accessible by webdav. If not you will have to give other read permissions to view files and directories will need other execute bit set.
4. start webdav service

To setup cifs:
1. create cifs dataset, must be different than webdav. Unless you know what you are doing
2. create cifs share and point it to the cifs dataset. Check the recursive box if you want to make everything accessible over cifs. if not you will have to modify it manually.
3. start cifs service

This should be very straightforward and webdav is quite easy to setup. Don't make it to complicated.

 

[mudshark]

Did a new build per instructions above. The big difference between building datasets in the order above, and the way the install wizard guides you, is that the build process from the boot CD creates all your "non-WebDAV" shares first. Further, as it creates each share it creates a dataset for each. So, the steps I was guided thru were:
- The wizard creates a single "RAID10" volume.
- Creates all your CIFS shares w/ a dataset for each.
After install completes, to make the WebDAV share I'd followed the same process the wizard used:
- Create WebDAV dataset from under SHARING > Add WebDAV share where, (like with the CIFS shares) it creates a dataset for you.
The result was ALWAYS are the same: I never have a problem with the WebDAV share but all once-working CIFS shares break, becoming READ-ONLY after a WebDAV share is created. (And no, I have *never* tried to have any one dataset be anything more than one kind of share.)

So, this time I did not let the wizard create any shares at all.
1- Complete the wizard w/o creating any shares.
2- Create WebDAV dataset (you guys specify create WebDAV first, then CIFS. )
3- Create WebDAV share specifically under the WebDAV dataset (service starts)
4- Create CIFS dataset
5- Create all CIFS shares specifically under the CIFS dataset (service starts)

What I have now is a properly working WebDAV share (except that it doesn't work w/https, but that's a different issue, no doubt).
However a new problem has appeared...
Now no matter which CIFS share I write to,the files show up in ALL CIFS shares!!! (At least they're not READ-ONLY!)

The obvious difference is that this time each CIFS share does not have it's own dataset. They are all shares under a common CIFS dataset.
I suppose the way that the wizard creates the CIFS shares each in it's own dataset must be the answer.

OK, so I delete all CIFS shares and the CIFS dataset, then create a new dataset for each share and create a new share inside each dataset . Guess what... They are all READ-ONLY.

 

[SweetAndLow]

Nice job doing all that work to figure things out. For the datasets that are read only can you provide a screenshot of there configuration and permissions? Or even better the debug file from advanced settings.

 

[mudshark]

Below are screen shots of the config/permissions for one example CIFS share & dataset.
If you can tell me how to get he debug file from advanced settings I am all ears! I see "Advanced" under "System". I see "Save debug" but I want to be sure that file contains whatever it is you need to see.

Dataset permissions.
You'd have to scroll down to see "Set recursively" which I did select and apply.

Share config for same dataset (top half)

Share config for same dataset (bottom half)

 

[SweetAndLow]

So the only user that can write to that dataset is the root user or a user that is in the wheel group. All other users can only read and execute from that directory. What do you think it should do? What user are you logging in with?

 

[mudshark]

Should be able to read / write these shares no matter what Windows User you are logged in as. Works that way before a WebDAV install!

 

[SweetAndLow]

No it didn't, not if this was the permissions it had before.

 

[mudshark]

Ok then, I'll build it again and not put WebDAV on and we'll have a way to check! I'll write back tomorrow with the results!
:D

 

[mudshark]

OK, Installation under 9.3 rev 201501162230. All CIFS shares working.

CIFS service config:
* Owner is NOBODY (root didn't seem like a good idea!)
* WorkGroup is correct

CIFS datasets:
* Owner/Group = NOBODY/WHEEL
* No datasets exist but for all the CIFS shares

Create WebDAV dataset > CIFS Read/Write still OK

Create WebDAV share specifically under the WebDAV dataset (service starts, configure service)
WebDAV Read/Write OK + CIFS Read/Write still OK

Perform update via SYSTEM>UPDATES
Can no longer write to CIFS shares

After comparing all info from before / after WebDAV & system update found the difference is in the CIFS services config screen... The "Allow Empty Password" checkbox suddenly has a check in it. Removed the check and all shares CIFS + WebDAV are working properly.

I'd not considered that update before.
I'd ASSUMED (why?) it had to be the addt'l share I'd added in... Anyway, issue seems solved.

That was satisfying!

Next: Why doesn't secure (https) WebDAV work! (New thread these.)

 

[mudshark]

The system update changed the "Allow Empty Password" checkbox (under CIFS services config), adding a tic mark for no good reason it would seem.
Should I post this finding to the BUGs list?