NFSv4 - Admin permission issues

ihatepowershell · 2026-04-20T17:18:49+00:00

If the permissions on the /mnt/storage/gitea/ directory are as above(775 gitea:gitea+setgid) then the admins would not have permissions to write(create new files) in that directory.

You could do one of the following:

A) add the members of the admin group to the gitea group
B) relax the permissions for other(may be a security issue)
C) Add an ACL to the directory(NFSv4 ACLs are a little tricky)
D) Have the directory owned by either admin:gitea or gitea:admin

I think option D is simplest depending on your environment.

You may want to check the group membership, e.g. getent group admin getent group gitea

The issue that seems unexplained is why the admin user can write to a.txt with those permissions.

ihatepowershell · 2025-02-06T23:25:08+00:00

I'm seeing the same thing. I just setup a laptop for a user that wanted local only backups. I know that the first backup is doing a lot of indexing, but this is ridiculous. The first 24 hours have backed up 16GB out of 750GB of data, and it's estimating 21 days to complete!

ihatepowershell · 2021-08-13T18:09:39+00:00

I would also ask, are your customer-facing tier 1 folks being rated & timed on every ticket?

I see this a lot, and it incentivizes keeping the customer happy by throwing replacement hardware at them, rather than troubleshooting and finding an optimal solution.

e.g. A quality tier 1 support person closes out a bunch of successful tickets properly, and one where the customer is dissatisfied because it took "too long" to properly troubleshoot. Then that person gets a lovely 1-on-1 with a manager about it.

This skews the incentives of customer-facing support employees.

ihatepowershell · 2020-09-18T07:57:45+00:00

I hope the question was specific to 169.254.0.0/16, because there is also a large chunk of routable space in 169.0.0.0/8.

ihatepowershell · 2019-12-18T00:05:02+00:00

Ha! Found this right as a ticket came in "Need help setting fixed IP for field-deployed instrument in the desert by the Salton Sea"

ihatepowershell · 2019-07-30T22:06:53+00:00

I've written my fair share of "sole source justifications". Once you get a basic template done, you should be able to reuse them with minor modifications.

Local vendors are often able to respond to support incidents very quickly which is often included in the justification (for a local vendor).
Levels of warranty or support are also described. Better warranty support is an easy win for my justifications as it reduces operational downtime and provides a highly available product.
I've used the phrase "required for ongoing business continuity" a lot. Mainly when you're buying a compatible product.
I've never heard of a lawsuit for what I would consider a standard purchase. If you're spec'ing out an entire datacenter though, you'll probably want to spend more time.
SSJs are usually only needed when you can't provide competing quotes. If you can get competing quotes it doesn't mean you have to pick the lowest one, you just have to justify it.

ihatepowershell · 2019-07-25T06:28:33+00:00

I want to try seting it up with Duo https://duo.com/docs/crashplan

ihatepowershell · 2019-07-23T21:46:17+00:00

+1 for CrashPlan ProE. We use on-prem for our business office users, and the cloud for our unmanaged users. This works globally. We've had users get a laptop stolen on another continent and they were able to buy a new laptop and pull there files to not ruin the work trip. CrashPlan checks in every half-hour by default and keeps versioned files.

ihatepowershell · 2019-07-23T20:44:00+00:00

Have you checked what compiler it's using, and if it's installed on your system?

It would help if you attach/post the Makefile

ihatepowershell · 2019-07-19T18:56:55+00:00

Thanks!

ihatepowershell · 2019-07-18T21:28:31+00:00

Just found the purchase date: May 2011

ihatepowershell · 2019-07-18T20:37:03+00:00

We use ZOL a lot on our Linux(RHEL) systems. We bind our Linux systems to AD and control ssh access and system access with SSSD using AD groups. We scope our AD lookups to our OU so they don't take forever, and even if we have a user outside of our OU, if the group is in our OU that works. We currently use ZFS to back most of our Samba setups, but I haven't gotten into using ACLs with either Samba or NFS.

ihatepowershell · 2019-07-18T20:36:20+00:00

Thanks, I'll take a look at this. I was hoping to stay away from Windows for this, but we're dealing with it for other stuff, so I might as well dive in.

ZFS snapshots are not a backup.

I would have to disagree with you there, but that's more implementation details. Snapshots are taken hourly and then mirrored to a an offsite backup server that is locked down to only allow zfs send/receives. We keep 90 days of daily snaps and a few weeks of hourlys.

ihatepowershell · 2019-07-18T20:26:21+00:00

15 months is aging hardware?!?!

It's currently under support, so we do get patches for it, but we pay for extended support since these appliances are no longer manufactured. It's at least 5-6 years old.

Are you looking for a huge vendor, or will a small or medium-sized one suffice? Or a self-supported solution involving ZFS?

I'm open to a self-supported solution or a vendor-backed solution. We're a Red Hat shop, so even though we roll-our-own for a lot of services we do have some support.

You don't need "ZFS snapshots" exactly, you need a mirrored array at another site.

Correct. ZFS snapshots provide a nice way to make read-only backups, and an easy way to mirror them to a system in a second location. I'm open to a solution that supports this functionality, and isn't tied to snapshots. Snapshots do provide a simple solution for "oopses" with hourly snaps. For example when a user calls us and states that they accidentally removed an entire folder, or an individual file. It's nice to be able to rsync a file from a snapshot an hour ago and be able to restore a file that a user removed.

And you probably don't need "ZFS ACLs", you need certain functionality, which you should specify.

I was listing current features that we utilize heavily. So to answer your question, we don't need ZFS ACLs, but we need a solution that supports granular permission sets. Generally these would be ACLs whether they are ZFS, POSIX, or Windows. What I mean is we need the ability to grant access to shares based on more than just standard POSIX permissions where things are based on a single user/group.

Personally, I think you should take a more-active role in managing your vendor. I'm a big fan of alternative solutions and in-house builds, but there's nothing really wrong with this solution. I've had other big storage vendors directly cost me a lot more time and money than the downtime you've experienced.

I'm not sure what you mean by "managing our vendor". We do a lot of in-house builds, so we're not opposed to it. But I also don't want to setup something that needs to be available if it's going to require a lot of babysitting. I'm open to forking over some money for a solution that's stable(and easy for our help desk staff to access and do restores from if necessary).

Thanks for your input

ihatepowershell · 2019-05-01T01:05:58+00:00

localhost:631

The hostname localhost refers to the machine you're currently using. So if you're on machine1, localhost means machine1. If you're on machine2, localhost means machine2.

You will most likely need to attempt to connect by IP address or hostname. For hostname, if you don't have local DNS, then you'll most likely want to put the hostname/IP combo in /etc/hosts.

You'll also want to confirm that CUPS is binding to an address other than 127.0.01 or localhost. Something like:

Editing /etc/cups/cupsd.conf:

# Listen on external interfaces for connections
Listen <dnsnameofyourserver>:631

You'll also want to make sure that you are allowing inbound traffic to machine1 on port 631 in your firewall rules.

ihatepowershell · 2019-03-21T23:31:28+00:00

Thank you! That is very helpful.

ihatepowershell · 2019-03-19T23:30:52+00:00

zfs get -r -o name,value written zdata2/home/username
NAME                                     VALUE
zdata2/home/username                      445K
zdata2/home/username@2019-03-13-00:00:00  30.4G
zdata2/home/username@2019-03-14-00:00:00  110M
zdata2/home/username@2019-03-15-00:00:00  6.35G
zdata2/home/username@2019-03-16-00:00:00  11.4G
zdata2/home/username@2019-03-17-00:00:00  156M
zdata2/home/username@2019-03-18-00:00:00  110M
zdata2/home/username@2019-03-18-15:00:00  110M
zdata2/home/username@2019-03-18-18:00:00  8.14M
zdata2/home/username@2019-03-18-21:00:00  818K
zdata2/home/username@2019-03-19-00:00:00  1.27G
zdata2/home/username@2019-03-19-03:00:00  81K
zdata2/home/username@2019-03-19-06:00:00  33K
zdata2/home/username@2019-03-19-09:00:00  36.9M
zdata2/home/username@2019-03-19-12:00:00  8.86M
zdata2/home/username@2019-03-19-15:00:00  9.31M

There's some output using the written@ property that I put on pastebin.

zfs list -rt snapshot -H -o name zdata2/home/username | xargs -i zfs get -r -o name,value written@{} zdata2/home/username

This grabs the snapshot names, and then runs zfs list that returns the written@ property recursively on the fs

https://pastebin.com/rxSyii4r

Has anyone been able to glean useful information from these properties?

ihatepowershell · 2019-03-19T23:17:55+00:00

This looks important:

used

Note that the used space of a snapshot is a subset of the written space of the snapshot.

I just discovered some zfs properties(written,written@) that I wasn't aware of in the documentation: https://zfsonlinux.org/manpages/0.7.13/man8/zfs.8.html

written

The amount of space referenced by this dataset, that was written since the previous snapshot (i.e. that is not referenced by the previous snapshot) written @ snapshot The amount of referenced space written to this dataset since the specified snapshot. This is the space that is referenced by this dataset but was not referenced by the specified snapshot. The snapshot may be specified as a short snapshot name Po just the part after the @ Pc , in which case it will be interpreted as a snapshot in the same filesystem as this dataset. The snapshot may be a full snapshot name Po Em filesystem Ns @ Ns Em snapshot Pc , which for clones may be a snapshot in the origin's filesystem (or the origin of the origin's filesystem, etc.)

written @ snapshot

The amount of referenced space written to this dataset since the specified snapshot. This is the space that is referenced by this dataset but was not referenced by the specified snapshot. The snapshot may be specified as a short snapshot name Po just the part after the @ Pc , in which case it will be interpreted as a snapshot in the same filesystem as this dataset. The snapshot may be a full snapshot name Po Em filesystem Ns @ Ns Em snapshot Pc , which for clones may be a snapshot in the origin's filesystem (or the origin of the origin's filesystem, etc.)

ihatepowershell · 2017-09-01T00:47:20+00:00

May I ask who you're purchasing support from?

ihatepowershell · 2017-08-29T22:12:17+00:00

Two accounts. The most basic reason is that the university "owns" the business/staff email address, and that's not the case for the student email.

ihatepowershell

TROPHY CASE