wrong umask in nfs-controller pod

[xhejtman]

It seems that current nfs-controller pod has umask 0022 which leads to PV created with access rights 0755. Is this desired? I guess not according to source codes:

if err = os.Mkdir(internalVolumePath, 0777); err != nil && !os.IsExist(err) {

should it be fixed to either allow set umask or set umask forcibly to 0000?

[andyzhangx]

not sure what do you mean, I think you could submit a PR and then review, thanks.

[xhejtman]

Ok, I try to explain it a bit more first, not sure if it is a real bug or not.

csi-driver-nfs/pkg/nfs/controllerserver.go

Lines 103 to 105 in b53f765

	if err = os.Mkdir(internalVolumePath, 0777); err != nil && !os.IsExist(err) {
	return nil, status.Errorf(codes.Internal, "failed to make subdirectory: %v", err.Error())
	}

this code should create volume with access rights 0777. Unless umask is set.

It seems that rke1/2 containers have umask set to 0022 which means that persistent volumes are created with rights 0755 instead of 0777.

I guess it is a bug and nfsplugin should set umask to 0000 by itself. What do you think?

[xhejtman]

I tried workaround with -mount-permissions, but no luck either:

kubectl logs csi-nfs-node-bg684 -n kube-system -c nfs
flag provided but not defined: -mount-permissions '0777'
Usage of /nfsplugin:
  -add_dir_header
    	If true, adds the file directory to the header of the log messages
  -alsologtostderr
    	log to standard error as well as files
  -endpoint string
    	CSI endpoint (default "unix://tmp/csi.sock")
  -log_backtrace_at value
    	when logging hits line file:N, emit a stack trace
  -log_dir string
    	If non-empty, write log files in this directory
  -log_file string
    	If non-empty, use this log file
  -log_file_max_size uint
    	Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
  -logtostderr
    	log to standard error instead of files (default true)
  -mount-permissions string
    	mounted folder permissions

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[juergenthomann]

Have you tried it with "--mount-permissions=0777"? I think it did not work for me with a single dash at the beginning.

But I'm not sure if that has to be at the driver or controller. I have it currently for both, as the first I tried was not the right one.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[andyzhangx]

should be fixed by this PR(#238) in v3.0.0 release